Ghost in the Binary

When regulation can't see what it declares compliant

On February 1, 2026, René Meusel takes the stage at FOSDEM in Brussels. Meusel maintains Botan, a cryptographic library recommended by Germany's BSI, and works as an engineer at Rohde & Schwarz Cybersecurity. His topic: "Trust the Math, Fear the Compiler." His demonstration: GCC 15.2, compiled with the -O3 optimization flag, strips side-channel protections from correct cryptographic code¹.

The compiler doesn't break the code. It optimizes it. It detects a verification loop that exits early when the character matches, concludes that the timing normalization code that follows is unnecessary, and removes it. Result: an exploitable timing side-channel appears in the compiled binary. The source code is secure. The binary is not.

Seven months later, on September 11, 2026, the European Cyber Resilience Act's reporting obligations take effect². Every manufacturer of products with digital elements will have to report actively exploited vulnerabilities to ENISA within 24 hours³, with fines up to €15 million or 2.5% of global turnover⁴.

The CRA assesses source code conformity. The compiler modifies the binary. The regulator doesn't see the difference.

What the CRA covers

The CRA and the new Product Liability Directive (PLD 2024/2853) form the most comprehensive regulatory framework to date for reducing risks associated with digital products in Europe.

The CRA requires manufacturers to assess cyber risks throughout all lifecycle phases, from design to maintenance, and to not place products with known vulnerabilities on the market⁵. Manufacturers must produce an SBOM (Software Bill of Materials) documenting all integrated components⁶. Reporting obligations extend even to products deployed before the regulation takes effect⁷.

The PLD goes further. Software becomes a product in the legal sense, subject to strict liability, no fault required⁸. The manufacturer is liable for defects even without negligence. The liability cap from the previous directive disappears⁹. Companies cannot contractually exclude or limit their liability for cybersecurity defects¹⁰.

The framework rests on a core assumption: the manufacturer controls its product. What it writes, what it tests, what it declares compliant, that is what runs at the customer's site.

Meusel's demonstration at FOSDEM invalidates this assumption.

The compiler as invisible actor

Aggressive optimization in modern compilers transforms the security properties of code. Meusel describes a three-step escalation to protect a simple password verification against timing attacks.

First step: replace boolean values with two-bit integers using bitwise operations. GCC sees through the trick. It recognizes the disguised boolean comparisons and reintroduces optimized branching.

Second step: apply obfuscation functions to inputs and outputs. These functions add nothing to the program. They exist solely to prevent the compiler from optimizing away security protections.

Third step: inject inline assembly that does nothing, returning the same value unchanged. The compiler doesn't understand assembly. It stops touching the affected values¹.

Code written to deceive a translation tool. Three layers of obfuscation whose only purpose is to stop GCC from removing protections the developer intentionally placed.

A second talk at the same FOSDEM takes a more ambitious approach. The GnuSecret project introduces a secret attribute directly into GCC, allowing the notion of confidential data to propagate through optimization passes¹¹. The C language has no concept of secret data in its abstract machine. The compiler cannot protect what it doesn't know needs protecting.

Meusel shows the manual workaround, GnuSecret shows the fundamental fix. Both confirm that the compiler is an autonomous actor in the security chain, and that neither the CRA nor the PLD accounted for it.

Who pays when the compiler breaks the binary

GCC is free software, developed outside any commercial activity. The CRA explicitly exempts open-source software stewards from manufacturer obligations¹². Their only constraints: maintain a cybersecurity policy, cooperate with market surveillance authorities, report actively exploited vulnerabilities (Article 24 CRA). The PLD excludes free software provided outside commercial activity (Article 2(2) PLD)¹³.

The exemption stops cold when an open-source component enters a commercial product. The CRA is explicit: when a manufacturer integrates third-party components into its product, it must exercise due diligence to ensure those components do not compromise the product's cybersecurity (Article 13(5) CRA)¹²ᵇ. The PLD drives the point home: free software developed outside commercial activity is excluded from its scope (Article 2(2) PLD). Recital 15 spells out the consequence: when a manufacturer integrates such software into a commercial product, the manufacturer can be held liable for defects in that software, but not the software's manufacturer, since the latter never placed a product on the market within the meaning of the directive¹³ᵇ.

In plain terms: you compile your product with GCC. GCC optimizes your code and breaks a constant-time protection. Your binary is vulnerable. You are liable under the CRA for the conformity defect. You are liable under the PLD for the resulting damage. And you cannot pursue GCC, because GCC is not an economic operator within the meaning of the directive.

