One writable folder can turn AI coding tools into cross-user access

At a glance

What this is: This is a Windows configuration trust issue in AI coding tools, where a writable system-default folder enables cross-user command execution and privilege escalation.

Why it matters: It matters because security teams now have to govern AI tooling like any other high-risk NHI, with attention to machine-wide defaults, endpoint hardening, and the command surface exposed to every user on a host.

👉 Read Cymulate's analysis of CVE-2026-35603 and AI coding tool trust failures

Context

AI coding tools often rely on system-wide configuration to keep developer experiences consistent across users and endpoints. In this case, the problem is not the model itself but a Windows trust boundary: a writable ProgramData location is being treated as authoritative for all users on the machine, which creates an identity and access control failure for AI coding tools.

When a low-privileged user can plant configuration that is later consumed by another user, the host becomes a cross-account execution path. For IAM and endpoint teams, the key issue is that a non-human identity control plane is being anchored to a directory that standard users can influence, which undermines the trust model before any prompt or command is even issued.

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. The break is not only file integrity. It is cross-user trust leakage, because the application treats attacker-controlled state as authoritative machine policy. That can lead to code execution, persistence and privilege escalation on shared Windows endpoints.

Q: Why do writable configuration paths increase risk for AI tooling on Windows?

A: They expand the trust boundary from the current user to every user who launches the tool. When a configuration file contains execution hooks or notify commands, one planted file can become a repeated trigger for arbitrary commands, including under administrator context. This turns endpoint configuration into a durable access path, not a simple preference file.

Q: How do security teams know if AI tool configuration is creating hidden execution risk?

A: Look for machine-wide settings stored in locations writable by standard users, especially if those settings control hooks, startup actions or shell commands. Then verify whether the application validates ownership, ACLs and file provenance before loading configuration. If it does not, the tool is effectively accepting untrusted runtime instructions from the host filesystem.

Q: Who is accountable when AI tooling uses a world-writable path for privileged behaviour?

A: Accountability sits with both the application owner and the endpoint governance team. The product team must avoid binding privileged behaviour to writable locations, while platform teams must harden the endpoint and restrict installation patterns. For regulated environments, this also falls under access control and secure configuration obligations in standard security frameworks.

Technical breakdown

Why a writable ProgramData path becomes a trust boundary failure

Windows uses C:\ProgramData\ for machine-wide data, but default permissions allow standard users to create new subdirectories and files. If an application does not create its own folder at install time and harden the ACLs, the first writer can define what later loads as the machine default. In these AI coding tools, that means configuration from an untrusted location is treated as trusted state for every user on the host. The control failure is not just file write access. It is the decision to bind security-sensitive behaviour to a directory whose integrity is not enforced.

Practical implication: pre-create and ACL-restrict all AI tool system-default paths so non-administrators cannot plant trusted configuration.

How event-triggered hooks turn configuration poisoning into code execution

The affected tools expose hooks or notify commands that run automatically on routine actions such as session start or an agent turn. Once the malicious configuration is loaded, the command executes in the context of the user who launched the tool, not in a sandbox or a constrained helper process. That makes the configuration file a runtime execution trigger rather than a passive settings file. Because the trigger is event-driven and not user-approved at execution time, the attacker does not need to wait for an explicit unsafe action. The workflow itself becomes the execution path.

Practical implication: treat hook and notify features as execution surfaces and monitor for unexpected child processes from AI CLI and IDE binaries.

Why cross-user defaults create persistence and lateral movement potential

A machine-wide file in ProgramData persists across logons and can affect every future launch by any user on the device. If the victim is an administrator, the same planted configuration becomes a local privilege escalation path. Even without admin execution, the attacker gains access to environment variables, source code, SSH keys and cloud tokens available to the victim session. That combination makes the issue more than a one-off code execution flaw. It is a durable foothold that can support credential theft and lateral movement from a developer endpoint into broader systems.

Practical implication: segment developer endpoints from privileged access and treat persistent AI tool configuration as a credential exposure risk.

Threat narrative

Attacker objective: The attacker aims to execute arbitrary commands under another user's security context and turn a local configuration weakness into persistence, credential access and possible administrator-level compromise.

1. Entry occurs when a low-privileged attacker creates the missing vendor directory under ProgramData and plants a malicious configuration file with no elevation required.
2. Escalation occurs when the tool loads the world-writable file as trusted machine-wide state and executes a hook or notify command under the next user's context, including an administrator's.
3. Impact occurs through cross-user code execution, durable persistence on every future launch, and exposure of credentials and environment data that can be used for further compromise.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cross-user configuration trust is the core failure mode here. These tools treated a writable system directory as authoritative machine state, which means any standard user could define behaviour that later affected every other user on the host. That is not just weak hardening. It is a broken assumption about where trust can safely originate in an NHI-style control plane. Practitioners should read this as a governance problem, not a patch-note event.

