Security

AWS Lambda's /tmp Directory Isn't as Clean as You Think

Assuming every Lambda invocation runs in a fresh, isolated environment is a very reasonable guess. It’s also wrong. Hi everyone 👋 A lot of developers write Lambda functions on the assumption that each invocation starts in a completely clean, isolated sandbox — new environment, empty disk, nothing left behind from whatever ran before. That assumption is exactly what “serverless” seems to promise. It isn’t quite what happens. 🔍 What’s actually happening: warm starts To keep invocations fast, Lambda reuses the same underlying execution environment (container) for consecutive invocations whenever it can — this is a warm start, as opposed to spinning up a brand-new one from scratch (a cold start). Reusing the container is exactly what makes warm invocations fast.

Sunday, August 2, 2026 Read

The IMDSv2 Hop Limit Trap When Running Containers on EC2

Switching to IMDSv2 is the right security move, full stop. Do it on an EC2 instance running Docker containers, though, and the app inside loses access to its IAM Role credentials immediately. Hi everyone 👋 Upgrading from IMDSv1 to IMDSv2 is standard, correct security guidance — it closes off a real class of credential-theft attacks against the EC2 instance metadata service. But flipping that switch on an instance that runs its application inside a Docker container can break AWS SDK access instantly, with no obvious explanation in the error message.

Saturday, August 1, 2026 Read

iam:PassRole + Wildcard: The Privilege Escalation Hiding in Plain Sight

A developer account with nothing but lambda:CreateFunction and a wildcard iam:PassRole can walk itself up to full Administrator — no exploit, no misconfigured bucket, just permissions doing exactly what they were asked to do. Hi everyone 👋 This one doesn’t show up as a vulnerability scan finding or a CVE — it’s a permissions grant that looks completely reasonable in a policy review, right up until someone connects the dots. 😱 The convenient habit To make deployments easier, it’s extremely common to grant developer accounts iam:PassRole against * (a wildcard covering every role in the account). The reasoning is simple and, on its own, sounds harmless: developers need to attach an IAM role to whatever they deploy — a Lambda function, an EC2 instance — and wildcarding PassRole means nobody has to update a policy every time a new role gets created.

Saturday, August 1, 2026 Read