The manufacturer bears 100% of the liability for a defect it did not introduce, in a binary whose security properties the compiler altered, using a tool the regulator chose to exclude from scope. The entity that causes the defect does not exist under the PLD. The entity that is liable did not cause the defect. And there is no one to pursue for recourse.

The PLD makes it worse. Liability is strict: the manufacturer need not be negligent to be held liable¹⁴. Having written correct, tested, and audited source code is not a defense, because the PLD evaluates the product as placed on the market, not as designed¹⁵. If the manufacturer cannot demonstrate compliance with required processes, courts may presume defectiveness¹⁶. But demonstrating source code compliance is not enough if the binary has different properties. And post-compilation verification processes (valgrind, ct-verif) are part of no CRA conformity standard. Finally, the PLD creates a liability cascade: manufacturer, then importer, then distributor (Article 8 PLD)¹³ᵇ. If the manufacturer cannot be identified or has no EU entity, the European distributor bears the liability, for a defect it knows nothing about.

What the SBOM doesn't see

The CRA mandates SBOMs to improve supply chain transparency⁶. An SBOM will document: Botan 3.x, compiled with GCC 15.2, flag -O3. It will not document that GCC stripped the constant-time protection from the verification function at line 247, exposing a 3-nanosecond side-channel exploitable remotely.

The SBOM inventories what goes into the box. Not what comes out.

A compiler version upgrade, from GCC 14 to GCC 15, can introduce new optimizations that break cryptographic protections in unchanged code. The SBOM will reflect the compiler version change. It will not reflect the silent security regression in the binary.

Conformity assessments, Common Criteria certifications, ANSSI's CSPN audits all examine source code or, at best, the binary at a given point in time. Recompilation with an updated compiler can invalidate those certifications without anyone noticing.

The American infrastructure in contraction

The hole in the binary is only the first blind spot. The second concerns the infrastructure the CRA relies on to function.

Reporting obligations presuppose that vulnerabilities are identified, catalogued, scored. In practice, this infrastructure rests on three American pillars: MITRE's CVE system, NIST's NVD database, and CISA's KEV catalog.

I documented the fragility of these pillars in earlier articles in this series¹⁷. The facts as of today.

The NVD has accumulated over 26,000 unanalyzed CVEs¹⁸. In late January 2026, NIST acknowledged before its advisory board that it is "fighting a losing battle" and stopped using the word "backlog," a term that implied the intention to catch up. NIST will not catch up. It will now prioritize which CVEs to enrich, abandoning the rest¹⁸ᵇ. MITRE's CVE program funding, extended through April 2026, has no long-term guarantee¹⁹. CISA has lost nearly all its senior leadership and suffered 30% budget cuts²⁰. The KEV catalog covers roughly 0.5% of published CVEs²¹, fed by predominantly American sources: sensors deployed on American networks, intelligence from the NSA, the FBI, and US vendors.

Europe has no operational alternative. The EUVD launched in 2025 is embryonic. The European GCVE (Global CVE Allocation System), launched in response to American failures, worries NIST, which fears a "balkanization" of the system¹⁸ᵇ. No European catalog of actively exploited vulnerabilities exists. 85% of European security solutions rely on NVD data²².

The CRA requires European manufacturers to report vulnerabilities within 24 hours. To identify those vulnerabilities, these manufacturers depend on an American infrastructure that no longer even claims to ensure comprehensive coverage²³.

Compliance and visibility

The CRA produces a compliance mechanism: SBOM documented, CVEs monitored, 24-hour reporting, patch processes, CE mark applied. The manufacturer checks the boxes. The auditor validates. The regulator is satisfied.

This compliance covers catalogued vulnerabilities, those with a CVE identifier, a CVSS score, an NVD entry. The "known vulnerability, known exploitation" quadrant in the classic known/unknown matrix. Everything else falls outside the framework.

An actively exploited 0-day without a CVE identifier remains invisible to the CRA as long as no attribution exists. The KEV requires a CVE to include a vulnerability in its catalog²¹. No CVE, no KEV, no signal, no reporting obligation.

A vulnerability introduced by the compiler into a binary declared compliant evades all detection: no scanner flags it, no CVE references it, no SBOM documents it. It exists in the binary deployed at the customer's site, not in the audited source code. And an unknown class of vulnerabilities, discovered by an attacker using AI to fuzz compiled binaries, is by definition absent from every catalog.

The CRA turns a visibility bias into a compliance attestation. The compliant organization believes its perimeter is covered. The covered perimeter represents a fraction of the actual risk.

AI in the blind spot

