Critical Vulnerabilities in ASUS Routers Allow Remote Code Execution
Key Takeaways AI agent ecosystems are vulnerable due to malicious or compromised LLM API routers. These routers, acting as intermediaries, can inject malicious code, steal credentials, and exfiltrate...
Key Takeaways
- AI agent ecosystems are vulnerable due to malicious or compromised LLM API routers.
- These routers, acting as intermediaries, can inject malicious code, steal credentials, and exfiltrate cryptocurrency.
- Researchers from UC Santa Barbara uncovered these risks, demonstrating attacks that bypass current security measures.
- No major AI provider currently enforces cryptographic integrity for responses, leaving a critical security gap.
- Client-side mitigations are available, but a permanent solution requires provider-side cryptographic signing of responses.
The rapidly expanding ecosystem of AI agents faces a significant and often overlooked security risk: third-party LLM API routers. These crucial components, which facilitate communication between AI agents and large language model providers, can be exploited to surreptitiously hijack tool calls, drain cryptocurrency wallets, and exfiltrate sensitive credentials on a large scale.
Table Of Content
As AI agents increasingly take on critical functions—from executing code and managing cloud infrastructure to handling financial transactions—their reliance on these intermediary services, which route requests to providers like OpenAI, Anthropic, and Google, introduces a dangerous new attack vector.
The Unguarded Trust Boundary of LLM API Routers
A recent study, “Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain,” conducted by researchers from the University of California, Santa Barbara, highlights that these LLM API routers represent an unsecured trust boundary. Positioned between AI agent clients and upstream model providers, these routers function as application-layer proxies. This placement grants them complete plaintext access to all JSON payloads in transit.
Unlike traditional network man-in-the-middle attacks, which necessitate TLS certificate forgery, developers voluntarily configure these intermediaries as their API endpoints. The router effectively terminates the client-side TLS connection and initiates a new one upstream, allowing it to read, modify, or fabricate any tool-call payload without detection. A critical finding is that major AI providers currently lack mechanisms to enforce cryptographic integrity between the client and the upstream model, meaning there is nothing to prevent a malicious router from altering the exact command an agent executes.
Malicious Code Injection and Data Exfiltration
The UC Santa Barbara team conducted an extensive investigation, acquiring 28 paid routers from platforms such as Taobao, Xianyu, and Shopify-hosted storefronts, and collecting 400 free routers from public communities. Their findings revealed alarming vulnerabilities:
- Nine routers (one paid, eight free) were found to actively inject malicious code into returned tool calls.
- Seventeen free routers intercepted researcher-owned AWS credentials in transit, subsequently triggering unauthorized usage.
- One router successfully drained Ethereum from a researcher-owned private key.
- Two routers demonstrated adaptive evasion techniques, activating malicious payloads only after 50 prior requests or specifically targeting autonomous “YOLO mode” sessions running Rust or Go projects.
A particularly dangerous attack, classified as payload injection (AC-1), involves replacing a legitimate installer URL or package name with an attacker-controlled endpoint. This method is highly effective because the manipulated JSON payload maintains its syntactic validity, allowing it to bypass schema validation and most automated security checks. A single altered curl command can be sufficient to achieve arbitrary code execution on the client machine.
The threat extends beyond overtly malicious routers. The researchers also demonstrated that even seemingly benign routers can be compromised. In one instance, intentionally leaking a single researcher-owned OpenAI API key on Chinese forums led to the generation of 100 million GPT-5.4 tokens and exposed credentials across multiple downstream Codex sessions.
A second poisoning study involved deploying intentionally weak router decoys across 20 domains and 20 IP addresses. These decoys attracted 40,000 unauthorized access attempts, processed approximately 2 billion billed tokens, and exposed 99 credentials across 440 Codex sessions spanning 398 different projects. Critically, 401 of these 440 sessions were operating in autonomous “YOLO mode,” where tool execution is automatically approved without per-command confirmation, significantly amplifying the risk.
Mitigation Strategies
While the researchers acknowledge that no client-side defense can fully authenticate the origin of a returned tool call, they propose three immediate mitigations that can be deployed without requiring cooperation from AI providers:
- Fail-closed policy gate: This mechanism blocks all shell-rewrite and dependency-injection attacks with a 1.0% false positive rate by only permitting commands from a local allowlist. However, attackers could bypass it by hosting payloads on allowlisted domains.
- Response-side anomaly screening: Utilizing an IsolationForest model trained on benign tool-call patterns, this defense flags 89% of payload injection attempts with a 6.7% false positive budget.
- Append-only transparency logging: This system records comprehensive request/response metadata, TLS data, and response hashes, enabling forensic analysis after an incident. Each entry requires only about 1.26 KB of storage.
Ultimately, the research team asserts that closing this critical “provenance gap” requires major AI providers to implement provider-signed response envelopes. This mechanism, analogous to DKIM for email, would cryptographically bind the tool call executed by an agent to the upstream model’s authentic output. Until providers like OpenAI and Anthropic adopt such response-integrity measures, developers utilizing AI agents via third-party routers must treat every intermediary as a potential adversary and implement robust, layered client-side defenses.
What You Should Do
- Vet Third-Party Routers Carefully: Prioritize trusted and reputable LLM API router providers. Avoid using free or unverified routers.
- Implement Client-Side Defenses: Deploy fail-closed policy gates, response-side anomaly screening, and append-only transparency logging as described by the researchers.
- Monitor for Anomalies: Regularly review logs and network traffic for unusual activity, unauthorized credential usage, or unexpected tool calls.
- Limit Permissions: Configure AI agents with the principle of least privilege, ensuring they only have access to the resources and functionalities absolutely necessary for their tasks.
- Stay Informed: Keep abreast of the latest security research and recommendations regarding AI agent ecosystems and LLM supply chain security.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.