Railway breach turned stolen customer AI keys into $740,000 of fraud, and NEAR AI loses an inference server to an SGLang RCE

Update: GPUStack, the open-source GPU cluster manager for running LLMs, has a critical SAML authentication bypass (CVE-2026-102894, CVSS 9.1). The callback never validates the response, so anyone who can reach /auth/saml/callback can log in as any user, admin included, even with SAML turned off. What to do: upgrade to 2.2.2 now, and until then keep the GPUStack server off the public internet and rotate any model or cloud credentials stored in it.

Railway published its full report on the October 21 intrusion, and the headline is that the attacker came for AI keys. They escaped build isolation to grab a build credential, used it to pull Railway's source, found a misconfigured identity binding in the deploy pipeline, and reached a machine that could decrypt customer variables for up to about 100,000 workspaces (1.85%). Railway's own query logs show the attacker filtering for AI provider key names, and it puts unauthorized spend at roughly $740,000. Railway says it will cover Anthropic and OpenRouter costs that providers won't refund, while AWS and Google are refunding fraud and OpenAI reviews claims case by case. Linked GitHub OAuth tokens and bring-your-own agent keys for 1,852 users were also taken and have been reset.

What to do: if you deploy on Railway, rotate every AI provider key that ever sat in a Railway variable, check provider billing back to October 20, and file unexplained charges through Railway's form. My take is that this is the second platform breach in a few weeks where the prize was LLM keys, not customer data. Stolen keys get resold for distillation and burn real money fast, so put hard spend caps and per-project keys on every provider account. A PaaS env var is only as safe as the PaaS's build sandbox.

NEAR AI says an attacker exploited a remote code execution flaw in SGLang, the open-source inference engine, to run code on one of its inference servers on November 8. From there they reached about 100 users' account details, chat history and logs for 18 legacy agents, and two customers' API keys sitting in logs. NEAR is candid that the attacker could also see requests being processed on that box, including ones in confidential mode, because a TEE protects you from the host, not from a bug in the software running inside it. NEAR has reported the bug to SGLang, but there's no public advisory or CVE yet. What to do: if you run SGLang anywhere reachable, keep it off the internet behind an authenticated gateway, and watch the SGLang repo for a patch.

Microsoft Threat Intelligence and Microsoft Research showed that editing fewer than 10 rarely used neurons can turn an open-weight agent model into a sleeper that passes evaluations and then emits an attacker's command when a trigger string shows up. It needs only inference-grade compute, and Microsoft says it hasn't seen anyone use it in the wild. The useful part is the defense: diff every checkpoint against its declared base, since real fine-tunes change weights broadly while implants change a few rows by a lot. What to do: pull models only from the original publisher, verify hashes, and treat third-party merges, quants and adapters as untrusted until audited. Sandbox the agent and restrict its egress so a triggered command can't do much.

GitGuardian followed up on the Claude Code permission-file leak we covered last week with numbers that hurt more. It counted 31,088 distinct secrets pushed in .claude/settings.local.json on public GitHub, 5,343 of them valid at detection, mostly Postgres strings and SSH passwords. Another 99 valid secrets shipped in Docker Hub images through COPY . . builds. If your team uses Claude Code, add .claude/ to both .gitignore and .dockerignore, and rotate anything that ever landed in an allow rule.