Home / Blog / A Regex Without Anchors, and a Race…
Supply Chain
A Regex Without Anchors, and a Race to Register a GitHub Account
A webhook filter checked ACTOR_ID with a regex that had no ^ or $. Substring match was enough. This is not a regex mistake - it is a deep understanding of how an application decides.
This piece is my read on research published by Yuval Avrahami and Nir Ohfeld at Wiz. The findings are theirs; the argument about what they mean is mine. Their original write-up is worth reading in full.
There are bugs you read and forget. And there are ones that stay with you - not because of how sophisticated they are, but because of the way of thinking behind them. That is exactly what happened to me reading the research by Yuval Avrahami and Nir Ohfeld at Wiz.
They found a weakness in AWS CodeBuild that made it possible to take over central AWS repositories on GitHub - including the JavaScript SDK that powers the AWS Console and is in use in something like 66% of cloud environments.
Technically it is almost embarrassing how simple it is
Webhook filters that check ACTOR_ID using a regex, with no anchors for the start and end of the expression (^ and $). The check did not require a full match - it was satisfied with the ID appearing as a substring.
The result: an attacker could create a new GitHub user whose ID contained the ID of a trusted maintainer, pass the verification check, and receive permissions they should never have had.
But that is not what caught me.
What was genuinely impressive is how they exploited it
Timing the creation of a GitHub App bot user so that the maintainer ID would be a substring of their own user - while racing GitHub's account-creation mechanism.
That is not a regex mistake. It is a deep understanding of how an application makes decisions. What exactly it checks, what it trusts, and where the application logic lets you cross the line without breaking a single formal rule.
And that is exactly the heart of application security. Not a random CVE. Not an automated scan. A place where code that works as designed permits behaviour nobody accounted for.
We run into this constantly
At AppSec Labs we see it all the time. Tests that pass. Code that looks right. And then one small logical detail - sometimes a single condition, sometimes a quiet assumption of trust - turns into a critical weak point.
This research is an important reminder that application security is not measured by how many tests you ran, but by how deeply you understood how your application actually thinks.
Ethical hacking, as far as I am concerned, is not about being sophisticated. It is about being suspicious of your own logic. Because the moment you stop applying that healthy doubt and assume everything will be fine, somebody on the other side will already have found how to use it against the application we are trying to protect - and by then it is too late.
I first shared a version of this as a LinkedIn post on 2026-02-02. It is republished here, lightly edited, so it is easier to find and reference. — Erez Metula
Keep reading
More from the blog
Supply Chain
One Click, and Every Private Repo You Can Reach Is Theirs
A link, inside the tool you use every day. Simulated keystrokes install an extension, which lifts the GitHub OAuth token - and…
Read itSupply Chain
The Docker Instruction That Runs on Your Machine, Not Theirs
ONBUILD does not run for whoever wrote it. It runs for you, the moment you FROM their image - silently, with no…
Read itSupply Chain
Canary Credentials: The Smoke Detector Nobody Installs
Fake credentials in the pipeline that are wired to nothing. Nothing legitimate ever touches them, so the moment anything does, you know…
Read itTell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.