EU Product Liability Directive: The EOL Open Source Problem

If your organization builds software, or products that run on software, and sells them into the European Union, the legal ground under your product stack is about to shift, and end-of-life open source is where it hits hardest. The EU Product Liability Directive (PLD), Directive (EU) 2024/2853, entered into force on 8 December 2024. Member states must transpose it into national law by 9 December 2026, and from that date it applies to every product placed on the EU market. For the first time, software is explicitly a “product,” and a defect in it can lead to strict, no-fault liability for damages — with exposure lasting 10 years, or 25 years for latent personal injury.

Most of the conversation around the new PLD focuses on AI, digital services and the end of the 1985 regime. Those matter. But there is one change that should be top of mind for senior leadership and for every engineering and security team shipping products built on open source: the PLD turns end-of-life (EOL) software in your product into a liability exposure, not just a technical debt item.

The PLD does not care that your upstream framework reached end of life. It cares whether you — as the manufacturer placing a product on the EU market — kept that product safe, including by providing the security updates within your control. If you didn’t, a claimant no longer has to prove you were negligent. They only have to show a defect, damage and a causal link.

What the EU Product Liability Directive Actually Says About End-of-Life Software

The PLD covers software however it is supplied: standalone, embedded in hardware, or delivered as a service (Article 4). The moment your company places a product containing open source code on the EU market, you are its manufacturer — and the liability for every component inside it attaches to you.

Four interlocking provisions create the EOL problem:

The Security Update Rule (Article 11(2))

Under the 1985 directive, a manufacturer could argue a product was not defective when it was first sold. The new PLD removes that defence where the defect comes from software, a software update, or the lack of a software update or upgrade necessary to maintain safety, provided it was within the manufacturer’s control. If an EOL component in your product has a known vulnerability and you neither patched it nor replaced it, that defence is gone.

The Cybersecurity Standard of Safety (Article 7)

A product is defective when it does not provide the safety a person is entitled to expect. In assessing that, courts consider relevant product safety requirements, including safety-relevant cybersecurity requirements such as those in the Cyber Resilience Act. Inadequate cybersecurity is now a recognized route to defectiveness.

Disclosure and Presumptions (Articles 9 and 10)

Once a claimant presents a plausible case, a court can order you to disclose relevant evidence. Defectiveness is presumed if you fail to disclose, if the product breaches mandatory safety requirements meant to protect against the harm that occurred, or if the damage follows an obvious malfunction. Where technical complexity makes proof excessively difficult, as it often does with software, courts can presume defect or causation. Your software bill of materials (SBOM), patch history and vulnerability records become evidence.

The Open-Source Exclusion (Article 2(2))

Free and open-source software supplied outside a commercial activity is excluded. That protects volunteer maintainers. It does not protect the commercial products built on top of their work. When you ship that code, you own it.

These provisions operate together. An EOL dependency creates a cascading failure: no upstream patch exists, a known vulnerability stays open, the missing update is treated as within your control, and disclosure puts the unsupported component in front of a court.

Why the PLD Is Not Just a Technical Problem

The PLD is a liability regime, not a fines regime, and that makes its exposure harder to cap. Compensation covers death and personal injury (including medically recognized psychological harm), damage to property, and the destruction or corruption of data not used for professional purposes. Liable parties are jointly and severally liable, and the chain reaches manufacturers, component makers, importers, authorized representatives and, where no one else is in the EU, fulfilment service providers. Non-EU manufacturers cannot avoid it by staying outside the Union.

Critically, the PLD is lifecycle-wide. Liability runs for 10 years from the date a product is placed on the market, and 25 years for latent personal injury. A substantial modification or update after 9 December 2026 can also bring a legacy product into the new regime. Component decisions you make this year can be examined in court in 2036. If your product today contains AngularJS (EOL since December 2021), Angular 18 or earlier, Spring Security 5.x, Node.js 18 or Vue 2, you already have a component that no upstream maintainer will patch.

Two Real-World Examples of EOL CVEs Under the PLD

CVE-2026-22732: Spring Security — CVSS 9.1 (Critical)

This critical vulnerability causes HTTP security response headers to silently not be written when responses are committed before Spring Security’s filter chain can write them. Headers such as Cache-Control, X-Frame-Options, Strict-Transport-Security and Content-Security-Policy are simply absent. It affects Spring Security versions back to 5.7.x, and for EOL versions there is no upstream patch. If your EU product relies on legacy Spring Security, you have:

• A critical, publicly known vulnerability in a component with no upstream fix
• A “missing security update” that a court may treat as within your control under Article 11(2)
• A cybersecurity shortfall that supports a finding of defectiveness under Article 7
• An SBOM and patch history that disclosure under Article 9 can put in front of a claimant

CVE-2026-27970: Angular — XSS via i18n ICU Messages (CVSS 7.6, High)

