Fallow CVE-2026-115569

Requires a user, CI job, or automated agent to run a vulnerable Fallow (2.68.0 through 3.33.1) on an untrusted/attacker-controlled repository (UI:R, AV:L - no remote or network trigger). The malicious repo must contain a Jest projects entry (all affected versions) or, from 3.33.1, a Vitest test.projects entry, a Vitest inline-project extends path, or a script --config symlink, where that path resolves outside the project root via an absolute path, .. segments, a .*-segment glob (the glob crate tests .. against literal-dot segments), or an in-root symlink to a parent directory. Limiting factors that reduce real risk: exploitation only occurs when Fallow is actually executed on the hostile repo; the outside file contents are never printed or sent over the network, so the attacker obtains only altered unused-dependency/unused-file findings, not the file data. The only complete fix per the advisory is updating to 3.34.0; the stated workaround is to run Fallow only on trusted repositories and to inspect projects entries of jest.config.*/vitest.config.* beforehand.

All decision signals point to low, non-urgent risk and they are broadly consistent. The input CVSS is 3.3 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) and the vuln.today Decision label is 'monitor'. There is no CISA KEV listing and no EPSS score was supplied, so there is no evidence of active or probable exploitation; status is 'no public exploit identified at time of analysis' (the four references are the GHSA advisory, PR #3556, the fix commit, and the release tag - patch/advisory material, not exploit code). The one notable tension is within the impact metrics: the CVSS vector assigns C:L (confidentiality), but the GHSA advisory explicitly states the outside file contents are neither printed nor sent over the network and that 'the attacker gets changed findings, not the file content.' On that evidence the real-world effect is on the integrity of Fallow's analysis output (unused-dependency and unused-file findings can be altered), not on confidentiality - so the C:L rating likely overstates data exposure while understating the integrity angle. Exploitation also depends on UI:R: a user, CI pipeline, or automated agent must actually run Fallow on an attacker-controlled repository. Net: a genuine but low-priority path-traversal/analysis-integrity issue, not an emergency; 'monitor' is the appropriate posture.

An attacker publishes a crafted repository whose jest.config.* (or, from 3.33.1, vitest.config.*) contains a projects entry pointing outside the project root via an absolute path, '..' segments, a dot-prefixed wildcard glob, or an in-root symlink to a parent directory. When a victim runs a vulnerable Fallow (2.68.0-3.33.x) on that repo - typically in CI or via an automated agent analyzing a freshly cloned repository (AV:L, UI:R) - Fallow follows the path, reads the outside file, and parses it as a test-runner config, silently altering unused-dependency and unused-file findings. No public exploit code is identified, and the file contents are never disclosed to the attacker.