Sentry's Python SDK unintentionally exposes environment variables to subprocesses

Impact

The bug in Sentry’s Python SDK <2.8.0 results in the unintentional exposure of environment variables to subprocesses despite the env={} setting.

Details

In Python’s subprocess calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use env argument in subprocess calls, like in this example:

>>> subprocess.check_output(["env"], env={"TEST":"1"})
b'TEST=1\n'

If you’d want to not pass any variables, you can set an empty dict:

>>> subprocess.check_output(["env"], env={})
b''

However, the bug in Sentry SDK <2.8.0 causes all environment variables to be passed to the subprocesses when env={} is set, unless the Sentry SDK’s Stdlib integration is disabled. The Stdlib integration is enabled by default.

Patches

The issue has been patched in https://github.com/getsentry/sentry-python/pull/3251 and the fix released in sentry-sdk==2.8.0. The fix was also backported to sentry-sdk==1.45.1.

Workarounds

We strongly recommend upgrading to the latest SDK version. However, if it’s not possible, and if passing environment variables to child processes poses a security risk for you, there are two options:

1. In your application, replace env={} with the minimal dict env={"EMPTY_ENV":"1"} or similar.

OR

2. Disable Stdlib integration:

import sentry_sdk

# Should go before sentry_sdk.init
sentry_sdk.integrations._DEFAULT_INTEGRATIONS.remove("sentry_sdk.integrations.stdlib.StdlibIntegration")

sentry_sdk.init(...)

References

• Sentry docs: Default integrations
• Python docs: subprocess module
• Patch https://github.com/getsentry/sentry-python/pull/3251