This cross-site scripting vulnerability affects Angular’s internationalization pipeline. When ICU messages contain HTML that is not properly sanitized, an attacker who compromises translation files can inject JavaScript that runs in the victim’s browser. Angular versions up to 18.2.14 are affected, and the Angular team does not backport security fixes to EOL versions. If your EU product uses an EOL Angular version, you have:

• A known XSS vulnerability in a component with no upstream patch
• Exposure to claims for corrupted or destroyed personal data if the flaw is exploited
• No “state of the product at release” defence for a missing update within your control
• A dependency record that is hard to defend once a court orders disclosure

The HeroDevs Vulnerability Directory tracks hundreds of CVEs across EOL frameworks still widely deployed in enterprise products, including Spring Boot, Node.js, .NET, AngularJS, Angular and many more.

So What Do You Actually Do About EOL Open Source Under the PLD?

The long-term answer is migration to a supported version. But anyone who has led a major framework migration knows the reality: these projects take months or years, need extensive regression testing, compete with roadmap priorities and consume significant engineering capacity. Rushing one to beat a legal deadline creates new risk of its own.

The 9 December 2026 date is not waiting for your migration to finish. Every product you place on the EU market from that day carries a decade of liability exposure for the components inside it. This is where HeroDevs Never-Ending Support (NES) comes in.

NES provides commercial long-term support for open source software that has reached end of life. HeroDevs engineers maintain the EOL codebases, backport security fixes, and publish patched releases as drop-in compatible packages through standard registries (npm, Maven, NuGet and more). No architectural changes required.

How NES Changes the PLD Picture

Liability under the PLD attaches to you as manufacturer because you place the product on the market. NES changes the practical reality of defending it.

When HeroDevs provides NES for an EOL component, that component has an active vendor providing security patches, a CVE response process and fixes published on a documented timeline. HeroDevs NES closes the “missing security update” gap that Article 11(2) turns into liability.

• Security updates: Patches exist for your EOL components, so a known vulnerability is not left open. The update that Article 11(2) asks about is one you actually provided.
• Cybersecurity safety: Supported, patched components help your product meet the safety-relevant cybersecurity expectations courts weigh under Article 7, including those set by the Cyber Resilience Act.
• Disclosure readiness: If a court orders disclosure under Article 9, your SBOM shows supported components with an active vendor and patch history, not unsupported EOL dependencies.
• Audit trail: NES provides a contractual commitment to patch critical vulnerabilities, with release history and documentation to demonstrate a duty of care across the liability window.
• Migration runway: NES bridges the gap between “we know we need to migrate” and “the migration is done,” so your team can modernize on a defensible timeline while your products stay protected.

Common Questions

Does the PLD only apply to EU companies?

No. The PLD applies to products made available on the EU market, wherever the manufacturer is based. If the manufacturer is outside the EU, the importer, authorized representative or fulfilment service provider can be held liable instead, and they will expect you to stand behind your product.

Isn’t open source exempt from the PLD?

Only when it is supplied outside a commercial activity. The exclusion protects volunteer maintainers, not the businesses that integrate their code into commercial products. Once you ship it, you are the manufacturer.

My EOL dependency is deep in the stack. Does it still count?

Yes. Liability covers defects in the product as a whole, and the chain expressly reaches the makers of defective components. A deep infrastructure library with an unpatched CVE is still part of the product you placed on the market.

What about products already on the market before 9 December 2026?

Products placed on the market before that date stay under the 1985 rules. But a substantial modification or update made after 9 December 2026 can bring them under the new regime, and every new release you ship from that date is covered.

How does the PLD relate to the Cyber Resilience Act?

They reinforce each other. The CRA sets mandatory cybersecurity requirements and vulnerability-handling duties, with reporting from 11 September 2026 and full application from 11 December 2027. Under the PLD, breaching mandatory safety requirements like these can lead a court to presume your product is defective.

The Bottom Line

The EU Product Liability Directive is in force, and from 9 December 2026 it applies to every product placed on the EU market. It makes software a product, treats cybersecurity as part of safety, and removes the defence for a missing security update you could have provided. For any product built on EOL open source, that is a decade-long liability exposure.

If your products sold into the EU contain EOL open source dependencies — and nearly all enterprise stacks do — the question is not whether this is a risk. It is. The question is what you do about it before 9 December 2026.

HeroDevs Never-Ending Support is one of the most cost-effective ways to close that gap: it restores active vendor support for EOL components, keeps them patched against new vulnerabilities, and gives your legal and compliance teams a defensible record of the care you took.

Start by understanding what is in your stack. The HeroDevs End of Life Dataset is a free resource that tracks 12 million+ package versions and identifies which EOL frameworks have known, unpatched CVEs — and what NES support is available for them.