← Back to articles

Compiler Can Undo Your Security Checks

2026-09-12 | original

read original get Hacking: The Art of Exploitation, 2nd Edition" by Jon Erickson → more articles

Why This Matters

A Black Hat conversation with researcher Chris Domas highlights that secure-looking C source code can become a vulnerable binary because compilers are legally permitted to optimize away security checks, memory-clearing operations, and even introduce time-of-check to time-of-use bugs. Since the CPU runs compiled output rather than source, developers' best practices and code review of source alone may not be enough. The issue affects widely used toolchains like GCC and Clang, meaning it has broad implications across the software supply chain.

Key Takeaways

Compiler optimizations permitted by the C abstract machine can silently delete security protections such as memory scrubbing and introduce TOCTOU flaws.
The problem is subtle and unpredictable \u2014 factors like register pressure, struct layout and data size can determine whether a binary is vulnerable; switching between GCC and Clang isn't a fix.
Practical mitigations include enabling compiler warnings, using sanitizers, analysing optimized builds, and testing the exact binary that ships; AI-assisted analysis of 500 million lines of open-source code surfaced about 300 risky patterns.

Worth a Look

Hacking: The Art of Exploitation, 2nd Edition" by Jon Erickson — If this talk on compilers quietly undoing your security checks hooked you, this classic walks through C code, memory layout and what the machine actually executes underneath. It's a hands-on way to build the low-level intuition Chris Domas draws on when explaining why source-level safety doesn't guarantee a safe binary.

See Hacking: The Art of Exploitation, 2nd Edition" by Jon Erickson on Amazon → Affiliate link — we may earn a commission on purchases, at no extra cost to you. Product picked by AI based on this article; it is not a tested recommendation.

Big thanks to @ThreatLocker for sponsoring my trip to Black Hat USA 2026 and also for sponsoring this video. To start your free trial with ThreatLocker please use the following link: https://www.threatlocker.com/davidbombal

You can write secure C code, follow accepted best practices and still end up with a vulnerable binary. The reason is simple: the CPU does not run your source code. It runs whatever the compiler produces.

David sits down with security researcher Chris Domas at Black Hat to examine how legal compiler optimizations can remove security protections, delete memory-clearing operations and introduce time-of-check to time-of-use vulnerabilities into code that appeared secure.

Chris explains the C abstract machine, why compilers are allowed to transform code so dramatically and how register pressure, structure layout and even data size can affect whether a binary is vulnerable. In one striking example, 17 or 33 bytes can be safe while nearby sizes produce vulnerable code. They also discuss whether Rust solves the problem, why switching between GCC and Clang is not the answer and how AI helped analyse 500 million lines of open-source code to identify 300 potentially dangerous patterns.

Most importantly, Chris explains what developers can do now, including enabling compiler warnings, using sanitizers, analysing optimized builds and testing the exact binary that will be shipped.

// Christopher Domas’ SOCIAL //

LinkedIn: / christopher-domas

GitHub: https://github.com/xoreaxeaxeax

X: https://x.com/xoreaxeaxeax

// David’s Social //

... continue reading

Explore topics: compiler optimizations chris domas black hat usa c abstract machine gcc