# Arbitrary Write to SSH Authorized Keys or Shell Startup File via Unvalidated File-Edit Tool

- **Severity:** Critical
- **Signature ID:** `25146304-07fd-4d56-a83a-8b16fe1eebce`
- **MITRE ATLAS:** AML.T0053 (AI Agent Tool Invocation)
- **OWASP:** ASI02 (Tool Misuse and Exploitation), LLM08 (Vector and Embedding Weaknesses)

## Summary

An AI agent with file-editing capabilities can be prompted to write a stranger's SSH public key into a user's authorized_keys file, or to sneak a writable temp directory onto the system PATH inside a shell startup file. Both moves let an attacker keep long-term access to a machine even after the original entry point is closed.

## How the attack works

An attacker crafts a prompt that instructs the agent to use a file-write or file-edit tool (such as multiedit, write_file, apply_diff, or patch) that lacks path validation or protected-path checks. The agent is directed to append an attacker-controlled SSH public key to ~/.ssh/authorized_keys, granting remote login without a password. Alternatively, the agent is told to edit a shell startup file (~/.bashrc, ~/.zshrc, ~/.profile, ~/.bash_profile) so that a world-writable directory like /tmp, /var/tmp, /dev/shm, or ~/.cache is placed at the front of PATH. Once that happens, any command the user runs which happens to share a name with a file the attacker drops in that directory will execute the attacker's code instead of the real program. Both techniques give the attacker persistence that survives beyond the initial compromise.

## Why it matters

An organization loses control over affected accounts and machines: the attacker gains a standing remote-access channel via SSH or silent code execution triggered by normal command use, and this access typically persists until someone manually inspects and cleans these files.

## What you can do

- Restrict which directories and files any file-write/edit tool used by an AI agent is allowed to touch, explicitly blocking ~/.ssh and shell startup files unless a human approves the change.
- Review ~/.ssh/authorized_keys and shell rc files for unexpected entries, especially PATH additions pointing to /tmp, /var/tmp, /dev/shm, or ~/.cache.
- Require explicit human confirmation before an agent modifies SSH configuration or shell startup files, even when the request appears to be self-provisioning.
- Monitor for PATH modifications that place writable/temporary directories ahead of standard system paths.

## Known benign look-alikes

- Adding a normal alias, function, or env-var export to a shell rc file
- Legitimate PATH additions pointing at project-local bin/ or language-version-manager (nvm/pyenv/rbenv) directories, not /tmp or /dev/shm
- An operator provisioning their OWN SSH key via cloud-init/Ansible/bootstrap onboarding, expressed with first-person framing ("my own", "my key", "myself", or a "me@<host>" key comment) -- this rule now requires the request to NOT carry that self-referential framing before firing, since routine self-provisioning is common and an attacker planting a foreign key has no reason to frame it as the requester's own

## References

- https://agentthreatrule.org/en/rules/ATR-2026-02040

---
Source: https://www.netzilo.com/threats/atr-arbitrary-write-to-ssh-authorized-keys-or-shell-startup-file