From GDPR to EU CRA: "Best Effort" is Over for Open Source Software

Ten years ago the issue was personal data. Companies collected it at enormous scale, and the people it described carried the risk. The industry's answer was best effort: consent banners and "we take your privacy seriously." After enough breaches, the EU stopped accepting that. GDPR made data protection a legal duty, with reporting deadlines and fines tied to global revenue.

Swap personal data for open source software and the story barely changes. Enterprises build on open source at an enormous scale, the risk falls on everyone downstream, and the license says "as is, no warranty."

The EU's response is the EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847. It entered into force on 10 December 2024. Vulnerability reporting has applied since 11 September 2026, and the full requirements arrive on 11 December 2027. Fines reach €15 million or 2.5% of worldwide turnover, whichever is higher. Soon, "the upstream project stopped patching" will carry about as much weight with a regulator as "we didn't think anyone would breach us" did in 2018.

History Repeats: From GDPR to the CRA

GDPR followed a run of failures: Snowden in 2013, TalkTalk in 2015, then Yahoo, Uber and Cambridge Analytica. The EU adopted the law in 2016, and enforcement began in May 2018 with fines up to 4% of global revenue.

Open source has had its own run. Equifax in 2017 came down to one unpatched open source flaw and 147 million exposed records. SolarWinds in 2020 reached about 18,000 organizations. Log4Shell in 2021 put much of the internet at risk overnight. Regulation followed: NIS2, DORA, CMMC 2.0 and now the CRA. The US, Canada, Japan, Australia, India and Singapore are heading the same way.

PHP2Shell and HTTP2Shell: The CRA's First Real Test

On 21 October 2026, two critical vulnerabilities were disclosed on the same day.

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) allows unauthenticated remote code execution in PHP, which runs most of the web's server-side code. Every version from 5.4 through 8.5 is affected. The PHP project shipped fixes for 8.2 through 8.5 only. Versions 8.1 and older get no release, and Mallory counted about 1.9 million internet-facing services still reporting one of them. Amazon saw exploitation attempts four days before disclosure.

HTTP2Shell (CVE-2026-111497), also called Node2Shell, is an out-of-bounds write in Google's Brotli decoder, rated 9.2 Critical. It reaches Node.js, .NET, Python, Bun and Envoy. Node.js 22, 24 and 26 were patched. Node.js 20, which reached end of life in April 2026, and every older line back to 12 bundle the vulnerable decoder and won't get an upstream fix. Zscaler logged exploitation attempts within 24 hours.

Under the CRA, actively exploited vulnerabilities start the 24-hour reporting clock. If you run PHP 8.1 or Node.js 20 in a product sold into the EU, an assessor will ask one question: who is patching it?

Open Source Runs Deep, and AI Is Speeding Things Up

Black Duck's Open Source Security and Risk Analysis (OSSRA) finds open source in 97% of codebases, making up about 70% of the code, with roughly 900 components per application. Most are transitive, pulled in rather than chosen. Black Duck also found that open source vulnerabilities per codebase more than doubled year over year.

AI has sped up both sides. Anthropic's Project Glasswing used an AI model to find more than 10,000 high- and critical-severity vulnerabilities in open source projects in one month, far more than volunteer maintainers can fix. Sonatype has catalogued more than 1.3 million malicious open source packages. Discovery now outpaces patching.

What the Cyber Resilience Act Requires

The CRA covers "products with digital elements": almost any hardware or software that connects to a device or network, including the open source inside it. It makes whoever places the product on the EU market responsible for that open source. Like GDPR, it applies based on where you sell, not where you're headquartered. Pure SaaS (handled under NIS2), sectors with their own regimes such as medical devices and automotive, and non-commercial open source are largely out of scope.

Three requirements matter most for open source:

• Support period (Articles 13(8) and 13(9)). Declare a support period, generally at least five years, and handle vulnerabilities in every component throughout it. Security updates must stay available for at least 10 years after release.
• Reporting (Article 14, live now). Report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform: an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days of a fix. This applies to products already on the market.
• SBOM (Annex I, from 11 December 2027). Keep a machine-readable software bill of materials and ship without known exploitable vulnerabilities. Market surveillance authorities can use your SBOM to spot end-of-life components.

Penalties reach €15 million or 2.5% of global turnover for the core obligations, and authorities can pull products off the EU market.

Where It Bites Hardest: End-of-Life Open Source

HeroDevs and Sonatype research for 2026 found that 5–15% of components in a typical enterprise dependency graph are already end of life. The HeroDevs EOL Dataset shows more than 81,000 package versions with known CVEs and no fix path, and 93% of that risk sits in transitive dependencies. Scanners often show these components as clean because there's no patch to flag.