Machine-wide defaults in non-protected paths create identity blast radius. Once the same configuration is consumed by multiple users, the security boundary becomes the directory integrity, not the user session. A single planted file can influence administrators, developers and service contexts alike, which collapses the notion that one low-privileged account maps to one limited impact domain. The implication is that host-level AI tooling must be governed like shared infrastructure, not personal productivity software.

Configuration-driven hooks are effectively privileged execution surfaces. When hooks or notify commands fire automatically, the organisation is authorising runtime actions through configuration rather than through a visible approval step. That is a familiar NHI risk pattern: trust is delegated to a file, not to an identity policy. Security teams should assume that any system-wide trigger mechanism can become a high-value execution path if its source path is writable by standard users.

AI coding tools now sit inside the same identity governance perimeter as other non-human identities. They read defaults, execute commands and expose access to tokens and code assets, so they belong in NHI governance, endpoint hardening and privileged access review. The field should stop treating these tools as a narrow application security issue and start treating them as managed machine identities with a real blast radius.

Writable system defaults are a named concept worth tracking. They are benign only when the directory integrity is preserved. Once a standard user can write the file that determines machine-wide behaviour, the control assumption fails and the entire product inherits the weakest local account on the box. Practitioners should use this concept when auditing AI tooling, developer workstations and shared jump hosts.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For a broader view of how exposed non-human identities are exploited in practice, see 52 NHI Breaches Analysis and use it to benchmark where your own controls are most likely to fail.

What this signals

Writable-default risk should be added to AI tooling governance now: if a product consumes machine-wide configuration from a path that standard users can alter, it belongs in endpoint allowlisting, EDR detection and change control review. The operational question is no longer whether the tool can run commands, but whether it can be made to run attacker-defined commands from a shared host.

With 43% of security professionals already concerned that AI systems may learn and reproduce sensitive information patterns from codebases, per The State of Secrets in AppSec, the next governance step is to separate model risk from host trust risk. The latter is easier to miss because it looks like ordinary configuration management until it becomes an execution path.

Teams should map AI coding tools into the same lifecycle controls they already use for service accounts and other non-human identities. That means installation governance, path hardening, execution monitoring and review of where the tool can reach secrets, source code and privileged sessions.

For practitioners

• Pre-create and ACL-restrict every AI tool system-default path Use Group Policy or endpoint management to create the relevant ProgramData subdirectories at install time and restrict write access to SYSTEM and Administrators only. Do not rely on application defaults to secure the directory after deployment.
• Monitor for configuration poisoning on developer endpoints Alert when non-administrative users create or modify managed-settings.json, hooks.json, config.toml or system-defaults.json, and correlate those writes with child-process creation by AI CLI and IDE processes.
• Block high-risk AI tooling from privileged contexts Prevent AI coding tools from running under administrative accounts or with access to production credentials, and isolate them from sessions that can reach SSH keys, cloud tokens or deployment material.
• Treat hook and notify features as execution channels Review any configuration-driven command execution in AI tooling as a privileged control surface. If the feature can launch shells or child processes, instrument it in the SIEM and EDR as though it were a managed script runner.

Key takeaways

• AI coding tools can turn a writable ProgramData folder into cross-user code execution if configuration trust is not enforced at the host level.
• The article shows that a single planted file can persist across users, elevate privileges and expose credentials on shared Windows endpoints.
• The relevant control is not just patching the app, but hardening system-default paths, restricting execution features and monitoring child processes from AI tooling.

Key terms

• Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.
• Cross-User Code Execution: A condition where one user can influence commands that run in another user's session on the same host. It matters here because the malicious configuration file is loaded as a system default, so the attack affects whoever launches the tool, not just the original writer.
• Execution Primitive: A configuration feature that causes software to run a command or shell action when a defined event occurs. In this case, hooks and notify commands convert configuration into runtime execution, which is why a poisoned file becomes a code execution path rather than a harmless preference.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full report

Cymulate's full blog covers the operational detail this post intentionally leaves for the source:

• Tool-by-tool configuration paths and execution primitives for Claude Code, Cursor, Codex CLI and Google Gemini CLI.
• Step-by-step exploitation flow showing how a standard user plants the malicious file and triggers cross-user execution.
• Vendor-specific remediation status, including which products were fixed, unresolved or handled as documentation updates.
• Recommended endpoint hardening and validation scenarios for detecting configuration poisoning in production-safe testing.

👉 Cymulate's full post covers the attack chain, affected tools, and endpoint mitigations in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.