Monday,
March 30, 2026

🥖 Palette Cleanser

This week's big story is one of the best credential cascade attacks I've seen in a while. The threat actor TeamPCP started with a single set of stolen CI/CD credentials from the Trivy security scanner (yes, the security tool), and then proceeded to use those credentials to hop across the open source ecosystem. Trivy on March 19, the Checkmarx KICS GitHub Action on March 23 (35 tags hijacked in under four hours), LiteLLM on PyPI on March 24, and Telnyx on March 27. Each compromise fed the next. Wiz's analysis of the LiteLLM malware found that versions 1.82.7 and 1.82.8 contained a payload that harvested AWS credentials, SSH keys, Kubernetes tokens, and cloud credentials, while Datadog traced the full campaign back through the CI/CD chain to the original Trivy compromise. With LiteLLM pulling 95 million monthly downloads and deployed in an estimated 36% of cloud environments according to Wiz telemetry, this wasn't a niche hit. LiteLLM CEO Krrish Dholakia and CTO Ishaan Jaff published a rapid response, paused all new releases, rotated credentials, and brought in Google's Mandiant team for forensic analysis, which is a mature response to an incident that most projects would quietly bury. One fun detail buried in the malware is the backdoor's kill switch is triggered if the C2 server returns the string "youtube.com." The internet ruins everything, including attack infrastructure.

Back in early March, AWS's ME-CENTRAL-1 region went down after what the status page initially called "a localized power issue." The updated explanation was that "objects struck the datacenter, creating sparks and fire." AWS never disclosed what the objects were or where they came from, though given the timing and location - UAE, during the Iran conflict - the likely cause wasn't hard to guess. Anyway, if you enjoy informed gossip, an AWS SRE shared more details on Instagram.

AWS also announced general availability of visible services and visible regions account settings in the Management Console, letting you hide services and regions your team doesn't use. Worth noting, as Ian McKay pointed out, this is not a security control. The Console fetches these customizations from uxc.us-east-1.api.aws client-side, so blocking that request in a browser restores full visibility. Treat it as a UX convenience for reducing noise, not a guardrail. IAM is still doing the actual work.

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

📋 Chef's selections

  • "But without PassRole it should be fine", Lambda edition by Daniel Grzelak

    The conventional wisdom is that iam:PassRole is the gatekeeper for privilege escalation via Lambda. If an attacker doesn't have it, they can't assign a more privileged execution role. I wrote up two smooth ways to make that assumption wrong. With only lambda:UpdateFunctionConfiguration, an attacker can attach a cross-account malicious layer and either drop an executable into /opt/extensions/ (which Lambda auto-runs during the Init phase as a Lambda Extension) or set AWS_LAMBDA_EXEC_WRAPPER to a wrapper script that runs before the runtime starts. Either way, code executes under the target function's role with zero changes to the handler, so nothing in your code diff or UpdateFunctionCode alerts fires. One of these was already abused for persistence in Stratus Red Team

  • Local File Inclusion in AWS Remote MCP Server via CLI Shorthand Syntax by Coby Abrams

    Coby found a Local File Inclusion vulnerability (CVE-2026-4270) in the official AWS Remote MCP Server that bypasses the FileAccessMode=NO_ACCESS security setting entirely. The AWS CLI has a built-in feature for loading local file contents into command parameters, and the MCP server passes these commands through without sanitizing inputs. Point it at a sensitive file, let the command error, and the file contents come back in the error message. It was reproducible against AWS's own hosted endpoint at aws-mcp.us-east-1.api.aws. AWS patched it in version 1.3.9. If you're running the MCP server or any forks of it, update now.

  • AWS Keeps Breaking Its Own Trust Boundaries by Daniel Grzelak

    This quick analysis of 20 AWS security bulletins from October 2025 to March 2026 found that trust boundary failures are the dominant vulnerability class, not memory corruption or crypto bugs. Seven of the twenty bulletins fit the pattern. Something assumes a principal is trustworthy when it isn't, and privilege escalation or lateral movement follows. The examples are instructive: an EKS provisioning role with arn:aws:iam::ACCOUNT:root in its trust policy, a SageMaker read-only API that leaked HMAC signing keys enabling forged payloads, and so on. The main point is that a permission's danger isn't determined by its IAM action name but by what it can reach through credential chains, resource-based policies, and service integrations. If AWS keeps making this mistake in its own services, your environment almost certainly has the same patterns.

🥗 AWS security blogs

🍛 Reddit threads on r/aws

    No threads this week.

💸 Sponsor shoutout

Pleri logo

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.

🤖 Dessert

Dessert is made by robots, for those that enjoy the industrial content.

🧁 IAM permission changes

🍪 API changes

🍹 IAM managed policy changes

    No changes this week.

☕ CloudFormation resource changes

🎮 Amazon Linux vulnerabilities

📺 AWS security bulletins

    No bulletins this week.

🚬 Security documentation changes

YouTube Twitter LinkedIn

Crafted with ❤️ by Plerion. We simplify cloud security.