CVE-2026-25725 is a sandbox protection gap in Claude Code before 2.1.2, scored 10.0. If .claude/settings.json did not exist at startup, code inside the bubblewrap sandbox could create it and add hooks that run with host privileges on restart. Version 2.1.2 fixes it.
What's affected
- Product: Claude Code (npm package @anthropic-ai/claude-code) using its bubblewrap sandbox.
- Affected: versions before 2.1.2.
- Fixed: 2.1.2.
- Condition from the advisory: the .claude/settings.json file was missing when Claude Code started.
How to check if you're exposed
Check the installed version and whether projects have the file:
claude --version
ls -l .claude/settings.json .claude/settings.local.json
Also open any settings.json that appeared unexpectedly and read the hooks section. SessionStart style hook entries you did not add should be treated as suspicious.
What to do now
- Update Claude Code to 2.1.2 or later.
- Inspect .claude/settings.json in each repository you used with sandboxing, and remove hooks you do not recognise.
- Create a reviewed settings file ahead of time so the file exists when the tool starts, as a defence in depth habit.
- Do not run untrusted code even inside a sandbox on a machine that holds production credentials.
- Rebuild shared images and devcontainers with the fixed version.
Why it matters
The record lists CWE-501, trust boundary violation, and CWE-668, exposure of a resource to the wrong sphere. The parent folder was writable and settings.local.json was protected read only, but the sibling settings.json was not protected when absent, so the sandbox could author configuration that the unsandboxed tool later trusted.
This is a lesson about sandboxes in general: whatever the sandbox can write and the host later reads is a path out. Hooks are commands, so planting one means code runs outside. The record does not mark this CVE as exploited in the wild, and the advisory credits a HackerOne reporter.
How to prioritise the fix
Anyone who relies on the bubblewrap sandbox as a safety boundary should take this seriously, because it was the boundary itself that had a gap. The advisory describes malicious code inside the sandbox creating a settings file that the unsandboxed tool later honoured.
Start with the update to 2.1.2. Then review settings files in projects where the sandbox ran code you did not write, looking for hook entries. A hook that runs a command at session start is exactly what you would expect an attacker to plant, so unknown entries deserve a closer look.
For longer term safety, treat everything a sandbox can write as untrusted input to the host. Create and lock down configuration files ahead of time, and keep production credentials off machines that run unreviewed code.
Quick check
Why does a missing file matter?
Protections were applied to files that existed. A file that was absent had no read only mount over it, so the sandbox could create it.
Sources
Last reviewed: 19 October 2026.
