Loading story…
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.
Map this exposure pattern across your cloud, code, and identities.
5 events from the most recent confirmed update back to the earliest known activity.
The webdev role invoked the Amazon Nova Pro model (amazon.nova-pro-v1:0) through the Bedrock Converse API in us-east-2. The unauthorized invocation consumed 944 input tokens and generated 126 output tokens.
Using the previously established console session, the webdev role called Amazon Bedrock ListFoundationModels in us-east-2, conducting read-only reconnaissance in a different AWS Region.
The assumed webdev role successfully performed a ConsoleLogin in us-east-1 from IP address 75.3.231.105 using a Windows 10 browser. The login recorded MFAUsed as "No" and mfaAuthenticated as false.
The assumed webdev role attempted to create an IAM user named "adm1n" in us-east-1 using AWS CLI. AWS denied the CreateUser request because the role lacked iam:CreateUser permission.
A threat actor exploited an SSRF vulnerability in an EC2-hosted web application to access IMDSv1 and obtain temporary credentials for the instance's attached webdev IAM role.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. See the values in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
See where this exposure pattern shows up across your cloud, code, supply chain, and non-human identities.
4 references tracked. Mallory keeps watching after this page renders.
infosec.pub
Open sourceinfosec.pub
Open sourceaws.amazon.com
Open sourcedocs.aws.amazon.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.
Attackers have exploited a server-side request forgery (SSRF) vulnerability in the Pandoc Linux utility, identified as CVE-2025-51591, to target the Amazon Web Services (AWS) Instance Metadata Service (IMDS) and steal EC2 IAM credentials. The flaw, which has a CVSS score of 6.5, allows threat actors to inject specially crafted HTML iframe elements into Pandoc, enabling them to direct requests to the IMDS endpoint. By leveraging this SSRF vulnerability, attackers can harvest temporary AWS credentials from EC2 instances without requiring direct host access, such as remote code execution or path traversal. The IMDS is a critical AWS component that provides metadata and temporary credentials to applications running on EC2 instances, facilitating secure interactions with other AWS services like S3, RDS, and DynamoDB. The exploitation method involves submitting HTML documents with malicious iframe elements, which, if processed by a vulnerable Pandoc instance on an EC2 host, can access sensitive metadata paths and extract credentials. Security researchers from Wiz highlighted that enforcing IMDSv2, which requires session-based authentication, can effectively block such attacks, as was observed in incidents where IMDSv2 was enabled. Organizations are advised to mitigate this risk by using Pandoc's '-f html+raw_html' or '--sandbox' options and by ensuring IMDSv2 is enforced across all EC2 environments. The attacks underscore the broader risk posed by SSRF vulnerabilities in cloud environments, as they can lead to severe consequences such as network reconnaissance and cloud credential compromise. Resecurity researchers have warned that SSRF flaws, when combined with access to IMDS, can have far-reaching impacts on cloud security. The incident demonstrates that attackers are actively searching for SSRF vulnerabilities in web applications running on EC2 instances to gain unauthorized access to AWS resources. The exploitation of CVE-2025-51591 is not merely theoretical; it has been observed in the wild, with real-world attempts to compromise cloud infrastructure. The incident also highlights the importance of secure application design and the need for defense-in-depth strategies in cloud environments. Security teams are urged to review their use of Pandoc and similar utilities, especially in cloud-hosted environments, to ensure they are not inadvertently exposing sensitive metadata endpoints. The case further illustrates the evolving tactics of threat actors targeting cloud infrastructure through application-layer vulnerabilities. Cloud providers and customers alike must remain vigilant and proactive in patching and securing their environments against such emerging threats. The incident serves as a reminder that even medium-severity vulnerabilities can have significant impact when exploited in the right context. Finally, the coordinated disclosure and analysis by security firms like Wiz have been instrumental in raising awareness and driving mitigation efforts for this vulnerability.
Jun 29, 2026
A critical SSRF flaw in AWS Systems Manager (SSM) Agent, tracked as `CVE-2026-89049`, lets authenticated AWS users authorized to initiate remote-host port-forwarding sessions bypass protections blocking link-local destinations. By supplying alternate representations of denied addresses, an attacker can reach the EC2 Instance Metadata Service at `169.254.169.254` through the affected remote-host forwarding capability. Access to the metadata service could expose temporary credentials for the IAM role attached to the targeted EC2 instance, enabling further activity under that role's permissions. The issue affects SSM Agent versions earlier than `3.3.4851.0` and is fixed in version `3.3.4851.0`; organizations should update agents, restrict access to `AWS-StartPortForwardingSessionToRemoteHost`, tightly scope `ssm:StartSession`, and review Session Manager activity and EC2 instance-role usage.
Sep 14, 2026
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.
Jul 25, 2026