Sorgen Sie für die Sicherheit Ihrer festgelegten Webpack -Builds, ohne Ihre Konfiguration umschreiben oder Ihre Loader-Kette aktualisieren zu müssen

Das Webpack-Team hat nie ein offizielles Enddatum veröffentlicht, aber faktisch ist Webpack 4 abgeschlossen. Die letzte Version war 4.47.0 im September 2023, und seitdem wurden keine Sicherheitsupdates mehr bereitgestellt. npm führt weiterhin ein webpack-4-Tag, das auf diese Version verweist, weshalb manche Teams davon ausgehen, dass Webpack 4 noch weiterentwickelt wird. Webpack 4 verwendet außerdem weiterhin MD4-Hashes, die unter Node.js 17 und höher mit OpenSSL 3 fehlschlagen, sofern nicht der Legacy-Provider-Flag verwendet wird.

ELS deckt derzeit webpack 5.50.0, 5.55.0, 5.76.1, 5.88.2 und 5.94.0 sowie ausgewählte Versionen des webpack-dev-server von 2.7.1 bis 4.15.2 und die entsprechenden Abhängigkeiten ab. Weitere Versionen können bei Bedarf hinzugefügt werden. Kontaktieren Sie TuxCare, um die Abdeckung für eine nicht aufgeführte Version zu besprechen.

Webpack 5 wird weiterhin aktiv weiterentwickelt, Sicherheitskorrekturen werden jedoch in neuen Paketversionen ausgeliefert, anstatt in alle älteren 5.x-Versionen integriert zu werden. Selbst die neueste betroffene Version weist offene Upstream-Sicherheitswarnungen auf: CVE-2025-68157 und CVE-2025-68458, beide im Februar 2026 veröffentlicht, sind nur in den Versionen 5.104.0 und 5.104.1 behoben und betreffen alle Versionen ab 5.49.0, wenn `experiments.buildHttp` aktiviert ist. Ein betroffenes Projekt hat daher drei Möglichkeiten: ein Upgrade durchführen, einen privaten Fork pflegen oder kommerziellen erweiterten Support nutzen.

Manchmal gelangt es in die Produktion. CVE-2024-43788, behoben in Version 5.94.0, war ein DOM-Manipulationswerkzeug im Laufzeitcode von Webpack, das zu XSS-Angriffen auf Seiten führen konnte, die von Webpack generierte Dateien auslieferten. Sicherheitsforscher demonstrierten einen funktionierenden Exploit in Canvas LMS. CVE-2023-28154, behoben in Version 5.76.0, ermöglichte den Zugriff auf Objekte über verschiedene Domänen hinweg während des Parsens. Scanner und Prüfer erkennen zudem nicht unterstützte Entwicklungsabhängigkeiten (devDependencies) unabhängig vom Ausführungsort.

Mit TuxCare ELS konfigurieren Sie die TuxCare npm-Registry, ersetzen Ihre Webpack-Abhängigkeit durch das passende @els-js/webpack-Paket, fügen einen Überschreibungseintrag hinzu, installieren Ihre Abhängigkeiten neu und überprüfen das Ergebnis mit `npm list`. Der TuxCare Patcher erkennt außerdem unterstützte Webpack-Versionen und aktualisiert die entsprechenden Abhängigkeiten und Überschreibungen automatisch.

Nein. ELS-Pakete sind versionsgleiche Ersatzpakete, die das Verhalten der bereits in Ihrem Projekt verwendeten Webpack-Version beibehalten. Ihre Einstiegspunkte, Loader, Plugins, Ausgaberegeln, Optimierungseinstellungen und npm-Skripte können weiterhin verwendet werden. Für die Bereitstellung sind lediglich Registry- und Abhängigkeitskonfigurationen erforderlich, nicht jedoch eine Konfigurationsänderung. Die Pakete sind Docker-kompatibel und lassen sich daher problemlos in containerisierte Build- und CI-Umgebungen integrieren.

Ein Upgrade ist die bevorzugte langfristige Vorgehensweise, sobald Ihr Projekt fertig ist. In der Praxis kann ein Webpack-Upgrade auch Aktualisierungen von Node.js, der Webpack-CLI, Plugins, Loadern und veralteten Konfigurationsoptionen erfordern. Zudem können sich Hashing, Modul-IDs oder die Asset-Verarbeitung so ändern, dass Cache-Busting und reproduzierbare Builds beeinträchtigt werden. ELS hält eine gepatchte Version bereit, während Ihr Team diese Änderungen in einem überschaubaren Zeitrahmen plant und testet.