The patch window closed. The registry pushed back.
LiteLLM went from GitHub Advisory Database index to honeypot exploitation in 36 hours, pnpm 11 added a 24-hour default delay before brand-new packages resolve, and the Context.ai to Vercel chain showed why OAuth grants need the same default friction as package installs.
> download one-pager (PDF)> New here? Get next Tuesday's issue in your inbox.
🎯 Attack of the Week
How the LiteLLM auth bypass runs. An attacker hits an internet-facing LiteLLM proxy with POST /chat/completions and a Bearer value that breaks out of the key lookup query, for example Authorization: Bearer sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM "LiteLLM_VerificationToken"--. Because LiteLLM mixed the Bearer value into the SQL instead of parameterizing it, the attacker can probe column count, match the underlying query shape, and pull back rows from LiteLLM_VerificationToken, litellm_credentials, and litellm_config.
The piece to sit with is the timeline. April 20, 21:14 UTC: GHSA-r75f-5x8p-qvmc published on the LiteLLM repo. April 24, 16:17 UTC: indexed in the global GitHub Advisory Database. April 26, 04:24 UTC: Sysdig's honeypot logs the first exploitation attempt. 36 hours, 7 minutes from index to weaponization. Source IPs 65.111.27.132 and 65.111.25.67 (AS200373, 3xK Tech, Germany). User-agent Python/3.12 aiohttp/3.9.1, empty or 75-byte POST body, Bearer header containing UNION SELECT. A patch window measured in days does not survive that timeline.
If LiteLLM is in your stack, upgrade to v1.83.7+ this week. If you cannot patch immediately, set general_settings.disable_error_logs: true now (per the advisory, this stops the in-band leak), then put the proxy behind NGINX or Envoy and block Authorization headers containing ', (, ), UNION, SELECT, FROM, OR, or --. Then rotate every virtual key, master key, and provider credential the instance ever held, grep access logs for sk-litellm', and audit provider billing for unexpected /chat/completions use.
🚨 Rule of the Week
pnpm 11 ships two defaults that change the worm-class attack math: minimumReleaseAge=1440 (a 24-hour delay before a newly published version resolves) and blockExoticSubdeps=true (transitive deps from git or tarball sources are refused unless explicitly allowed). A new allowBuilds model replaces the older lifecycle-script settings. The point is simple: the highest-risk window for a malicious package is the first few hours after publish, and pnpm 11 now makes teams opt out of that delay instead of opt in.
If you use pnpm, upgrade and leave the defaults on. If you use npm or yarn, you do not get the same control out of the box. Recreate it in your private registry or CI wrapper by blocking package versions published in the last 24 hours, and make exceptions explicit instead of silent.
🔧 Defender's Corner
Read it in full. The chain he documented: Context.ai was reportedly compromised, the attacker reused OAuth tokens stored in Context.ai's Supabase platform, and a broad https://www.googleapis.com/auth/drive grant on Context.ai's OAuth app (110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com) exposed downstream Google Workspace accounts, including a Vercel employee account. Monday: open Google Admin -> Security -> Access and data control -> API controls, review that client ID, and decide whether Don't allow users to access any third-party apps should be your default for unconfigured apps. Then audit every existing third-party app with Drive, Mail, or Calendar scope.
The post argues short TTL alone is not the answer (5 to 15 minutes for user-facing, 15 to 60 for background, 1 to 6 hours for autonomous, all with the same caveats: refresh failures cause partial writes, vault availability becomes a single point, and the long-lived "exception" credential drifts into the default). The actual control is per-task and per-stage scoping, not just shorter expiry.
Same lesson, different surface: fast attacker execution matters more when old grants still exist and broad credentials still work. OAuth scopes and agent credentials both need narrower scope, shorter lifetime, and an explicit approval path.
Monday export. Download the Configured apps and Accessed apps CSVs from Google Admin -> Security -> Access and data control -> API controls this week, then flag every OAuth client with Drive, Mail, or Calendar scope that lacks a current owner.
📡 Also on the Radar
Markov-chain analysis trained on 8,000 passwords across 40 LLMs identifies AI-generated passwords with 55% model-attribution accuracy and 65% provider attribution. GitGuardian found 28,000 such passwords in a 34M-password GitHub sample from 2025-11 to 2026-03, with Anthropic, Qwen, and Google the top three attributions. Same control theme as the rest of this issue: if AI tooling is allowed to mint reusable secrets, make those secrets short-lived and narrow-scoped before statistical bias turns into reusable access.