Article 4 of this series documented the imbalance between defensive and offensive AI²⁴. Defensive AI improves the handling of known threats, a linear improvement. Offensive AI explores the space of the unknown, discovers new attack paths, generates undocumented techniques, and exponentially multiplies the number of capable attackers.

The compiler case illustrates this imbalance with surgical precision.

What Meusel does manually with valgrind, verifying that a compiled binary preserves the constant-time properties of the source code, an offensive AI can do at industrial scale. Fuzz compiled binaries across different versions of GCC, Clang, MSVC. Map the optimizations that introduce timing variations. Identify cryptographic libraries whose protections are silently stripped. Target CRA-compliant products whose binary no longer matches the source code guarantees.

In February 2026, Anthropic published Claude Opus 4.6's vulnerability research results: over 500 validated high-severity flaws in major open-source projects (Ghostscript, OpenSC, CGIF), some present for decades and resistant to millions of CPU hours of automated fuzzing²⁵. The model does not fuzz: it reads source code, analyzes Git history, reasons about algorithmic logic. Cost: roughly $45 per attempt. Anthropic estimates that 90-day disclosure windows may become inadequate given the volume of discoveries²⁵ᵇ. Google Big Sleep and Microsoft Security Copilot confirm the trend²⁶.

These results concern source code, not compiled binaries. Extrapolation to binary analysis is a projection, not an established fact. But the direction is clear: when a model reasons about the logic of a compression algorithm to trigger a buffer overflow that fuzzing cannot find statistically, applying that reasoning to compiler transformations is a matter of time and focus, not a technological breakthrough.

AI maximizes the offensive game in the exact plane the CRA does not cover. Catalogued vulnerabilities, manufacturers know how to handle them, even poorly. Emergent vulnerabilities, created by interaction between stack layers, invisible to scanners, absent from catalogs, that is where offensive AI operates without constraint and where the CRA is blind.

The full chain

To recap. The compiler introduces vulnerabilities into the binary that the source code does not contain, but the CRA assesses source code conformity. The detection infrastructure (CVE/NVD/KEV) that feeds CRA obligations is under American control, contracting, and geographically biased. And offensive AI discovers and exploits classes of vulnerabilities that the CVE/NVD/KEV system does not catalog by definition, since they did not exist before being found.

These three gaps do not add up. They multiply. The compiler creates vulnerabilities that the CVE does not reference, that the scanner does not detect, that the SBOM does not document, and that offensive AI can hunt for at a marginal cost of $45 per attempt, with success rates doubling every six months. CRA compliance, far from protecting, reassures the organization about a covered perimeter while risk concentrates outside it.

In military terms, this is the Maginot Line. An expensive, technically impressive fortification, built to face the visible threat. The attack will come through the Ardennes.

What I don't know

The extent of the problem is no longer a hypothesis. An October 2024 study, "Breaking Bad: How Compilers Break Constant-Time Implementations," analyzed 44,604 compiled targets across major cryptographic libraries, six processor architectures (x86-64, ARM, RISC-V, MIPS), multiple GCC and LLVM versions, and all optimization levels²⁵ᶜ. Result: compiler-introduced vulnerabilities are "widespread." The researchers found them in every configuration tested, including in the libraries most reputed for side-channel resistance. A second paper from July 2025 identifies the specific optimization passes responsible and proposes compiler flag mitigations²⁵ᵈ.

What I don't know: the extent beyond the open-source libraries studied. Internal corporate cryptographic implementations, embedded firmware, unaudited proprietary libraries, no one has measured the impact of compiler optimizations on this perimeter. And that is where the CRA bites: compliant products placed on the European market massively include this type of unverified code.

I also don't know whether the European Commission is aware of this blind spot. CRA discussions focused on SBOMs, patch processes, reporting obligations. The question "does the compiled binary have the same security properties as the audited source code?" does not appear in any preparatory document I could find.

The future of GnuSecret remains uncertain. If GCC integrates a secret attribute in a future version, it would be a first step toward a compiler that understands security, not just performance. But GCC evolves slowly, and integrating such a change would take years. As for the European EUVD or the new GCVE, nothing suggests they can cover compiler-introduced vulnerabilities. This type of vulnerability does not fit the classic CVE model: there is no bug in the source code, no bug in the compiler (it behaves in accordance with the C standard), and yet the binary is vulnerable. The current conceptual framework has no category for this phenomenon.

Seven months to act

The CRA takes effect in stages: vulnerability reporting in September 2026, full conformity in December 2027²⁷. The PLD applies from December 2026²⁸.

Manufacturers preparing for CRA compliance have seven months to integrate a fact the regulation ignores: the binary they ship does not necessarily have the security properties of the code they wrote.

