Topic starter
01/08/2026 9:00 pm
TL;DR: A single writable ProgramData folder can let a low-privileged user plant configuration that runs commands inside other users’ AI coding tool sessions, including administrators, across Claude Code, Cursor, Codex CLI and Google Gemini CLI, according to Cymulate Research Lab. The failure is a trust model built on machine-wide defaults in a directory standard users can alter.
Editorial analysis by NHI Mgmt Group, based on content published by Cymulate: “CVE-2026-35603: One Writable Folder, Every User Compromised: Exploiting Configuration Trust in AI Coding Tools”.
Key questions
Q: What breaks when AI coding tools trust writable system-default folders?
A: A writable system-default folder lets a low-privileged user define configuration that later executes in other users’ sessions.
Q: Why do writable default settings increase cross-user risk in AI coding tools?
A: Because the application treats the shared file as authoritative for every account on the machine.
Q: What are the signs that AI tool configuration poisoning is happening?
A: Look for non-administrative creation of vendor-specific configuration files in ProgramData, unexpected child processes spawned by AI CLI or IDE executables, and sessions that behave differently without an approved configuration change.
Practitioner guidance
- Inventory AI coding tools on Windows endpoints Identify where Claude Code, Cursor, Codex CLI, Google Gemini CLI and similar tools are installed, then classify which endpoints expose shared configuration paths.
- Pre-create and restrict shared configuration folders Use Group Policy or configuration management to create the relevant ProgramData subdirectories with tight ACLs so only SYSTEM and Administrators can write them.
- Alert on non-administrative writes to managed config files Monitor creation or modification of managed-settings.json, hooks.json, config.toml and system-defaults.json by standard users, then route those events to the SIEM.
Bottom line: A writable shared configuration path can let a low-privileged user redirect AI coding tool execution into another user’s session.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 9:06 pm
Cross-user configuration trust is the real failure mode: these tools treated machine-wide defaults as trustworthy even when a standard user could create them. That assumption belongs to a world where shared configuration is controlled by administrators, not a world where user-writable directories are loaded as authoritative execution inputs. The implication is that desktop AI tooling now needs explicit trust validation for configuration provenance, not just functional settings handling.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should teams respond when an AI coding tool stores trust settings in ProgramData?
A: Treat the path as a privileged control surface, not a convenience folder. Restrict who can create vendor directories, pre-stage secure ACLs, remove administrative use where possible, and verify that logging captures both writes to the configuration file and any downstream shell execution.
👉 Read our full editorial: One writable folder can turn AI coding tools into cross-user access