boringproxy authorized_keys Newline Injection Privilege Escalation

Technical Analysis

The vulnerability stems from insufficient sanitization of the domain parameter in boringproxy's tunnel creation API, which fails to reject percent-encoded newline characters (%0A). Attackers with only tunnel-creation permissions can craft a request that injects an arbitrary line into the server account's ~/.ssh/authorized_keys file, effectively adding their own attacker-controlled public key. This grants passwordless SSH access to the host running boringproxy, from which the attacker can read the local database file containing cleartext user tokens, tunnel private keys, and TLS certificates, enabling further lateral movement and impersonation of legitimate tunnels. Because boringproxy is commonly used to expose self-hosted services (including internal dashboards, APIs, and development environments) to the internet, compromise of the proxy host can cascade into full network exposure. Organizations that use boringproxy to expose AI agent orchestration endpoints, RAG pipeline APIs, or LLM tool-use backends are directly at risk: theft of tunnel private keys and TLS certificates could allow attackers to intercept or hijack agent-to-tool communications, and stolen credentials/tokens could be reused to access connected AI service API keys, exposing agent infrastructure to further compromise.

Affected Systems

boringproxy versions through 0.10.0, specifically deployments running the tunnel creation endpoint with the domain parameter accepting percent-encoded input; any host running the boringproxy server process with SSH access configured via authorized_keys

Indicators of Compromise

• Unrecognized/unauthorized entries in ~/.ssh/authorized_keys on boringproxy server hosts
• Unexpected SSH logins to boringproxy host from unknown source IPs
• Modified or accessed boringproxy database file (typically containing tokens, tunnel keys, and TLS certs)
• Anomalous tunnel creation requests containing %0A or encoded newline sequences in the domain parameter

Remediation Steps

1. 1

   Upgrade boringproxy

   Update to a patched version of boringproxy beyond 0.10.0 once available, or apply vendor-provided hotfix/mitigation.

2. 2

   Audit authorized_keys files

   Immediately inspect the server account's authorized_keys file for unauthorized or unrecognized public key entries and remove them.

3. 3

   Rotate credentials and keys

   Rotate all user tokens, tunnel private keys, and TLS certificates stored in the boringproxy database, assuming they may have been exposed.

4. 4

   Restrict tunnel-creation permissions

   Limit which users can create tunnels and enforce strict input validation/allowlisting on the domain parameter at a network proxy or WAF layer as a temporary compensating control.

5. 5

   Monitor SSH access logs

   Review SSH authentication logs on the boringproxy host for unexpected logins or key-based authentication events correlating with the vulnerability window.

6. 6

   Isolate boringproxy hosts

   Ensure boringproxy servers are not co-located with sensitive AI agent, RAG, or LLM infrastructure, and segment network access to limit blast radius if compromised.