Integrating post-compilation verification into the CI/CD pipeline is the first priority. Tools like valgrind (memcheck mode), ct-verif, or timecop can detect timing leaks in compiled binaries. No CRA standard requires it. The PLD will require it in practice, since a manufacturer unable to demonstrate it verified its binary, not just its source code, will have no defense against a presumption of defectiveness.

Documenting compilation flags and justifying them comes next. The choice between -O2 and -O3 has consequences for the binary's security properties. An augmented SBOM, including the compiler version, optimization flags, and post-compilation verification results, constitutes evidence of due diligence that exists in no current standard but that any court will understand.

Finally, treat every compiler version upgrade as a security event. An update from GCC 14 to GCC 15 can introduce new optimizations that break cryptographic protections in unchanged code. Change management processes must include re-validation of the binary's security properties after every compiler change.

These measures do not solve the underlying problem. They reduce legal exposure and technical risk while the regulatory framework catches up with reality.

The underlying problem is a design flaw in the CRA. A regulation that aims to reduce risks from European digital products without addressing the transformation chain between source code and deployed binary, and without a European alternative to the American vulnerability databases it depends on, produces compliance, not security. And it produces a perverse effect: compliance costs and strict liability that only established players can absorb, in a market dominated by non-European actors who can choose not to enter it.

Twelfth article in a series on the structural weaknesses of Western cybersecurity (articles 1-5 in French):

• Article 1 : La vulnérabilité de la gestion des vulnérabilités
• Article 2 : La dépendance européenne aux standards américains
• Article 3 : Les États, architectes cachés du marché noir des vulnérabilités
• Article 4 : L'IA ou l'effondrement du modèle défensif occidental
• Article 5 : Desert Power — survivre sans l'Empire
• Article 6: I Am Altering the Deal
• Article 7: The Last Channel
• Article 8: Lord of Cyber War
• Article 9: The Digital Hawks
• Article 10: They Live... We Sleep
• Article 11: Soylent Green

¹ Meusel, R. (2026). "Trust the Math, Fear the Compiler", FOSDEM 2026, Security Devroom https://fosdem.org/2026/schedule/event/fosdem-2026-6174-trust-the-math-fear-the-compiler/

² Regulation (EU) 2024/2847, Article 69(3) — reporting obligations applicable from September 11, 2026 https://digital-strategy.ec.europa.eu/en/policies/cra-summary

³ Regulation (EU) 2024/2847, Article 14(1) — 24-hour notification to ENISA and national CSIRTs https://www.european-cyber-resilience-act.com/

⁴ Regulation (EU) 2024/2847, Article 64 — maximum penalties of €15 million or 2.5% of global turnover https://www.whitecase.com/insight-alert/cyber-resilience-act-clock-ticking-compliance

⁵ Regulation (EU) 2024/2847, Annex I, Part I — essential cybersecurity requirements https://cycode.com/blog/cyber-resilience-act/

⁶ Regulation (EU) 2024/2847, Preamble 77 — SBOM requirement https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Preamble_71_to_80.html

⁷ Regulation (EU) 2024/2847, Article 69(3) — applies to products placed on the market before December 2027 https://www.keysight.com/blogs/en/tech/nwvs/2025/09/11/one-year-countdown-to-eu-cra-compliance-september-11-2026-changes-everything

⁸ Directive (EU) 2024/2853, Article 4 — software explicitly included in the definition of "product" https://www.ibanet.org/European-Product-Liability-Directive-liability-for-software

⁹ Directive (EU) 2024/2853 — removal of liability cap https://www.ibanet.org/European-Product-Liability-Directive-liability-for-software

¹⁰ Reed Smith (2025). "The new EU Product Liability Directive: Implications for software, digital products, and cybersecurity" https://www.reedsmith.com/articles/eu-product-liability-directive-software-digital-products-cybersecurity/

¹¹ "Tentative Definition of the Secret Attribute in GCC", FOSDEM 2026 https://fosdem.org/2026/schedule/event/HGLHTN-tentative_definition_of_the_secret_attribute_in_gcc/

¹² Regulation (EU) 2024/2847, Article 24 — obligations for "open-source software stewards": cybersecurity policy, cooperation with authorities, reporting of actively exploited vulnerabilities https://digital-strategy.ec.europa.eu/en/policies/cra-open-source

¹²ᵇ Regulation (EU) 2024/2847, Article 13(5) — manufacturer's due diligence obligation on integrated third-party components, including open source. The Commission foresees "voluntary security attestation programmes" via delegated acts (Article 25) https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

