Pi Security researchers started by noticing one strange AWS behavior. Under the right conditions, a bogus region value supplied to an AWS software development kit could eventually lead to an attacker gaining access to AWS credentials that could then be used to compromise the targeted cloud environment running core business operations.
That one strange AWS behavior amounted to a vulnerability-research jackpot.
Using its agentic AI technique, Pi researchers focused on the behavior behind the flaw rather than searching for identical vulnerable code. The technique unearthed roughly 2,500 instances of the same underlying flaw scattered across dozens of AWS SDK clients.
One root cause, multiplied at software scale.
Then came the paradox. AWS credited Pi for the discovery, but rated the underlying issue low severity, tagging it CVE-2026-22611. Pi argues the AWS low score belies the critical impact of its discovery.
“One configuration field, set to one malformed string, and we were in their cloud,” Pi researchers wrote in a technical blog of the findings Monday.
It sounds counterintuitive. How can AWS rate the underlying flaw low when Pi was able to use it, in the right production context, to obtain live AWS credentials? Worse, Pi says it found roughly 2,500 instances of the same underlying behavior across different AWS SDK implementations.
One AWS SDK Flaw: 2,500 Echoes
Both can be true, Pi co-founder and CEO Guy Arazi said in an interview. He said the gap between the bug on paper and what it can become in context is the more important finding.
“The fact that you’re going to see a low severity doesn’t mean that it’s going to be low severity for my environment,” Arazi said. “It might be critical to me because I’m using it in a specific way, or because it powers one of my core business functions.”
That context is something a low vulnerability score cannot know.
One Bug Wearing Thousands of Outfits
Pi credits the research jackpot to the way it decodes the root cause of a vulnerability into what it calls an “anti-pattern”. That describes the behavior behind the flaw, rather than the way that flaw happens to be implemented. In the AWS SDK example, the way it was operationalized in JavaScript, Go, Rust or C#.
Traditional automated scanning often looks for known signatures, functions or predefined code patterns. Pi’s anti-pattern approach instead tries to identify the behavior that made the original flaw possible. Next, a variant-analysis system then searches for that behavior across different languages, frameworks and implementations.
In the AWS research, that meant reducing the flaw to its essential behavior and hunting for that behavior across the broader SDK ecosystem. In Pi’s case the approach surfaced roughly 2,500 instances stemming from the same root cause.
The process uses AI agents but also human-in-the-loop validation. AI can perform at machine speed, replacing sometimes months of variant analysis, while researchers concentrate their own grey matter on determining whether what the agents found is real and consequential. Pi emphasizes it leans heavily on AI agents to do the grunt work, but humans manually validated each of the 2,500 findings.
About That Flaw
The AWS flaw centered on how the SDK figured out where to send a request. A region value such as us-east-1 helps determine which Amazon endpoint the software should contact. Pi found that on affected paths, some SDKs did not sufficiently validate that the region was a legitimate hostname component before using it to build the destination URL.
Pi discovered a malformed AWS region value could steer credential-bearing cloud requests to an attacker-controlled server. In an authorized production test, the redirected request sent the workload’s identity token to a server controlled by Pi. Researchers then replayed that token to AWS STS, which returned temporary AWS credentials tied to the workload’s IAM role.
By supplying specially crafted characters inside the region value, the researchers could cause the resulting URL to be interpreted differently by a URL parser than it appeared at first glance. The SDK would construct and sign what looked like an AWS request, but the surviving destination could instead be a server controlled by the researcher.
Pi researchers demonstrated the trick with a region value such as @attacker.com#. When the SDK used it to construct the URL, a browser-style parser could interpret attacker.com as the actual destination rather than AWS.
Pi characterizes the behavior as an SSRF primitive. More precisely, attacker-influenced input was able to affect construction of a server-side request destination without a validation step ensuring that the request was still headed for AWS.
AWS Rated the Bug: Pi Measured the Blast Radius
AWS and Pi were looking at two different layers of the same problem.
AWS scored the underlying SDK flaw in isolation. A bad region value could misroute a signed request. By itself this looked like a low-severity input-validation issue.
Pi looked at what happened when that flaw was embedded in a real production application, where the redirected request could carry a live workload identity token and lead to AWS credentials.
AWS characterized the SDK change as a defense-in-depth enhancement, emphasizing that customers remain responsible for controlling the configuration values their applications supply. Pi’s view was not that AWS’s Low rating was simply wrong, but that it captured only the base flaw, not what that flaw could become in a real production environment.
The difference, then, was one of perspective: AWS rated the underlying bug; Pi focused on the blast radius once that bug was put in context.
“A severity number is one piece of triage,” Arazi said. Defenders still have to understand whether the affected code actually runs, whether attackers can reach it, which credentials or identities surround it and what those identities can do, he said.
He added one more piece. Defenders need to know what faulty assumption created the bug and everywhere that assumption has spread.
