GHSA-H4FR-CMH5-QR62
Vulnerability from github – Published: 2026-10-23 21:58 – Updated: 2026-10-23 21:58Impact
Fallow expands some globs from the analyzed repository on disk. Before 3.34.0, a segment such as .*, .? or ..* in such a glob also matched the special .. entry. The glob crate tests .. against a segment that starts with a literal .. Fallow validates plugin glob patterns and refuses absolute paths and .. segments, but these segments passed that validation.
The attacker controls the repository content. The attacker must also be able to read the Fallow output, for example a CI log or a pull request comment. Then the attacker can learn if a file or directory exists in the parent of the project root:
- A plugin
fileExistsdetection pattern such as.*/marker.jsonmade the plugin active whenmarker.jsonexisted in the parent directory. - An external plugin
configPatternsoralwaysUsedpattern could match a config file in the parent directory. When the plugin was active and declaredtoolingDependencies, the tooling detection credited the related dev dependency. An unused dependency finding could then disappear, and--trace-dependencyprinted the outside path. fallow plugin-checkreportedpath_exists: truefor a seeded entry that matched only in the parent directory.
Fallow tested only that these paths exist. It did not read or print the content of a file outside the project root through these globs.
The Jest, Vitest and Rstest project globs had the same .* problem, and the Jest and Vitest ones also read file content. GHSA-jfwm-3p3c-6hx5 describes that case.
Patches
Fixed in 3.34.0. Fallow now rewrites a leading . in a wildcard segment to [.] before it expands the glob on disk. [.] matches the same hidden files and directories inside the project root. The glob crate does not test .. against it.
Workarounds
Run Fallow only on repositories that you trust. Before you run Fallow on another repository, check the detection, configPatterns and alwaysUsed patterns of its plugin files.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fallow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.34.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fallow-cli/fallow-node"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.34.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "fallow-cli"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.34.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "fallow-config"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.34.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "fallow-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.34.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-23T21:58:16Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\n\nFallow expands some globs from the analyzed repository on disk. Before 3.34.0, a segment such as `.*`, `.?` or `..*` in such a glob also matched the special `..` entry. The `glob` crate tests `..` against a segment that starts with a literal `.`. Fallow validates plugin glob patterns and refuses absolute paths and `..` segments, but these segments passed that validation.\n\nThe attacker controls the repository content. The attacker must also be able to read the Fallow output, for example a CI log or a pull request comment. Then the attacker can learn if a file or directory exists in the parent of the project root:\n\n- A plugin `fileExists` detection pattern such as `.*/marker.json` made the plugin active when `marker.json` existed in the parent directory.\n- An external plugin `configPatterns` or `alwaysUsed` pattern could match a config file in the parent directory. When the plugin was active and declared `toolingDependencies`, the tooling detection credited the related dev dependency. An unused dependency finding could then disappear, and `--trace-dependency` printed the outside path.\n- `fallow plugin-check` reported `path_exists: true` for a seeded entry that matched only in the parent directory.\n\nFallow tested only that these paths exist. It did not read or print the content of a file outside the project root through these globs.\n\nThe Jest, Vitest and Rstest project globs had the same `.*` problem, and the Jest and Vitest ones also read file content. GHSA-jfwm-3p3c-6hx5 describes that case.\n\n### Patches\n\nFixed in 3.34.0. Fallow now rewrites a leading `.` in a wildcard segment to `[.]` before it expands the glob on disk. `[.]` matches the same hidden files and directories inside the project root. The `glob` crate does not test `..` against it.\n\n### Workarounds\n\nRun Fallow only on repositories that you trust. Before you run Fallow on another repository, check the `detection`, `configPatterns` and `alwaysUsed` patterns of its plugin files.",
"id": "GHSA-h4fr-cmh5-qr62",
"modified": "2026-10-23T21:58:16Z",
"published": "2026-10-23T21:58:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fallow-rs/fallow/security/advisories/GHSA-h4fr-cmh5-qr62"
},
{
"type": "WEB",
"url": "https://github.com/fallow-rs/fallow/pull/3548"
},
{
"type": "WEB",
"url": "https://github.com/fallow-rs/fallow/commit/133d4c862c74f4b1f0a7417c65b7157c1144294d"
},
{
"type": "PACKAGE",
"url": "https://github.com/fallow-rs/fallow"
},
{
"type": "WEB",
"url": "https://github.com/fallow-rs/fallow/releases/tag/v3.34.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Fallow: A `.*` glob segment let an analyzed repository make Fallow test paths in the parent of the project root"
}
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.