Keep pinned webpack builds secure without rewriting your config or upgrading your loader chain
Endless Lifecycle Support delivers CVE fixes for out-of-support versions of webpack, covering the bundler and dependencies still building legacy front ends, design systems, internal tools, and production bundles.
Jump to:
Talk to Us
Ask about coverage, SLAs, pricing, or anything else.
-
webpack 5.50.0
Covered by ELS
-
webpack 5.55.0
Covered by ELS
-
webpack 5.76.1
Covered by ELS
-
webpack 5.88.2
Covered by ELS
-
webpack 5.94.0
Covered by ELS
webpack patches security issues only in its newest 5.x release, and webpack 4 has had no release since 4.47.0 in September 2023.
ELS closes that gap without forcing a bundler upgrade.
Three steps to a patched webpack build
Add the TuxCare registry to your project’s .npmrc, replace the webpack dependency with the matching @els-js package manually or with the TuxCare Patcher, and reinstall. Verify the package with npm list, then run your build exactly as before.
What You Get with ELS
CVE Fixes for Out-of-Support webpack
When a new webpack vulnerability is disclosed, TuxCare investigates, patches, regression-tests, and ships a drop-in fix for your covered webpack version so a public CVE never becomes an open exposure window in your build pipeline or your shipped bundles.
On day 1
ELS gives you access to existing fixes for known CVEs affecting your covered webpack versions and their dependencies.
Drop in.
Don’t rebuild.
ELS replaces vulnerable webpack packages with secured, version-matched equivalents. Your loaders, plugins, config, and build output behave exactly as before. No code changes, no framework migration.
ELS installs through npm with a registry and dependency change, and an overrides block catches webpack pulled in transitively by CLIs and starters, and runs anywhere Node.js does:
local, CI runners, Docker, x86_64, and arm64.
Support That Holds Up to Review
SLA-Backed
Patch Delivery
TuxCare’s patch-delivery SLA helps you meet vulnerability-remediation expectations under SOC 2, FedRAMP, PCI DSS, HIPAA, DORA, and the CRA.
Enterprise Support
Guarantees
Commercial terms and contractual protections built for organizations that need more than best-effort community maintenance.
Ask a webpack Security Specialist
Let’s talk about extending security coverage for the webpack builds your applications depend on, from implementation and compliance requirements to CVE patching and pricing.
Secure Legacy webpack
Without Rebuilding Your Front End
Add ELS to your existing environment, keep the configuration, plugins, loaders, and build scripts your applications rely on, and address security risk while modernization moves forward at a pace that works for your team.
-
No emergency upgrade.
-
No mandatory config rebuild.
-
No dependence on upstream fixes that will never reach your pinned version.
Compatible across any environment that runs Node.js:
Docker
npmA head start on webpack security
Begin with existing fixes for your covered version and stay protected as new disclosures land.
| CVE | Product | Component | Severity | Status | Published |
|---|---|---|---|---|---|
| CVE-2026-2739 Transitive | webpack | webpack 3.3.0 | Medium | Not vulnerable | |
| CVE-2025-68458 Direct | webpack | webpack 5.55.0 | Low | Not vulnerable | |
| CVE-2025-68458 Direct | webpack | webpack 5.94.0 | Low | Patch available | |
| CVE-2025-68157 Direct | webpack | webpack 5.94.0 | Low | Patch available | |
| CVE-2024-43788 Direct | webpack | webpack 5.55.0 | Medium | Patch available | |
| CVE-2023-28154 Direct | webpack | webpack 5.50.0 | Critical | Patch available |
How Does It Work?
We onboard new projects and enable 24/7 automated CVE tracking – monitoring the NVD, vendor, and GitHub security advisories, and other sources.
Once CVEs are detected, we backport upstream fixes using algorithmic and AI-assisted automation, with expert validation to ensure accuracy.
Patches are compiled in a binary format, extensively tested (for integrity, functionality, and regression), signed, and deployed to ELS repositories.
Your package managers, build tools, or orchestrators check for updates, then automatically pull and install them.
How Teams Use ELS
Close the Build-Chain CVE Exposure Window
⚠️ The bind:
A vulnerability scanner flags a pinned webpack release inside a customer-facing front end, a shared design system, or an internal tool. webpack patches only its newest release, and moving up means retesting every loader and plugin in the chain.
🔄 The turn:
ELS gives covered webpack releases a commercial security-patching path again. Fixes are carefully backported and tested, helping teams remediate vulnerabilities without scheduling an emergency bundler upgrade.
Resolve an Outstanding Audit Finding
⚠️ The bind:
An internal audit, SOC 2 assessment, PCI DSS review, or customer security questionnaire identifies an unsupported webpack release. “It’s only a build dependency” rarely settles the finding, especially when webpack runtime code ships to the browser.
🔄 The turn:
ELS provides continued security coverage for eligible webpack releases under commercial terms. Compliance teams gain documented remediation, while developers gain the time needed to modernize without introducing unnecessary release risk.
Modernize on Your Schedule
⚠️ The bind:
A pinned webpack version often sits beneath forked loaders, an ejected starter config, custom plugins, and build logic your team did not write. Upgrading can change hashing, module IDs, and asset handling, breaking cache busting, reproducible builds, and CI.
🔄 The turn:
ELS protects the webpack version already producing your bundles without changing how the build behaves. Your team gets additional runway to plan, test, and complete modernization while legacy builds remain patched, supportable, and stable.
Why TuxCare?
420,000+
Patches Delivered
From the Team That Extends Open-Source Lifecycles
TuxCare keeps essential components protected long after upstream support ends, from the Linux kernel to JavaScript build tooling like webpack. One partner, whole-stack coverage.
14,000+
Vulnerabilities Fixed
Founding platinum sponsor of the AlmaLinux OS Foundation and member of the Open Source Security Foundation (OpenSSF).
TuxCare invests in the open-source projects it secures, from JavaScript build tooling to Linux, and beyond.
Learn more →
70,000+
Packages Curated
2,700+
Enterprise Clients
Related Insights
Top 5 Patch Management Tools in 2026: Full Review
Key Takeaways Patch management tools often look alike on a feature list, but they…
CVE-2026-98276 Was Fixed Upstream. Then a Server Crashed 12 Times.
KernelCare Rebootless Patches for CVE-2026-98276 Are Out for EL 8 and 9 TuxCare has…
The SSH Authentication Bypass That Lived Between OpenSSH and musl (CVE-2026-123158)
Key Takeaways A password of 257 to 1024 bytes logs in to any key-only…
Secure Your Unsupported webpack Versions
Talk to our team about protecting pinned webpack releases without a forced upgrade, a risky config rewrite, or waiting on upstream fixes that will never be backported.
Ask Us a Question
Frequently Asked Questions
The webpack team has never published a formal EOL date, but in practice webpack 4 is finished. Its last release was 4.47.0 in September 2023, and no security fixes have followed. npm still carries a webpack-4 tag pointing at that release, which is why some teams assume it is maintained. webpack 4 also still hashes with md4, which fails on Node.js 17 and later under OpenSSL 3 unless you run with the legacy provider flag.
ELS currently covers webpack 5.50.0, 5.55.0, 5.76.1, 5.88.2, and 5.94.0, along with selected webpack-dev-server releases from 2.7.1 to 4.15.2 and eligible covered dependencies. Additional versions may be added as customer requirements change. Contact TuxCare to discuss coverage for a release not listed.
webpack 5 remains actively developed, but security fixes ship in new package versions rather than being backported to every historical 5.x release. Even the newest covered release carries open upstream advisories: CVE-2025-68157 and CVE-2025-68458, both published in February 2026, are fixed only in 5.104.0 and 5.104.1, and both affect every release from 5.49.0 onward when experiments.buildHttp is enabled. A pinned project therefore has three options: upgrade, maintain a private fork, or use commercial extended support.
Sometimes it reaches production. CVE-2024-43788, fixed upstream in 5.94.0, was a DOM clobbering gadget in webpack's own runtime code that could lead to XSS in pages serving webpack-generated files, and security researchers demonstrated a working exploit in Canvas LMS. CVE-2023-28154, fixed in 5.76.0, allowed cross-realm object access during parsing. Scanners and auditors also flag unsupported devDependencies regardless of where they run.
With TuxCare ELS, configure the TuxCare npm registry, replace your webpack dependency with the matching @els-js/webpack package, add an overrides entry, reinstall your dependencies, and verify the result with npm list. The TuxCare Patcher can also detect supported webpack versions and update the relevant dependencies and overrides automatically.
No. ELS packages are version-matched replacements designed to preserve the behavior of the webpack release your project already uses. Your entry points, loaders, plugins, output rules, optimization settings, and npm scripts can all remain in place. Deployment requires registry and dependency configuration rather than a config rewrite, and the packages are Docker compatible, so they drop into containerized build and CI environments.
Upgrading is the preferred long-term approach when your project is ready. In practice a webpack upgrade can also require updates to Node.js, the webpack CLI, plugins, loaders, and deprecated configuration options, and it can change hashing, module IDs, or asset handling in ways that affect cache busting and reproducible builds. ELS keeps a covered version patched while your team plans and tests those changes on a manageable schedule.