CVE-2024-40647

What it actually does

Affected versions of the Sentry Python SDK before 2.8.0 can unintentionally pass the parent Python process environment to child processes even when application code explicitly calls Python subprocess APIs with env={}. The issue occurs when the SDK's Stdlib integration is enabled, which is the default. This breaks the expected security boundary of subprocess environment isolation and can expose environment-stored secrets such as API keys, cloud credentials, database URLs, tokens, proxy credentials, and deployment metadata to spawned commands. The flaw does not by itself provide remote code execution; exploitation depends on an attacker already having a way to influence, execute, observe, or compromise a subprocess that was intended to run with an empty environment.

Why it matters to the business

Organizations using vulnerable sentry-sdk versions may have unintentionally exposed sensitive configuration and credentials to helper commands, plugins, build tools, scripts, or other subprocesses. If those subprocesses are less trusted, user-controlled, logged, sandboxed incorrectly, or able to make outbound network connections, leaked environment variables could lead to credential theft, cloud or SaaS account access, data exposure, or lateral movement. Public exploitation is not known, the CVE is not in CISA KEV, and EPSS is low, but the impact can still be serious where secrets are stored in environment variables and subprocesses are used for isolation.

How an attack unfolds

An attacker first needs a path to benefit from a child process receiving environment variables: for example, the ability to influence a command executed by the Python application, run code inside a helper process, read output from a subprocess, access logs produced by a subprocess, or compromise a lower-trust tool launched by the application. The vulnerable application initializes sentry-sdk before version 2.8.0 with default integrations enabled. Application code then calls subprocess functionality intending to clear the environment, such as subprocess.run(..., env={}). Because of the SDK bug, the child process still inherits the parent process environment. The attacker causes or waits for the child process to expose its environment through stdout, stderr, logs, crash output, network callbacks, temporary files, or behavior that uses inherited credentials. The attacker then uses any recovered secrets to access downstream services or escalate access.

How to fix it

Upgrade sentry-sdk to version 2.8.0 or later. The upstream fix is included in sentry-sdk==2.8.0 and in commit 6f4685e29b072d02edfb5c9def75120e88e600e4. Update direct and transitive dependency pins in requirements.txt, pyproject.toml, Poetry/Pipenv lock files, container images, serverless packages, and build artifacts. If immediate upgrade is not possible, disable Sentry default integrations where feasible, for example by initializing the SDK with default_integrations=False, because the vulnerable behavior is associated with the default Stdlib integration. As defense in depth, avoid storing long-lived secrets in process environment variables, minimize environment contents before application startup, use short-lived credentials, isolate untrusted subprocesses, restrict child process network access, and avoid launching user-controlled commands in processes that hold sensitive environment variables.

How to confirm the fix worked

Confirm that all deployed Python runtime artifacts use sentry-sdk 2.8.0 or later by checking dependency manifests, lock files, SBOMs, container layers, and runtime output such as pip show sentry-sdk or import sentry_sdk; print(sentry_sdk.VERSION). Verify that no vendored or bundled copy of sentry-sdk before 2.8.0 remains. For behavioral validation, run a controlled test in a non-production environment with a harmless marker environment variable set in the parent process, initialize sentry-sdk as the application does, and execute a subprocess with env={}; the child process must not receive or print the marker. Also review application code for subprocess calls that rely on env={} for secret isolation and confirm they behave correctly after the upgrade or mitigation.

Typical attack path

1. Identify a Python application using sentry-sdk before 2.8.0 with the default Stdlib integration enabled.
2. Find application functionality, jobs, plugins, worker tasks, CI steps, converters, scanners, or helper commands that spawn subprocesses with env={} or another expectation of a sanitized environment.
3. Gain the ability to influence the subprocess, read its output, access its logs, or compromise the child command/tool.
4. Trigger the subprocess so it runs under the vulnerable SDK instrumentation.
5. Collect inherited environment variables from child process output, logs, temporary artifacts, crash reports, or network exfiltration.
6. Use exposed credentials or tokens to access cloud services, internal APIs, databases, package registries, source repositories, or other connected systems.

How to detect it

There is no reliable universal network signature or exploit string for this issue because exploitation depends on local application behavior and the specific subprocesses launched. Investigate whether environment variables were exposed after subprocess execution in applications using sentry-sdk before 2.8.0. Review application logs, worker logs, CI/CD logs, container logs, Sentry event payloads and breadcrumbs, EDR process telemetry, auditd/Sysmon-style parent-child process records, shell command outputs, crash dumps, core dumps, and temporary files produced by subprocesses. Focus on time windows when vulnerable versions were deployed and on parent Python processes that spawned commands with intended empty or sanitized environments. Search for secret-like environment variable names and values appearing in stdout/stderr, exception traces, diagnostic dumps, uploaded artifacts, or outbound requests from child processes. Correlate any unexpected child process network connections or file writes with Python parent processes using vulnerable sentry-sdk versions. If secrets are found in child process artifacts, assume exposure and rotate them.

What your security team should do

• Inventory Python applications, workers, jobs, containers, and serverless functions that include sentry-sdk, prioritizing systems that store credentials in environment variables and spawn subprocesses.
• Upgrade sentry-sdk to 2.8.0 or later everywhere, including pinned lock files and rebuilt container images.
• Where upgrade is delayed, disable default Sentry integrations or otherwise remove the vulnerable Stdlib integration behavior, then regression-test subprocess behavior.
• Search code for subprocess usage with env={} or sanitized env dictionaries and treat those locations as higher risk until patched.
• Rotate secrets that may have been exposed to subprocesses, prioritizing long-lived cloud keys, database credentials, SaaS tokens, package registry tokens, and source control credentials where child processes were lower trust or logged their environment.
• Review logs and telemetry for evidence that environment variables or secrets appeared in child process output, Sentry events, application logs, CI logs, or temporary files.
• Add automated dependency policy checks to prevent sentry-sdk versions earlier than 2.8.0 from being introduced again.