Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

AI coding tools and writable ProgramData folders: are your controls keeping up?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 13010
Topic starter  

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.

NHIMG editorial — based on content published by Cymulate covering CVE-2026-35603: one writable folder, every user compromised through AI coding tool configuration trust

Questions worth separating out

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 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.

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.

Practitioner guidance

  • 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.
  • 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.

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.

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

AI coding tools and writable ProgramData folders: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 12594
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: One writable folder can turn AI coding tools into cross-user access



   
ReplyQuote
Share: