Live › vulnerability › GHSA-h4fr-cmh5-qr62
Go to dashboardBefore 3.34.0, Fallow's glob expansion let a segment like `.*` match the parent-directory entry `..`, so a malicious repository could check whether files outside the project root exist. The attacker learns only existence (and a dependency path in trace output), not file contents, and must be able to read Fallow's output.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 22:05 UTC. All times on this page are UTC.
Teams that run Fallow in CI or on pull requests against repositories they do not fully control, where an outside contributor could add plugin files with wildcard glob patterns and read the Fallow output. Teams that only analyze their own trusted code have low exposure. Jest, Vitest and Rstest project globs share the same flaw, and the Jest and Vitest variant can also read file content (see GHSA-jfwm-3p3c-6hx5).
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| fallow | npm | < 3.34.0 | 3.34.0 |
| @fallow-cli/fallow-node | npm | < 3.34.0 | 3.34.0 |
| fallow-cli | cargo | < 3.34.0 | 3.34.0 |
| fallow-config | cargo | < 3.34.0 | 3.34.0 |
| fallow-core | cargo | < 3.34.0 | 3.34.0 |
fallow --version (or check the fallow entry in package-lock.json / Cargo.lock) and confirm it is below 3.34.0.detection, configPatterns or alwaysUsed patterns contain .*, .? or ..*.fallow and @fallow-cli/fallow-node to 3.34.0.fallow-cli, fallow-config and fallow-core crates to 3.34.0.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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:
fileExists detection pattern such as .*/marker.json made the plugin active when marker.json existed in the parent directory.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.
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.
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.
This page as .md · .json · in your agent: get_signal("GHSA-h4fr-cmh5-qr62")
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.