Phala Breach: OpenRouter Users Told to Treat DeepSeek Prompts as Exposed
If you sent prompts to DeepSeek V4 Flash 0731 through OpenRouter between 21 October and 8 November, one of the servers answering them was compromised.
Phala, a cloud provider that sells “confidential AI” on hardware-isolated GPUs, published a preliminary incident report late on 10 November. It tells users whose requests for that model were routed to Phala by OpenRouter to “treat request contents as exposed” for anything sent between 21 October 00:00 UTC and 8 November 05:35 UTC, and to rotate every API key, token or password those requests contained.
Phala didn’t spot this part of the breach itself. An outside security researcher had been planting unique fake credentials, so-called canaries, in requests to Phala since 1 July. Canaries sent on 21 and 22 October were later used by someone else.
What Phala Says Happened
All times are UTC and come from Phala’s report:
- 21 October: Phala’s precautionary exposure window starts at 00:00. The attacker reaches internal management interfaces on one server and installs malware.
- 21–22 October: the requests later confirmed as exposed are sent.
- 22 October, 05:41: the first misuse of stolen data.
- 4–5 November: another server is tampered with, and an unauthorised confidential virtual machine (CVM) is created.
- 5 November: Phala detects “unauthorized activity on one server” and contains that intrusion the same day.
- 6 November, 05:02: Phala rotates the root key of its key management system (KMS).
- 8 November, 04:12: the researcher’s evidence arrives. Phala traces it to an inference deployment on “a new GPU server”, which “was serving production traffic without our full production security hardening”. The server goes offline by 05:35.
- 9 November: the most recent misuse of stolen data that Phala has seen.
The way in, according to Phala, was a chain: “a legacy internet-facing service” plus management interfaces “that relied on loopback access for trust and did not independently authenticate callers”. In plain terms, internal tools trusted anything that talked to them from the same machine, so once the attacker was on the machine, they were trusted too. On the inference server, that gave the attacker control of the virtual machine running the model, “making in-flight request data visible during processing”.
Phala believes one attacker was behind both intrusions. It’s holding back exploit details until it publishes a full root cause analysis.
Who Needs to Do Something
Phala names two groups.
OpenRouter users of DeepSeek V4 Flash 0731. OpenRouter is a gateway that sends your request to one of several companies hosting the same model. Unless you told it otherwise, it picks the provider for you, weighing price, speed and reliability, according to its routing documentation. So you could have reached Phala without ever choosing it. If you used model ID deepseek/deepseek-v4-flash-0731 in the window and hadn’t excluded Phala, Phala advises two steps:
- Rotate every API key, token, password or other secret that appeared in those requests.
- Check the accounts those secrets belong to for activity you don’t recognise, and contact the provider if you find any.
Count the secrets a coding agent pulled in from your files, not only what you typed. Coding agents can reach more of your secrets than you’d expect.
OpenRouter’s Activity page shows whether you used the model in that period. If your app logs OpenRouter generation IDs, the generation endpoint returns the provider_name that served each request. Phala says OpenRouter is notifying affected users; we found no public notice on OpenRouter’s own website at the time of writing.
Phala Cloud customers with CVMs. The attacker created unauthorised CVMs on two servers and obtained application credentials, so secrets derived from Phala’s KMS may have leaked. Phala confirmed misuse of stolen credentials belonging to one customer and says it has contacted that customer. If you didn’t get a notice, Phala says no action is needed based on its current findings.
The report concerns Phala’s own deployment only. DeepSeek’s API and the other companies serving the model through OpenRouter aren’t part of it. When we checked OpenRouter’s public model list on 11 November, it showed 27 provider endpoints for DeepSeek V4 Flash 0731, and Phala wasn’t one of them.
"Confidential" Hardware, Ordinary Weak Spots
Phala’s pitch is that your data stays private even from the company running the servers. Its GPU page says workloads run in an Intel TDX confidential VM where “the runtime is sealed against the operator”. When Phala started serving models on OpenRouter in April 2025, it announced “Secure, Privacy & Verifiable LLMs with GPU TEEs”. This rests on trusted execution environments (TEEs), isolated areas of a processor that keep data encrypted while it’s being used.
The incident report doesn’t use the words TEE or attestation once. It doesn’t say whether the compromised inference server was running inside a TEE at all, and that’s the first question anyone paying for confidential inference will want answered.
Phala isn’t the only one in this spot this week. NEAR AI, another provider selling confidential inference, published its own incident report on 9 November. An attacker used a remote code execution flaw in SGLang, the open-source engine that runs its models, and on 8 November “could also have observed user requests being processed on the accessed server, including requests running in confidential mode”. NEAR spelled out the limit of the technology: “Confidential computing protects data from the operator and the host. It does not protect against a vulnerability in the software running inside the environment.” Neither company has linked the two incidents.
It’s also Phala’s third disclosed incident in just over five months. On 1 June it patched an API flaw that let an attacker plant a script on some customer CVMs, where it may have read decrypted environment variables. Between 8 and 12 October, an attacker exploited a bug in its dstack guest agent to read container logs and environment variables from a small set of customer apps, according to its October post-mortem.
None of the three reports describes the hardware isolation itself being broken. Each time, the attacker came in through the software around it: an API endpoint, a guest agent, management tools that trusted the local machine. An enclave is only as private as the plumbing someone bolts onto it.
Routing Settings Won't Save You From This
OpenRouter gives you real control over where your prompts go. You can exclude providers (ignore), allow only the ones you name (only), skip providers that may store your data (data_collection: "deny"), or require Zero Data Retention endpoints (zdr: true).
The last two are promises about what a provider keeps after answering you. They can’t stop an attacker who controls the server while your request is being processed, which is what Phala describes. An allowlist of providers you trust narrows the risk; it doesn’t remove it.
The safest secret is the one that never goes into a prompt. Keep API keys and .env files out of the folders your coding agent can read, give agents short-lived or narrowly scoped keys, and assume that anything you send to a hosted model could be read by someone other than the model.
What We Don't Know Yet
- How many OpenRouter users and requests were affected
- Whether the compromised inference server ran inside a TEE, and if so, how the attacker saw request data
- What the “legacy internet-facing service” was, and whether it’s related to the SGLang flaw at NEAR AI
- Who the attacker is, and what they did with the stolen credentials
- Whether OpenRouter has paused Phala as a provider
Phala says it will publish a full root cause analysis and update its report if the scope changes.
Our Mission
We believe security online security matters and its our mission to make it a safer place.