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 28d ago modified 22d 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
Is GHSA-h4fr-cmh5-qr62 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS 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
- Maintainer advisory GHSA-h4fr-cmh5-qr62
Fencer Intel 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.
The maintainers of fallow-rs/fallow published their own advisory on GitHub. Reviewed sources take precedence over it.