AWS Security Digest

Monday,
April 27, 2026

🥖 Palette Cleanser

Cloud security vendors have conditioned us to focus on "attack paths" and they've often defined them as compute with some exploitable vulnerability that leads to data. Don't get me wrong, they are important. But what every red team knows is that the path of least resistance is often some developer's workstation or some engineer's creds on some SaaS platform. Then what matters is the privileges they have, the blast radius of their creds.

Vercel disclosed a security incident on 19 April 2026 after an attacker pivoted from a compromised third-party AI productivity tool (Context.ai) into an employee's Google Workspace account and from there into Vercel itself. The attacker enumerated and decrypted "non-sensitive" environment variables across a subset of customer accounts.

Any long-lived AWS access keys sitting in Vercel environment variables should be treated as exposed and rotated, and the same goes for any AWS creds you've handed to other SaaS platforms whose auth model is "OAuth + we hold your secrets". The durable mitigation would be OIDC federation so AWS hands out short-lived STS tokens to your build platform instead of you giving it static keys to lose for you. Even then, working on reducing the scope and need for identities and their access is something you can't forget.

Have feedback about AWS Security Digest? Tell us here. This issue is also available to share online.

📋 Chef's selections

How attackers exploited LMDeploy LLM Inference Engines in 12 hours by Sysdig

LMDeploy is an open-source LLM serving toolkit out of Shanghai AI Lab, and its chat-completion endpoint yolo fetches whatever URL you stuff into the `image_url` field, turning the model server into a server-side request forgery (SSRF) proxy. Within 13 hours of the CVE going public, a real attacker hit Sysdig's honeypot running LMDeploy and over the next 8 minutes pulled AWS IAM credentials off the metadata service, port-scanned Redis and MySQL for sport, then capped it off by hitting an admin endpoint that (naturally) had no auth at all. AI is shrinking time to patch windows to ~0.
Can AI Attack the Cloud? Lessons From Building an Autonomous Cloud Offensive Multi-Agent System by Yahav Festinger and Chen Doytshman

This isn't an AWS thing but there's a bunch in this post we can generalize. Researchers built a three-agent offensive AI system (infra, app, cloud specialists) and pointed it at a sandboxed GCP environment to see whether agents can pull off a real cloud attack without a human, and they did SSRF, metadata token, IAM enumeration, self-granted `storage.objectAdmin`, BigQuery exfil to a freshly minted bucket. When the agents weren't pwning your cloud, they were stuck doing dumb stuff, and fixating on irrelevant IPs.
Global S3: Another C2 Channel for AgentCore Code Interpreters by Nigel Sood

Bedrock AgentCore Code Interpreters run in "Sandbox mode" which, surprise, lets them reach any S3 bucket on the planet, including buckets owned by complete strangers in other AWS accounts. That's enough for a lazy command-and-control channel. Drop a command file in your attacker bucket, the sandbox polls for it, runs the thing, and PUTs the result back through a presigned URL. AWS already closed the DNS-based version of this trick. The S3 version is still wide open until you switch to VPC mode and lock S3 down with a Gateway Endpoint policy.

🥗 AWS security blogs

🍛 Reddit threads on r/aws

No threads this week.

💸 Sponsor shoutout

Meet Pleri: your AI security engineer. She’s not a chatbot. Pleri proactively finds meaningful security work and fixes issues before they become problems.

Learn more about Pleri and see her in action.

🥖 Palette Cleanser

📋 Chef's selections

🥗 AWS security blogs

🍛 Reddit threads on r/aws

💸 Sponsor shoutout

🤖 Dessert

🧁 IAM permission changes

🍪 API changes

🍹 IAM managed policy changes

☕ CloudFormation resource changes

🎮 Amazon Linux vulnerabilities

📺 AWS security bulletins

🚬 Security documentation changes