
Cloud Vulnerability DB
A community-led vulnerabilities database
Two code paths open files under the project without refusing a symlink, so a repository that commits a symlink (force-added past .gitignore where needed) makes DevOPs write to, or change the mode of, a file outside the project that the user can write.
devops init): analyzer/install.ts (around lines 287-414) and analyzer/scan.ts (around 421) copy hooks, write AGENTS.md, profile.yml and other files, and chmod 0755, following symlinks; realpath is checked once (around 264). Reproduced in a scratch project: a symlinked hook target outside the project was overwritten and its mode went 644 to 755, a dangling AGENTS.md link created a file outside, and a .workflow symlink redirected profile.yml; init exited 0.scripts/graph-blocked.sh (temp write and events.jsonl append) and scripts/graph-preflight.mjs (report write) append JSON lines, including operator-supplied --task text, through a symlink at .workflow/state/.... The revert records and graph-run-record.mjs already refuse a redirect.
Impact: integrity of any user-writable file, including making a planted file executable; with a .git/hooks target this can reach code execution on the next git operation (not probed).
Fix: resolve each destination and refuse it unless its real path stays inside the project root; open with O_NOFOLLOW/exclusive create where the file is new; never chmod through a link. Regression tests with planted symlinks for every write site.Source: NVD
Free Vulnerability Assessment
Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.
Get a personalized demo
"Best User Experience I have ever seen, provides full visibility to cloud workloads."
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
"We know that if Wiz identifies something as critical, it actually is."