¹³ Directive (EU) 2024/2853, Article 2(2) — exclusion of free software outside commercial activity. A paid service or one provided in exchange for personal data restores product status https://www.ibanet.org/European-Product-Liability-Directive-liability-for-software

¹³ᵇ Directive (EU) 2024/2853, Recital 15 (a manufacturer integrating free software into a commercial product can be held liable for defects in that software, but not the software's manufacturer, excluded from scope by Article 2(2)), Article 8 (liability cascade: manufacturer → importer → authorized representative → fulfillment service provider → distributor) and Article 12(2) (recourse against a software component manufacturer can be contractually waived if it is a micro or small enterprise) https://eur-lex.europa.eu/eli/dir/2024/2853/oj/eng

¹⁴ Directive (EU) 2024/2853 — strict liability regime (no-fault) https://www.fladgate.com/insights/the-eus-new-product-liability-directive-what-it-means-for-software

¹⁵ Directive (EU) 2024/2853, Article 7(2) — assessment of defectiveness of digital products https://riskandcompliance.freshfields.com/post/102jk3j/the-eu-product-liability-directive-key-implications-for-software-and-ai

¹⁶ Reed Smith (2025), ibid. — presumption of defectiveness in cases of technical complexity https://www.reedsmith.com/articles/eu-product-liability-directive-software-digital-products-cybersecurity/

¹⁷ See articles 1, 2 and 7 in this series

¹⁸ Gamblin, J. (2026). "NVD Analysis Status" — 26,628 unanalyzed CVEs since February 2024, estimated 484 days to clear at pre-crisis rate https://github.com/jgamblin/NVDAnalysisStatus

¹⁸ᵇ Cybersecurity Dive (January 2026). "NIST is rethinking its role in analyzing software vulnerabilities" — NIST admits "We're fighting a losing battle" and announces prioritization over comprehensive enrichment https://www.cybersecuritydive.com/news/nist-cve-vulnerability-analysis-nvd-review/810300/

¹⁹ See article 1 in this series: MITRE funding crises in 2024 and 2025

²⁰ Cybersecurity Dive, "CISA loses nearly all top officials as purge continues," May 2025 https://www.cybersecuritydive.com/news/cisa-senior-official-departures/748992/

²¹ See article 7 in this series: "The KEV covers roughly 0.5% of published CVEs"; the KEV requires a CVE for inclusion

²² See article 2 in this series: "85% of European security solutions rely on NVD data"

²³ GIS Reports, "U.S. cybersecurity policy under Trump," November 2025 https://www.gisreportsonline.com/r/trump-cyber/

²⁴ See article 4 in this series: "AI and the Collapse of the Western Defensive Model"

²⁵ Anthropic Frontier Red Team (February 2026). "0-Days" — Claude Opus 4.6 discovers 500+ validated high-severity vulnerabilities in major open-source projects without specialized scaffolding https://red.anthropic.com/2026/zero-days/

²⁵ᵇ Anthropic (February 2026). "Building AI Cyber Defenders" — Sonnet 4.5 reproduces known vulnerabilities in 66.7% of cases at 30 trials ($45/attempt); success rate doubled in six months https://www.anthropic.com/research/building-ai-cyber-defenders

²⁵ᶜ Music, N. et al. (2024). "Breaking Bad: How Compilers Break Constant-Time Implementations", ACM CCS — 44,604 targets analyzed, compiler vulnerabilities "widespread" across all tested configurations https://arxiv.org/abs/2410.13489

²⁵ᵈ "Fun with flags: How Compilers Break and Fix Constant-Time Code" (July 2025) — identification of responsible GCC/LLVM optimization passes, compiler flag mitigations https://arxiv.org/abs/2507.06112

²⁶ Google Project Zero "Big Sleep" (October 2024), first exploitable vulnerability (SQLite) discovered by an AI agent; Microsoft Security Copilot (March 2025), 20 flaws in GRUB2, U-Boot and Barebox bootloaders https://projectzero.google/2024/10/from-naptime-to-big-sleep.html https://www.microsoft.com/en-us/security/blog/2025/03/31/analyzing-open-source-bootloaders-finding-vulnerabilities-faster-with-ai/

²⁷ Regulation (EU) 2024/2847 — application timeline: reporting September 11, 2026, full conformity December 11, 2027 https://orcwg.org/cra/

²⁸ Directive (EU) 2024/2853 — national transposition by December 9, 2026 at the latest https://iclg.com/practice-areas/product-liability-laws-and-regulations/01-the-new-eu-product-liability-directive