Development record
The guard allows a zsh line that loads a function file through `FPATH` or `fpath` and `autoload`: zsh reads the file and runs its body when the function is called, and the guard never opens it, so a bundled blocker in that file runs as the operator with exit 0.
The guard allows a zsh line that loads a function file through FPATH or fpath and autoload: zsh reads the file and runs its body when the function is called, and the guard never opens it, so a bundled blocker in that file runs as the operator with exit 0.
Private security advisory GHSA-jh4q-4cgv-5crr (draft, severity high). Full text, evidence and reproduction: .abcd/.work.local/scratch/security-drain-2026-10-11/advisories/ in the main checkout's local tier. This record stays uncommitted until its fix lands; the fix commit adds it directly to resolved/.
Evidence (main 3d171421a): trackedVars (internal/core/guard/script.go) lists BASH_ENV, ENV, HOME, ZDOTDIR and PATH, not FPATH; targetsOf skips autoload as a command that reads no file. Reproduced at that commit with abcd guard check --command and a blocker in <dir>/fp/p: FPATH=<dir>/fp zsh -c 'autoload p; p' and zsh -c 'fpath=(<dir>/fp); autoload p; p' are both allow (exit 0).
Frontmatter
| id | iss-2610111600022820 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2610111600022820-guard-allows-zsh-fpath-autoload.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2610111730574385An FPATH already exported in the hook's environment and then changed on the line by a plain assignment (no export) is not handed to a child zsh, so the guard's autoload reader, which now tracks FPATH set on the line, can judge the function file from the line's value while the child shell searches the inherited one. Left open by lane G on 2026-10-11 while fixing the FPATH and autoload gap (iss-2610111600022820).