CVE-2024-40647: Dstack · Sentry's Python SDK unintentionally exposes environment variables to subprocesses
Affects dstackSource GCVE Database
Not known to be exploited · CVSS 5.3 Medium : upgrade to 0.18.5 when convenient.
Data as of 30 Oct 2026, 07:30 UTC
- Patch
- Available – fixed in 0.18.5
CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:NExploitation evidence
Disclosed: evidence found.
CVE published 1 Jun 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.
What to do
Upgrade dstack to 0.18.5.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewdstackpkg:brew/dstackOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
### 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](https://docs.sentry.io/platforms/python/integrations/default-integrations/#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](https://github.com/getsentry/sentry-python/releases/tag/2.8.0). The fix was also backported to [sentry-sdk==1.45.1](https://github.com/getsentry/sentry-python/releases/tag/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](https://docs.sentry.io/platforms/python/integrations/default-integrations/) * Python docs: [subprocess module](https://docs.python.org/3/library/subprocess.html) * Patch https://github.com/getsentry/sentry-python/pull/3251
References
- github.com/getsentry/sentry-python/security/advisories/GHSA-g92j-qhmh-64v2 (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2024-40647 (opens in a new tab)
- github.com/getsentry/sentry-python/pull/3251 (opens in a new tab)
- github.com/getsentry/sentry-python/commit/763e40aa4cb57ecced467f48f78f335c87e9bdff (opens in a new tab)
- docs.python.org/3/library/subprocess.html (opens in a new tab)
- docs.sentry.io/platforms/python/integrations/default-integrations (opens in a new tab)
- docs.sentry.io/platforms/python/integrations/default-integrations/ (opens in a new tab)
- github.com/getsentry/sentry-python (opens in a new tab)
- github.com/getsentry/sentry-python/releases/tag/1.45.1 (opens in a new tab)
- github.com/getsentry/sentry-python/releases/tag/2.8.0 (opens in a new tab)
- lists.debian.org/debian-lts-announce/2026/06/msg00001.html (opens in a new tab)