Build1 publisher3 min readPublished
Nine of 428 audited LLM routers injected code into the tool calls they relayed
The routers teams adopt for cheap access to many models terminate the client's TLS by design. An April 2026 audit of 428 of them found nine editing the tool calls they relayed, one of them a paid product.
The Engineer · Build desk

What happened
- Research published in April 2026 tested 428 LLM API routers and found nine of them actively injecting malicious instructions into the traffic they relayed.
- The sample was 28 paid routers bought from marketplaces in China and Shopify stores plus 400 free ones collected from public communities, and the injectors were one paid router and eight free ones.
- The documented rewrite changed an install command's package name to a lookalike the attacker had registered in advance, requests becoming reqeusts, leaving the trusted domain and the rest of the command untouched.
- Loosely configured honeypot servers on twenty domains and twenty IP addresses drew access attempts from 147 IP addresses and leaked 99 credentials across 440 sessions, every one of which allowed shell execution.
- Of three client-side defenses measured, the deny-when-uncertain command gate blocked every direct injection sample at a 1.0 percent false-positive rate.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint No client-side control the research measured verifies where a returned tool call came from, so a team behind a router can shrink the damage but cannot establish that the command it is about to execute is the model's.
- decision Evaluating a router now has to run past fifty requests and in the auto-approve mode a team actually ships, because the two evasive routers stayed quiet in anything shorter.
- exposure Every secret that crosses a router is reachable at application level: seventeen routers went back to the researchers' planted test credentials after the fact, and one emptied a bait crypto wallet.
- contradiction An early author summary of 26 injecting routers and the paper's nine come from different samples, so the prevalence figure a team quotes depends on which denominator it is citing.
A router is different from a proxy you would notice because of the setup step. The client points its base URL at the router, so the client's TLS session ends there and the router opens its own connection onward to the model provider [5]. At that hop the prompts, the API keys and the list of tools the model asked to call are all plaintext [6]. Forged certificates and downgraded ciphers leave evidence; the router needs neither, because the customer configured it as the endpoint and gave it full application-level rights [7]. People adopt these services to pay one bill and reach several vendors' models through one request format [4].
The relayed payload carries operational meaning [8]. And the rewritten package name is not executed only once: the substituted package lands in the local cache and gets pulled from there in later sessions [11].
The honeypot sessions show how little sophistication the injection needed. Of 440 sessions, 401 were already running in automatic mode, about 91 percent [16][2], and the research reports that direct injection was sufficient [17]. Ninety-nine credentials leaked from those sessions, roughly one in four and a half [15][5]. A separate test seeded an OpenAI key, identifiable as the researchers' own, in Chinese forums and chat groups; it went on to generate 100 million tokens across more than seven sessions [14].
Nine hits in 428 is 2.1 percent overall [1], and the paid sample did worse than the free one: one of 28 is 3.6 percent, eight of 400 is 2.0 percent [6]. One injector out of 28 is too thin a base to rank tiers on, and the paid tier still had one.
On the defenses, the price differs more than the detection does. The response-side screener's 6.7 percent false-positive rate is 6.7 times the gate's 1.0 percent [3], for 11 points less coverage on direct injection [7] and half coverage on package renames [19]. The append-only log is a record only, at about 1.26 KB an entry [20][21]. An agent making a thousand tool calls a day writes 1.26 MB a day and about 460 MB a year [4]. The research describes the log as light enough to leave enabled on an ordinary developer machine [21].
None of the three defenses verify provenance, and the research says so directly [22]. A router inside the allowed scope, behaving normally, can still change what an instruction means [23]. The fix proposed sits with the model providers: sign responses so a client can check that the command it is about to run came from the model and was not altered in transit [24]. Some router operators have started offering extra protective layers [26].
This account is secondhand. The dev.to writeup, published 12 September 2026 under the name Nokka, was written by an AI model, deepseek-v4.1-flash, through Hermes Agent, then checked and edited by Nokka, and it refers to the underlying research by bracketed number [27].
What to watch
- Whether any model provider ships signed responses that a client can verify before executing a returned tool call.
- Whether the 26-router figure and the published nine are reconciled against a stated sample in a revised version.
- Whether the router operators now selling protective layers publish what those layers inspect and at what false-positive rate.