The list keeps growing. In Q2 2026, MySQL 8.0, Node.js 20, Django 4.2 LTS, Angular 19 and Spring Boot 3.5 all reached end of life within 90 days. Old versions also linger: the vulnerable Log4j release was downloaded 619 million times in 2025, four years after the fix shipped.

PHP2Shell and HTTP2Shell show where this leads. When a critical CVE lands, supported versions get a patch within hours and EOL versions get nothing. The CRA makes that gap your problem. The HeroDevs Vulnerability Directory tracks hundreds of these CVEs.

Same Four Requirements, Every Regime

Most of these laws ask for the same things:

1. Know what you run. An SBOM of every component, transitive ones included.
2. Fix on a clock. Often 30 days or less for critical issues.
3. Report fast. Serious incidents within 24 to 72 hours.
4. Prove it. Evidence an assessor can check on request.

NIS2 makes vulnerability handling a legal duty, with personal accountability for management. DORA treats unsupported systems as an operational resilience finding. FedRAMP and NIST SP 800-53 require high-severity flaws to be fixed within 30 days. One evidence trail (SBOM, patch record, remediation SLA) covers nearly all of them. The hard part is keeping it up for components that are end of life.

Two Paths for EOL Open Source When Time Is Short

Upgrade when you can. If a supported version fits your timeline, that's the right long-term answer.

Bridge when you can't. Framework migrations take months or years, and the reporting clock is already running. HeroDevs Never-Ending Support (NES) provides secure, drop-in replacements for end-of-life open source, including PHP, Node.js, AngularJS, Angular, Spring, .NET, Struts, Vue 2, Tomcat and Django. Our engineers, including original framework maintainers, backport fixes for CVEs found after end of life, and as a CVE Numbering Authority we find vulnerabilities ourselves. NES for PHP already covers PHP2Shell on versions 5.6 through 8.2, and remediated Node.js 20 builds for HTTP2Shell are in progress.

NES directly addresses the Annex I and Article 13(8)–(9) requirements for EOL components. It supports, but doesn't replace, your Article 14 reporting, SBOM work and third-party due diligence. It doesn't cover conformity assessment, CE marking or your own code.

Ask for Proof

More than 48,000 CVEs were published in 2025, and plenty of vendors now promise to fix them. Many of those fixes don't hold up. When 1Password tested AI-generated patches, only about one in four fully closed the vulnerability without breaking something. In our own testing of one vendor across 258 Spring CVEs, about two in three "fixed" CVEs had no working fix.

Ask any vendor, including us:

1. Which CVE IDs are fixed in which releases?
2. Where are your VEX statements?
3. How many CVEs has your team found itself?
4. After deployment, does a re-scan clear because the code changed, or only the version string?

What a Reviewer Wants to See

For each EOL dependency, keep three things: the version and its EOL date, the patch record, and a remediation SLA tracked in your issue tracker. Give every component one status: maintained upstream, under commercial support, or scheduled for replacement by a committed date. Anything without a status is what assessors look for.

A short playbook:

1. Generate SBOMs in CI on every release.
2. Treat EOL dates as compliance deadlines. Alert at 12 months, plan at 9.
3. Give every component a status.
4. Track remediation SLAs in the issue tracker, not a policy document.
5. Rehearse the 24-hour reporting flow before you need it.
6. Put lifecycle risk in writing for leadership.

Common Questions About the Cyber Resilience Act

Is the CRA only for EU companies?

No. If your products reach the EU market, directly or through partners, it applies.

Does our SCA scanner cover this?

Not fully. Scanners flag known CVEs. An EOL component can look clean today and have no fix tomorrow.

Does it apply to products already on the market?

Yes. Article 14 reporting applies now. Full requirements apply to products placed on the market from 11 December 2027, or substantially modified after that.

Does NES make us "CRA compliant"?

No single product does. NES covers vulnerability handling and patching for EOL components. Conformity assessment, CE marking and your own code are still on you.

The Bottom Line

GDPR turned best effort into a legal duty for personal data. The CRA is doing the same for software. Reporting has been live since September 2026, PHP2Shell and HTTP2Shell have already tested it, and the full requirements arrive in December 2027. Teams that build lifecycle tracking in now will treat these rules as paperwork. Teams that don't will treat them as emergencies.

• Take the CRA Readiness Check: 16 questions, about four minutes.
• Run a free EOL scan with the HeroDevs EOL Dataset, which tracks lifecycle data for more than 19 million open source packages.
• Talk to HeroDevs about Never-Ending Support or book a results review.

This article is general guidance, not legal advice, and is not a compliance certification. It is based on Regulation (EU) 2024/2847. Consult qualified counsel about your specific obligations.