A condition where an attacker influences the path an application follows so that a legitimate workflow reaches an unintended destination or action. In management software, this often means redirecting trusted browser activity into attacker-controlled responses, which can then shape authentication, execution, or command delivery.
Expanded Definition
Control-flow hijacking describes a security failure where an attacker bends an application’s execution path away from the intended branch, callback, or redirect target and toward attacker-controlled logic. In NHI and IAM workflows, that can mean a browser-based authentication step, token exchange, or delegated command is routed into a malicious endpoint that still appears legitimate to the user or service.
The term is used across web security, language runtime exploitation, and identity workflows, but no single standard governs it yet in NHI-specific operations. In practice, security teams should distinguish control-flow hijacking from simple redirection mistakes: the risk is not only that a user lands in the wrong place, but that trusted state is preserved while the destination or next action is altered. That is why this issue is often discussed alongside NIST SP 800-53 Rev 5 Security and Privacy Controls and browser or protocol hardening guidance.
The most common misapplication is treating it as a UI nuisance, which occurs when teams focus on the visible redirect instead of the underlying trust boundary that was violated.
Examples and Use Cases
Implementing controls against control-flow hijacking rigorously often introduces more validation steps and tighter callback governance, requiring organisations to weigh user experience and integration speed against execution integrity.
- An OAuth or SSO callback is altered so the browser returns to an attacker-owned domain that captures session artifacts or authorization data.
- A service account initiates a browser-mediated workflow, and a malicious page manipulates the next request so the trusted client submits commands to the wrong endpoint.
- An API gateway or reverse proxy misroutes authenticated traffic, letting attacker-controlled content shape the downstream action while the session remains valid.
- A vulnerable application accepts unsafe redirect parameters, allowing a legitimate identity flow to finish on a destination chosen by the attacker instead of the expected control point.
- An operator console or admin portal loads a compromised script that changes the sequence of actions, causing an approved management task to execute against the wrong resource.
For NHI-heavy environments, this becomes especially important in delegated automation and browser-based service interactions. The Ultimate Guide to NHIs — Standards is useful for framing how workflow integrity fits into broader NHI governance, while identity and transport controls documented by NIST SP 800-53 Rev 5 Security and Privacy Controls help constrain how execution paths are approved and monitored.
Why It Matters in NHI Security
Control-flow hijacking matters because NHI systems often operate with durable trust, reusable tokens, and automation that assumes the next step in a workflow is safe if the first step was authenticated. When that assumption fails, the attacker does not need to break the identity itself; they only need to steer the legitimate process into an unintended action. In practice, that can expose secrets, redirect approvals, or cause service accounts to execute privileged tasks against the wrong target.
This risk is amplified by weak visibility and excessive privilege across machine identities. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot easily see when a workflow diverges from its intended path. The same governance gap is why control-flow issues should be handled as identity and execution problems, not only as application bugs.
Practitioners also align this concern with browser, proxy, and session defenses described in the Ultimate Guide to NHIs — Standards and with control coverage in NIST SP 800-53 Rev 5 Security and Privacy Controls. Organisations typically encounter the impact only after a trusted workflow has already been abused, at which point control-flow hijacking becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Workflow abuse and unauthorized execution map to NHI attack-path controls. |
| OWASP Agentic AI Top 10 | A-04 | Agentic workflows can be steered into unsafe tool calls through path manipulation. |
| NIST CSF 2.0 | PR.AC-3 | Access enforcement is weakened when trusted flows are redirected by attackers. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust segmentation helps contain malicious rerouting of trusted requests. |
| NIST SP 800-63 | Digital identity guidance applies when redirected flows alter authenticator trust. |
Validate every redirect, callback, and automation hop before allowing the next privileged step.
