GHSA-JV6M-48W5-5RPR
Vulnerability from github – Published: 2026-11-13 18:05 – Updated: 2026-11-13 18:05Summary
envd’s install.python_packages(requirements=...) could read files outside the build context on the host. Content interpreted as dependency entries could appear in build logs and build-step metadata.
Commit f576c92, released in v1.3.5, added path containment validation but left a time-of-check/time-of-use (TOCTOU) race between symlink resolution and opening the requirements file. Commit 9d575b3 addresses this race by opening requirements files through a directory-rooted filesystem handle.
Details
envd reads requirements files on the host to determine whether their contents can be embedded directly into a pip installation build step.
The vulnerable host-side requirements read was introduced in v0.3.38. Version v1.3.5 added containment checks for static path escapes but remained vulnerable to a TOCTOU race. The complete fix is included in v1.3.6.
Before f576c92, this host read lacked a build-context containment check. That commit added frontend path validation and a compile-time check using filepath.EvalSymlinks followed by a containment comparison.
However, symlink resolution returns a pathname rather than a pinned filesystem object. The subsequent os.Open independently resolves that pathname. Concurrent filesystem changes could therefore invalidate the containment check before the file was opened.
The complete fix uses os.OpenRoot and Root.Open to enforce containment during filesystem traversal.
Resources: - first commit: be783264fdd79ad7262cea0485b7d449ca514f80 - Initial containment fix: f576c92 - TOCTOU fix: 9d575b3
Proof of concept
The security-relevant condition is a requirements-file pathname whose filesystem resolution changes between validation and opening. The containment check describes the filesystem at validation time, while the later pathname-based open may access a different object.
The fix includes a deterministic regression test for the underlying object-pinning guarantee. It opens a context directory handle, moves that directory, and creates a replacement directory at the original pathname containing different requirements. The rooted reader continues reading the original context; a pathname-based reader reads the replacement.
This regression test demonstrates the distinction between rooted and pathname-based reads. It is not an end-to-end demonstration of host file disclosure.
Impact
An attacker who can influence the build input—and, for the residual race in v1.3.5, concurrently modify the relevant filesystem paths—may cause envd to read files outside the intended build context, subject to the permissions of the envd process.
Depending on the file contents and requirements parsing, information may be exposed through dependency debug logs and build-step metadata. This issue does not establish arbitrary code execution or unrestricted disclosure of every file.
v1.3.5 remains affected by the TOCTOU variant. Earlier versions containing the host requirements-reading behavior are affected by the original containment issue; confirm the earliest affected release before setting the advisory’s version range.
Patched version: v1.3.6.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "envd"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.38"
},
{
"fixed": "1.3.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-128079"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-11-13T18:05:15Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nenvd\u2019s `install.python_packages(requirements=...)` could read files outside the build context on the host. Content interpreted as dependency entries could appear in build logs and build-step metadata.\n\nCommit f576c92, released in v1.3.5, added path containment validation but left a time-of-check/time-of-use (TOCTOU) race between symlink resolution and opening the requirements file. Commit 9d575b3 addresses this race by opening requirements files through a directory-rooted filesystem handle.\n\n### Details\n\nenvd reads requirements files on the host to determine whether their contents can be embedded directly into a pip installation build step.\n\nThe vulnerable host-side requirements read was introduced in v0.3.38. Version v1.3.5 added containment checks for static path escapes but remained vulnerable to a TOCTOU race. The complete fix is included in v1.3.6.\n\nBefore f576c92, this host read lacked a build-context containment check. That commit added frontend path validation and a compile-time check using filepath.EvalSymlinks followed by a containment comparison.\n\nHowever, symlink resolution returns a pathname rather than a pinned filesystem object. The subsequent os.Open independently resolves that pathname. Concurrent filesystem changes could therefore invalidate the containment check before the file was opened.\n\nThe complete fix uses os.OpenRoot and Root.Open to enforce containment during filesystem traversal.\n\nResources:\n- first commit: be783264fdd79ad7262cea0485b7d449ca514f80\n- Initial containment fix: f576c92\n- TOCTOU fix: 9d575b3\n\n### Proof of concept\n\nThe security-relevant condition is a requirements-file pathname whose filesystem resolution changes between validation and opening. The containment check describes the filesystem at validation time, while the later pathname-based open may access a different object.\n\nThe fix includes a deterministic regression test for the underlying object-pinning guarantee. It opens a context directory handle, moves that directory, and creates a replacement directory at the original pathname containing different requirements. The rooted reader continues reading the original context; a pathname-based reader reads the replacement.\n\nThis regression test demonstrates the distinction between rooted and pathname-based reads. It is not an end-to-end demonstration of host file disclosure.\n\n### Impact\n\nAn attacker who can influence the build input\u2014and, for the residual race in v1.3.5, concurrently modify the relevant filesystem paths\u2014may cause envd to read files outside the intended build context, subject to the permissions of the envd process.\n\nDepending on the file contents and requirements parsing, information may be exposed through dependency debug logs and build-step metadata. This issue does not establish arbitrary code execution or unrestricted disclosure of every file.\n\nv1.3.5 remains affected by the TOCTOU variant. Earlier versions containing the host requirements-reading behavior are affected by the original containment issue; confirm the earliest affected release before setting the advisory\u2019s version range.\n\nPatched version: v1.3.6.",
"id": "GHSA-jv6m-48w5-5rpr",
"modified": "2026-11-13T18:05:15Z",
"published": "2026-11-13T18:05:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorchord/envd/security/advisories/GHSA-jv6m-48w5-5rpr"
},
{
"type": "WEB",
"url": "https://github.com/tensorchord/envd/pull/2112"
},
{
"type": "WEB",
"url": "https://github.com/tensorchord/envd/pull/2119"
},
{
"type": "WEB",
"url": "https://github.com/tensorchord/envd/commit/9d575b354ce17a02ef9698b6ff0d5d14296c5734"
},
{
"type": "WEB",
"url": "https://github.com/tensorchord/envd/commit/f576c92c1e6dcb9b00b60995534aeb2a83b0b407"
},
{
"type": "PACKAGE",
"url": "https://github.com/tensorchord/envd"
},
{
"type": "WEB",
"url": "https://github.com/tensorchord/envd/releases/tag/v1.3.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "envd: Host file disclosure through requirements path traversal and TOCTOU"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.