Loading story…
A documented AWS attack path shows how an attacker can escalate privileges by combining SSRF, exposed EC2 instance credentials, and a misconfigured CodeBuild project that reads its buildspec from an attacker-writable S3 bucket. In the reported scenario, the attacker first used Server-Side Request Forgery against an EC2 instance’s IMDSv1 metadata service to obtain temporary AWS credentials, then enumerated access and found permissions including codebuild:StartBuild and s3:PutObject.
Without needing iam:PassRole or permission to modify CodeBuild projects directly, the attacker altered the S3-hosted build specification and triggered a new build, causing arbitrary commands to run on the CodeBuild worker. That execution exposed the worker’s AWS credentials, which inherited the project’s assigned role and in the described case led to a more privileged role with iam:* permissions. The technique highlights how cloud misconfigurations can turn limited access into broad account compromise, and underscores mitigations including least privilege, tighter S3 and CodeBuild controls, and use of IMDSv2 to reduce SSRF impact on EC2 instances.
Map this exposure pattern across your cloud, code, and identities.
4 events from the most recent confirmed update back to the earliest known activity.
From the resulting shell on the CodeBuild worker, the attackers retrieved the worker's AWS credentials, which inherited the project's assigned role. In the reported case, this led to a more privileged role with iam:* permissions.
The attackers abused an attacker-writable S3 bucket used by a CodeBuild project for its buildspec, injecting commands into the buildspec file and then starting a build. This caused arbitrary code to execute in the context of the CodeBuild worker.
After enumerating permissions, the attackers found access to S3 and CodeBuild but could not create or update CodeBuild projects and did not have iam:PassRole. These constraints led them to look for an alternate privilege-escalation path.
In the described assessment, initial AWS credentials were obtained from an EC2 instance by exploiting SSRF against the IMDSv1 metadata service. This gave the attackers a foothold to enumerate the environment's AWS permissions.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See where this exposure pattern shows up across your cloud, code, supply chain, and non-human identities.
3 references tracked. Mallory keeps watching after this page renders.
owasp.org
Open sourceaws.amazon.com
Open sourceshielder.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Security researchers at **Wiz** disclosed a critical **AWS CodeBuild** misconfiguration (dubbed **CodeBreach**) that could have enabled unauthenticated attackers to trigger CI builds from untrusted pull requests, access the build environment, and exfiltrate privileged credentials such as **GitHub admin tokens**. With those tokens, an attacker could have pushed malicious commits into AWS-managed open-source repositories—creating a high-impact **software supply chain** pathway that could have cascaded into widespread compromise, including risk to dependencies like the **AWS JavaScript SDK** and potentially components used by the **AWS Console** itself. AWS was notified on **2025-08-25** and remediated the issue in **September 2025**. The root cause was described as a weakness in CodeBuild’s webhook filtering logic intended to restrict which events/users can trigger builds; affected repositories used an `ACTOR_ID` regex filter that omitted the `^` and `$` anchors, allowing bypass of the intended match constraints. Reported impacted AWS-managed GitHub repositories included `aws-sdk-js-v3`, `aws-lc`, `amazon-corretto-crypto-provider`, and `awslabs/open-data-registry`, all configured to run builds on pull requests. Separate reporting on abuse of **self-hosted GitHub Actions runners** as backdoors (including the **Shai-Hulud** worm technique) is related at a thematic CI/CD level but does not describe the CodeBuild misconfiguration or the AWS repository takeover scenario.
Jun 29, 2026
Sysdig reported observing an offensive operation against an **AWS** environment in which a threat actor progressed from initial access to **administrative privileges in under 10 minutes**, with multiple indicators suggesting **large language models (LLMs)** were used to accelerate reconnaissance, code generation, and decision-making. Initial access was obtained via **valid credentials exposed in public S3 buckets**, reportedly associated with AI/RAG-related data and an IAM user used to automate *Amazon Bedrock* tasks via *AWS Lambda*. The actor then escalated privileges via **Lambda function code injection**, moved laterally across **19 AWS principals**, and abused *Amazon Bedrock* in an **LLMjacking** pattern while also provisioning **GPU-capable compute instances** for suspected model-related activity. Dark Reading’s coverage echoed Sysdig’s findings, emphasizing the speed of the compromise, the role of AI as a force multiplier, and post-compromise activity including **data collection/exfiltration** and **GPU instance provisioning**. In contrast, TechTarget’s “must-have security technologies” piece and SecuritySenses’ discussion of borrowing financial risk models for security are **general guidance/trend** articles and do not describe this specific intrusion or provide incident-specific technical details, making them non-contributory to the reported AWS compromise.
Jun 29, 2026
AWS documented an incident-response scenario in which an attacker exploited a server-side request forgery (SSRF) flaw in an EC2-hosted web application to retrieve temporary credentials for the instance's attached `webdev` IAM role through IMDSv1. The attacker enumerated the role's permissions, established an AWS Management Console session without MFA, pivoted from `us-east-1` to `us-east-2`, and enumerated Amazon Bedrock foundation models. The actor then invoked Amazon Nova Pro through the Converse API, resulting in unauthorized token consumption. The activity was enabled by IMDSv1 exposure, an overprivileged EC2 role with unnecessary cross-Region Bedrock permissions, and missing MFA, with inconsistent regional logging and controls potentially limiting detection. AWS advises remediating the SSRF flaw, requiring IMDSv2 for EC2 metadata access, revoking and investigating use of the compromised role, reviewing CloudTrail across all Regions, restricting Bedrock permissions, and enabling Bedrock model-invocation logging to determine whether prompts or generated outputs were exposed.
Sep 5, 2026