GHSA-h4fr-cmh5-qr62 json
Fallow: A `.*` glob segment let an analyzed repository make Fallow test paths in the parent of the project root
published 2026-10-23 16 d ago modified 2026-10-23 16 d ago
- cvss
- 3.3
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### Impact
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 `fileExists` detection pattern such as `.*/marker.json` made the plugin active when `marker.json` existed in the parent directory. - 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. - `fallow plugin-check` reported `path_exists: true` for 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.
Patch / fix
- npm fallow 3.34.0
- npm @fallow-cli/fallow-node 3.34.0
- crates.io fallow-cli 3.34.0
- crates.io fallow-config 3.34.0
- crates.io fallow-core 3.34.0
- github.com/fallow-rs/fallow@133d4c8 commit
- github.com/fallow-rs/fallow#3548 pull request
- github.com/fallow-rs/fallow/releases/tag/v3.34.0 release
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 3.3 | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| npm | fallow | <3.34.0 |
3.34.0 |
| npm | @fallow-cli/fallow-node | <3.34.0 |
3.34.0 |
| crates.io | fallow-cli | <3.34.0 |
3.34.0 |
| crates.io | fallow-config | <3.34.0 |
3.34.0 |
| crates.io | fallow-core | <3.34.0 |
3.34.0 |
Classification
- Weakness
-
- CWE-22 Improper Limitation of a Pathname to a Restricted Directory
References
Sources
- GitHub Advisory GHSA-h4fr-cmh5-qr62
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.