TL;DR: Control-flow enforcement remains absent from Intel's for-market processors, leaving return-oriented programming and other code-reuse attacks viable in connected systems, according to Karamba Security. Runtime integrity controls still matter because memory safety gaps can turn trusted code paths into exploit paths before hardware support arrives.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Karamba Security's blog post: Intel CET remains unavailable in for-market processors, leaving code-reuse attacks such as ROP relevant to connected systems.
Why it matters: This matters because product teams cannot assume hardware enforcement will close memory-exploit risk on its own, so runtime integrity and exploit mitigation still need to be designed into the stack.
Context
Control-flow integrity is the ability to verify that execution follows legitimate transfer paths instead of being redirected by an exploit. In embedded and connected systems, that matters because memory corruption can still turn ordinary return instructions into attacker-controlled jumps, even when the code itself was meant to be trusted.
Intel's CET concept is a hardware approach to tightening those checks, but the gap between specification and deployment leaves a practical governance problem for product security teams. Where connected products ship before the platform ecosystem is ready, runtime mitigation becomes a control decision rather than a future option.
Key questions
Q: How do shadow stacks stop return-oriented programming?
A: Shadow stacks stop return-oriented programming by keeping a protected copy of each function return address on a separate stack that normal memory corruption cannot overwrite. On return, the CPU or runtime compares the architectural return address with the shadow copy and traps on a mismatch, which blocks control-flow hijacking through smashed stack frames.
Q: Why does control-flow integrity matter for memory corruption attacks?
A: Control-flow integrity matters because it restricts where indirect branches, calls and returns are allowed to go after memory corruption. By checking that execution follows an approved control-flow graph, it makes code-reuse attacks such as return-oriented programming and jump-oriented programming much harder to chain from a corrupted pointer or stack overwrite.
Q: How should teams apply hardware and software exploit mitigations together?
A: Teams should layer hardware and software mitigations because each covers different exploit paths. Hardware features such as shadow stacks, non-executable memory and pointer authentication can block or detect certain control-flow abuses, while software controls such as stack canaries, CFI, sanitizers and safe language use reduce the chance that a memory bug becomes code execution.
Q: What signs suggest a code-reuse attack is underway?
A: Signs of a code-reuse attack include return-address mismatches, unusual indirect branch targets, repeated crashes at return instructions and execution that jumps into existing code gadgets instead of normal functions. Defenders often see control-flow integrity alerts, shadow stack violations or telemetry showing a process reusing library code rather than loading new instructions.
Technical breakdown
How shadow stacks block return-oriented programming
A shadow stack is a second, protected stack that stores return addresses separately from the normal call stack. In a return-oriented programming attack, the attacker does not inject new code. Instead, they chain together existing instructions by corrupting return addresses and steering execution through legitimate code fragments. By comparing the return address on the normal stack with the protected copy, the CPU or runtime can detect tampering at the moment of return. That makes control-flow corruption visible at the point where it would otherwise be exploited, rather than after the process has already diverged. See the Exploit Mitigations Guide.
Practical implication: Treat shadow-stack support as a compensating control for memory corruption risk, not as a substitute for secure coding and exploit mitigation.
Why control-flow integrity still matters before hardware support arrives
Control-flow integrity, or CFI, validates that indirect jumps, calls and returns stay within allowed execution paths. That matters because modern exploit chains often abuse legitimate instructions instead of introducing obviously malicious payloads. Software CFI can run across multiple processor families and operating systems, which makes it useful in product portfolios that cannot wait for one hardware vendor's roadmap. The key point is governance: if the platform cannot guarantee hardware enforcement today, the build and runtime layers must carry part of the burden. See the Memory Corruption Vulnerabilities Guide.
Practical implication: Map CFI coverage to the product line now and use it where hardware-backed enforcement is not yet available.
How runtime integrity validation detects exploit attempts
Runtime integrity validation watches execution as the system runs and checks whether code paths deviate from expected factory-defined behaviour. That is different from static hardening because the control is active during use, when buffer overflows and code-reuse attacks actually try to take effect. The value is not only blocking the attack but also recording that the attempt happened, which supports forensics and response. In environments with third-party libraries and scripts, this becomes especially important because the attack surface is not limited to first-party code.
Practical implication: Instrument runtime validation where third-party components expand the execution surface and make post-event investigation harder.
Threat narrative
Attacker objective: The attacker aims to execute malicious behaviour through trusted code paths while avoiding the need to drop obvious new code.
- Entry occurs through a memory corruption flaw that gives the attacker a foothold in the execution flow of the target process.
- Credential access is not the main objective here; instead, the attacker abuses legitimate code paths and corrupted return addresses to build a return-oriented programming chain.
- Escalation follows as the process is steered into attacker-chosen behaviour without introducing new executable payloads.
- Impact is achieved when the code-reuse attack executes malicious actions inside trusted software before the control-flow violation is detected.
Breaches seen in the wild
- Twitter source code leak 2023: Twitter source code and internal tools were posted to GitHub by "FreeSpeechEnthusiast" and stayed public for months before a 2023 takedown.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Hardware control-flow enforcement is not a future nicety, it is a gap-closing control for memory corruption now. When processor-level enforcement is absent from shipping systems, product teams are left relying on software mitigations, secure coding, and runtime checks to contain exploitability. That changes the assurance model for any connected product that still carries legacy memory-unsafe code. The practical conclusion is that exploitability should be judged on the controls available today, not on a hardware roadmap.
Shadow stacks make return-address tampering measurable, which is why they change the economics of ROP. Code-reuse attacks succeed by reusing legitimate instructions, so traditional malware detection often sees normal-looking code until the moment of impact. A protected shadow stack turns that hidden manipulation into a verifiable mismatch. That is a strong example of how runtime integrity can convert an exploit chain into a detectable control event.
CFI should be treated as a portfolio control, not a point feature. Karamba Security's discussion makes the broader point that protection has to span operating systems, applications, and third-party components when hardware support is inconsistent. That is especially relevant for vendors shipping across Intel, Arm and other architectures. The governance question is whether the software stack is consistent enough to absorb the gap between specification and deployment.
Control-flow assurance debt: the risk created when product teams depend on forthcoming hardware enforcement instead of deploying present-day mitigations. That debt accumulates across release cycles when memory-unsafe code stays in production without equivalent runtime checks. It is a useful lens for boards and engineering leaders because it reframes exploit resilience as a backlog item, not a future benefit. The action is to reduce that debt before attackers exploit the gap.
Read next: Memory Corruption Vulnerabilities Guide
What this signals
Control-flow assurance debt: organisations that wait for hardware roadmaps while shipping memory-unsafe code accumulate a preventable exploitability gap. The immediate programme risk is inconsistent protection across product lines, especially where third-party libraries and legacy components remain in use.
Runtime enforcement is becoming a governance decision as much as an engineering one. Security leaders should track where control-flow validation is actually active, because unsupported platforms can quietly become the weakest part of the fleet.
For practitioners
- Deploy runtime CFI on memory-unsafe components Prioritise code paths that parse untrusted input, handle network traffic, or embed third-party libraries, then enforce control-flow checks around indirect branches and returns.
- Use shadow-stack telemetry for exploit forensics Collect events that show return-address mismatches, blocked code-reuse attempts, and process-level tampering so incident responders can distinguish noise from real exploitation attempts.
- Map mitigations to product architectures Document which devices, operating systems and processors can rely on hardware enforcement and which need software-based compensating controls until deployment catches up.
- Validate third-party code paths at build time Review compiler and build pipeline settings so the runtime protection is actually present in shipped binaries rather than assumed as a downstream platform capability.
Key takeaways
- Memory corruption remains dangerous because code-reuse attacks can weaponise trusted instructions without dropping obvious malware.
- The article points to a control gap between hardware specifications and deployed processor support, not to a lack of awareness about the risk.
- Practical defence depends on runtime integrity controls and control-flow validation across the product stack, not on waiting for one CPU feature to arrive.
Related NHI Mgmt Group resources: Memory Corruption Vulnerabilities Guide · Exploit Mitigations Guide · NetFlow and IPFIX Flow Telemetry Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0040 — Credential Access; Impact | Code-reuse attacks manipulate control flow to achieve execution impact through trusted code paths. |
| Recommendation — Map control-flow abuse to credential-access and impact tactics, then prioritise detections for return-address tampering. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Memory corruption exposure requires active tracking of vulnerable code and exploitability reduction. |
| Recommendation — Use CIS-7 to track exploitable memory-unsafe components and validate mitigation coverage in production. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration management and baseline management | Runtime integrity controls depend on secure platform baselines and enforced protective settings. |
| Recommendation — Apply PR.PS-01 to harden execution baselines and verify exploit mitigations are enabled where supported. | ||
| NIST SP 800-53 Rev 5 | SI-16 — Memory Protection | The article centres on protecting execution flow from memory corruption exploitation. |
| Recommendation — Implement SI-16 to enforce memory-protection mechanisms that resist control-flow hijacking. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The exploit path arises from memory-unsafe code paths and architectural resilience gaps. |
| Recommendation — Use V15 to reduce memory-unsafe patterns and architecture choices that enable control-flow attacks. | ||
Key terms
- Control-flow integrity: Control-flow integrity means an agent follows its intended sequence of actions even when it encounters hostile or misleading input. In LLM systems, it reduces the chance that prompt injection can redirect tool choice or execution order, but it does not automatically protect the values carried through those actions.
- Control-Flow Enforcement Technology: Control-Flow Enforcement Technology is a CPU security feature set that helps protect programme control flow against tampering. It uses mechanisms such as shadow stacks and indirect branch tracking to verify returns and indirect branches, making common code-reuse attacks harder to execute after memory corruption.
- Shadow Stack: A Shadow Stack is a protected copy of call-stack return addresses used to detect tampering. It helps stop return-address overwrite attacks, but defenders still need to confirm it is enabled where supported and that software does not bypass or disable the control during exploitation or compatibility changes.
- Return Oriented Programming: Return oriented programming is an exploitation technique that chains short sequences of existing instructions already present in a binary. Attackers use it when direct code injection is blocked, especially after they gain memory corruption and can influence control flow without writing new executable code.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programmes they operate every day.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org