No password was guessed. No token was stolen. No phishing email was clicked.
And yet an attacker could walk straight into someone else’s account including an administrator’s just by sending a request out of order.
That’s the quiet danger of state validation flaws: bugs that live not in what a system checks, but in what it forgets to check when.
What Is a State Validation Flaw, Really?
Most sensitive workflows password resets, checkout flows, onboarding, MFA enrollment are really a sequence of required steps:
- Request the action
- Prove who you are
- Get permission to proceed
- Complete the action
Each step is only supposed to unlock the next one. The system is trusting its own internal state: “if we’re at step 4, the user must have completed steps 1 through 3.”
That assumption is the whole security model. And assumptions can be skipped.
The Illusion of Safety
A multi-step auth flow looks airtight on a diagram. Verification link goes out, user clicks it, session updates, password gets changed. Every box ticked, every arrow followed.
But a state machine doesn’t actually know a step happened. It only knows what it was told happened. If the workflow can be nudged into a later state without proof the earlier one occurred, the whole sequence collapses into a formality.
The link, the email, the “please verify” step all decoration on a door that was never really locked.
When Workflow State Becomes a Security Vulnerability
A state validation flaw happens when a system advances a sensitive workflow without confirming the previous step was actually satisfied. The common patterns:
- Trusting a client-supplied session or step parameter
- Treating “reached this endpoint” as proof of “completed that step”
- Skipping verification because a token or flag wasn’t explicitly re-checked
- Assuming a workflow can only be entered in order
None of these look-like bugs in a code review. They look like normal state machines. That’s exactly the problem.
Real-World Example: The Keycloak Password Reset Bypass
In August 2026, researchers disclosed a critical flaw in Keycloak, the widely used open-source identity and access management platform maintained by Red Hat, that put this exact failure mode on display.
The password reset flow is supposed to work like this: a user requests a reset, Keycloak emails a signed one-time token, the user clicks it to prove they own that inbox, and only then can a new password be set.
The flaw, tracked as CVE-2026-18963, sat in how the flow tracked its own progress. By sending a specially crafted request to the reset-credentials endpoint, an unauthenticated attacker could push the authentication session straight to the “set new password” stage without the email link ever being clicked, and without the action token that was supposed to prove ownership ever being validated.
The system didn’t check whether the proof step had actually happened. It just assumed that if you’d reached the final stage, you must have earned your way there.
The result: a remote, unauthenticated attacker could take over any account by username or email alone including admin accounts with no interaction from the victim required. Red Hat rated it Critical, with a CVSS score of 9.1. Patched versions (26.7.2 and equivalent Red Hat builds) were released in the days that followed, and as of this writing no confirmed public exploitation has surfaced. But the flaw sat in one of the most consequential systems an organization runs: the one that decides who’s allowed to be who.
Why State Validation Flaws Are So Dangerous
These bugs break security in ways that don’t trip normal alarms.
No credential theft. The attacker never needed a password, a token, or a phished link they just needed to know where the workflow’s later steps lived.
No malformed input. The requests aren’t malicious-looking. They’re syntactically valid, just out of sequence.
No visible failure. Logs show a completed reset flow, because as far as the system’s internal state was concerned, it was completed.
For an identity provider specifically, this risk doesn’t stay contained. A single sign-on system that trusts every downstream application does the compromising for an attacker automatically there’s no second door to break through.
How to Defend Against State Validation Failures
Design principles
- A workflow step is only “complete” when the system has cryptographic or session-bound proof, not client-asserted progress
- Never treat “attacker reached this endpoint” as evidence that prior steps occurred
Implementation rules
- Re-validate proof-of-completion server-side at every stage transition, not just at entry
- Bind state transitions to a token that can’t be replayed, guessed, or skipped to
- Test the flow by deliberately calling later steps first if the system lets you in, it’s broken
Operational controls
- Treat identity and auth flows as Tier-0 systems: continuous testing of recovery, enrollment, and delegation workflows
- Include “skip a step” as a standard test case in threat models for any multi-stage flow
- Patch identity infrastructure with the same urgency as anything internet-facing, because it usually is
The Bigger Picture
State validation flaws fail because a workflow trusts a sequence it can’t actually verify it infers that earlier step happened instead of confirming it.
As more of what we build is orchestration steps, states, flows, tokens passed between services this is where the next generation of “no exploit, no malware, still a breach” incidents will keep coming from.
Security isn’t just about exploits anymore. It’s about whether your system actually knows what it thinks it knows.