Topic starter
11/11/2026 6:04 pm
TL;DR: Intel CET has not reached Intel's for-market processors yet, so code-reuse attacks still have room to operate, according to Karamba Security. Connected systems need runtime control-flow validation now because hardware-backed enforcement is not yet universally available.
Editorial analysis by NHI Mgmt Group, based on content published by Karamba Security: “Blog”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Memory corruption remains dangerous because code-reuse attacks can weaponise trusted instructions without dropping obvious malware.
Glossary terms: Control-flow integrity, Control-Flow Enforcement Technology, Shadow Stack, Return Oriented Programming
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:06 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Intel CET delays keep control-flow attacks viable in connected systems