Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Build-Tools bergen Produktionsrisiken, selbst wenn sie niemals als Laufzeitcode der Anwendung ausgeliefert werden.
- Webpack veröffentlicht keine LTS-Zweige, und Fehlerbehebungen werden in der aktiven 5.x-Reihe bereitgestellt und nicht in älteren Nebenversionen.
- Code, der während der Build-Phase ausgeführt wird, läuft mit den Quellen, Anmeldedaten und Tokens, auf die der Build-Prozess Zugriff hat.
- Ein erneuter Build mit demselben anfälligen Webpack ändert nichts, da die Schwachstelle jedes Mal erneut ausgegeben wird.
Die meisten Programme zur Schwachstellenerkennung nehmen die Build-Kette stillschweigend aus. Sie befindet sich in den „devDependencies“, wird niemals auf einem Produktionsserver ausgeführt, und wenn sie in einem Scan-Bericht auftaucht, wird sie mit einem Achselzucken abgetan und landet ganz unten auf der Warteliste. Diese Logik erscheint sinnvoll, solange eine Abhängigkeit niemals in die Produktion gelangt. Bei Webpack versagt sie jedoch in zweierlei Hinsicht.
In diesem Beitrag wird erläutert, wie das Support-Modell von Webpack tatsächlich funktioniert, warum eine festgelegte 5.x-Nebenversion in der Praxis als nicht unterstützter Code gilt und wie man die Build-Kette als Angriffsfläche betrachtet, ohne dabei jede Veröffentlichung zu verzögern.
Der Build läuft immer noch, also rührt ihn niemand an
Die Webpack-Konfiguration in einem älteren Repository gilt als unantastbar, da sie weiterhin funktioniert und niemand derjenige sein möchte, der sie kaputtmacht. Stabile Build-Systeme haben die Angewohnheit, zur ältesten Software im Unternehmen zu werden – nichts zwingt jemals jemanden dazu, sich diese noch einmal genauer anzusehen.
Dann findet eine Triage-Besprechung statt. Ein Scanner meldet eine Webpack-CVE, jemand wirft einen kurzen Blick darauf, sagt: „Das betrifft nur die Build-Phase“, und das Ticket rutscht in der Warteschlange hinter alles zurück, was wie ein echtes Produktionsrisiko wirkt. Die Argumentation klingt plausibel. Sie ist jedoch in zweierlei Hinsicht falsch.
Der erste Fehler besteht darin, die Ausgabe von Webpack als etwas vom Bundler selbst Getrenntes zu betrachten. Webpack bindet seinen eigenen Laufzeitcode in das Bundle ein, sodass ein Fehler in diesem Laufzeitcode zu einem Fehler in der von Ihnen ausgelieferten Anwendung wird.
Zweitens wird davon ausgegangen, dass ein Build-Tool nur zum Zeitpunkt des Builds zugänglich ist. Der Entwicklungsserver weist eine eigene Klasse von Schwachstellen auf, die sich direkt gegen die Entwickler richten, die ihn betreiben. Und das tiefer liegende Problem besteht darin, „devDependencies“ überhaupt als Risikoeinstufung zu betrachten. Es handelt sich um eine Paketbezeichnung, nicht um eine Sicherheitsgrenze. Ein Bundler macht dies nur besonders deutlich, da ein Teil dessen, was er generiert, letztendlich in der Produktion landet.
Webpack 4 ist fertig, und Webpack 5 hat keine LTS-Version.
Webpack veröffentlicht weder einen LTS-Kalender noch eine Support-Matrix noch einen Zeitplan für die Einstellung des Supports. Fehlerbehebungen fließen in die aktiv weiterentwickelte 5.x-Reihe ein und nicht in die gepflegten älteren Zweige; daher kann eine Minor-Version, an der Sie festhalten, in dem Moment ins Hintertreffen geraten, in dem etwas im Upstream behoben wird.
Webpack 4 wurde im Februar 2018 veröffentlicht, Webpack 5 folgte im Oktober 2020, und die 4.x-Reihe endete im September 2023 mit der Version 4.47.0. Die Umstellung von Version 4 auf Version 5 hat das Ökosystem Jahre gekostet, und viele Teams haben sie nie abgeschlossen. Wenn Sie noch mit Version 4 arbeiten, führen Sie Code aus, für den es keinerlei Upstream-Korrekturen mehr gibt.
Webpack 5 ist stabiler, allerdings nur an der Oberfläche. Die aktuelle Version ist 5.110.3, veröffentlicht im September 2026, und die beiden unten aufgeführten Korrekturen verdeutlichen das praktische Problem, da jede davon in einer neueren 5.x-Version enthalten war und nicht als Backport für die älteren, betroffenen Nebenversionen bereitgestellt wurde. Das Projekt Roadmap 2026 Es wurden die native CSS-Verarbeitung, ein universelles Kompilierungsziel, TypeScript ohne Loader sowie die Grundlagen für Webpack 6 eingeführt, und die Release-Reihe hat sich in all diesen Bereichen rasant weiterentwickelt. Die experimentelle TypeScript-Unterstützung wurde mit Version 5.107 eingeführt, und in der Version 5.110 wurden css-loader, style-loaderund mini-css-extract-plugin zugunsten der in Webpack integrierten CSS-Unterstützung. Mit anderen Worten: Die gepatchte Version im Upstream ist auch diejenige, die sich unter Ihrer Nase ständig ändert.
Wussten Sie schon: Die Angabe „Webpack 5“ sagt so gut wie nichts über Ihren Patch-Status aus. Ein Repository, das auf Version 5.76.1 festgesetzt ist, liegt mehr als dreißig Minor-Releases hinter der aktuellen Patch-Reihe zurück, auch wenn Webpack 5 nach wie vor die aktuelle Major-Version des Projekts ist.
Genau diese Lücke zwischen „unterstützter Hauptversion“ und „gepatchter Version“ macht Audits zu einer heiklen Angelegenheit. Stellen Sie sich ein Frontend einer Bank vor, das an eine bestimmte 5.x-Minor-Version gebunden ist, weil die Pipeline zertifiziert ist und jede Änderung an der Toolchain eine erneute Zertifizierung des gesamten Systems erforderlich macht. Ein Wechsel des Bundlers würde bedeuten, diesen Prozess erneut durchlaufen zu müssen, daher bleibt die Bindung bestehen – und mit ihr der nicht unterstützte Code. Genau für diese Situation ist der erweiterte Support gedacht: Er ermöglicht es einem Team, auf einem Zweig auf dem neuesten Stand zu bleiben, von dem es nicht ohne Weiteres abweichen kann.
Manche Fehler im Bundler landen im Browser
Einige Webpack-Sicherheitslücken treten gar nicht erst im Build-Schritt auf. Sie befinden sich in dem Code, den Webpack in Ihr Bundle schreibt. Deshalb gehört der Bundler zu Ihrer Angriffsfläche in der Produktion und nicht nur auf Ihre Checkliste für die Build-Phase.
43788 ist das saubere Beispiel. Es handelt sich um ein Gadget, das das DOM durcheinanderbringt, in Webpacks AutoPublicPathRuntimeModule, und das gilt, wenn output.publicPath ist nicht gesetzt oder auf auto. In der Meldung des Upstream-Entwicklers werden Versionen vor 5.93.0 als betroffen und 5.94.0 sowie spätere Versionen als gepatcht aufgeführt; das NVD stuft das Risiko mit einem Wert von 6,4 als „mittel“ ein. Gut zu wissen, dass auto ist die effektive Standardeinstellung für Web- und Web-Worker-Ziele, wenn niemand publicPath, es handelt sich also nicht um eine ungewöhnliche Konfiguration.
Die Einstufung „Medium“ wird dem tatsächlichen Sicherheitsrisiko nicht gerecht. Der Sicherheitshinweis berichtet von einer realen Ausnutzung in Canvas LMS, und der anfällige Code wird in das Bundle generiert und ist nicht auf einen CI-Runner beschränkt. Die Ausnutzung erfolgt jedoch nicht automatisch. Es bedarf einer Seite, die von Webpack generierte Dateien enthält und es einem Angreifer ermöglicht, skriptfreies HTML mit unzureichend bereinigten name oder id Attribute. Wenn diese Bedingungen erfüllt sind, kann das Gadget beeinflussen, von wo aus Ihre Skripte geladen werden – und das ist ein Cross-Site-Scripting-Pfad, der in den Browsern Ihrer Nutzer ausgeführt wird und von Ihrem Build-Tool bereitgestellt wird.
28154 ist der aufschlussreiche Kontrast, da es den Build nie verlässt. Es handelt sich um ein Problem beim realmübergreifenden Objektzugriff in ImportParserPlugin Fehlerhafte Verarbeitung von „magischen“ Kommentaren, der Webpack-Versionen vor 5.76.0 betrifft. Während der Kompilierung könnte ein Angreifer, der Einfluss auf das betreffende nicht vertrauenswürdige Objekt nehmen kann, dazu führen, dass Webpack auf das globale Objekt des Host-Realm zugreift. Das NVD stuft diese Schwachstelle mit 9,8 als „kritisch“ ein, während Red Hat dieselbe Schwachstelle mit 9,1 bewertet.
Ein Neuaufbau mit demselben anfälligen Webpack hilft aus unterschiedlichen Gründen in keinem der beiden Fälle. Der Laufzeittcode hinter CVE-2024-43788 wird so lange in jedes Bundle neu eingebunden, bis Webpack selbst gepatcht wird, und CVE-2023-28154 liegt in Webpacks eigener Kommentaranalyse, sodass es so lange bestehen bleibt, wie diese Version die Kompilierung durchführt. Beide Korrekturen sind im Upstream bereits seit Jahren verfügbar.
Vorsicht: Bevor jemand über die Schweregrade diskutiert, sollte man zunächst die Version und die Konfiguration überprüfen. In der Sicherheitsempfehlung werden Webpack-Versionen vor 5.93.0 als betroffen und 5.94.0 und höher als gepatcht aufgeführt. Daher sollten alle Versionen unter 5.94.0 überprüft werden, und output.publicPath nicht eingestellt oder eingeschaltet auto Dadurch wird die betroffene Laufzeitumgebung in Ihr Bundle aufgenommen. Prüfen Sie anschließend, ob Ihre Anwendung es Benutzern ermöglicht, HTML-Code einzufügen, der nicht bereinigt wurde name oder id Eigenschaften, da diese Bedingungen für die Verwertbarkeit von zentraler Bedeutung sind.
Eine Abhängigkeit von der Entwicklungsphase bedeutet nicht, dass das Risiko gering ist
Selbst die Schwachstellen, die auf die Build-Phase beschränkt bleiben, sind nicht zu unterschätzen, da der Code in dieser Phase auf zahlreiche Ressourcen zugreifen kann. Ein Bundler wird mit den Ressourcen ausgeführt, die im Build-Prozess verfügbar sind – dazu gehören in der Regel Ihre Quelldateien, Ihre Umgebungsvariablen, Ihre Anmeldedaten und in vielen Pipelines auch Ihre Veröffentlichungstoken. Das ist ein reichhaltiges Angriffsziel.
30359 und die damit zusammenhängenden 30360 Beide führen zum Diebstahl von Quellcode aus dem webpack-dev-server und wurden in Version 5.2.1 behoben, allerdings auf unterschiedliche Weise. Die erste nutzt die Tatsache aus, dass eine klassische Skriptanfrage von einem <script> Das Tag unterliegt nicht der Same-Origin-Policy, sodass eine bösartige Seite ein Bundle von einem laufenden Entwicklungsserver abrufen und mit ein wenig „Prototype Pollution“ den Quellcode wieder aus __webpack_modules__ unter Verwendung von Function::toString. Der zweite Fall betrifft das siteübergreifende WebSocket-Hijacking, bei dem die Herkunftsprüfung IP-Adressen als Herkunft zuließ, wodurch Entwickler, die Browser ohne Chromium-Basis verwenden, gefährdet wurden; diese Schwachstelle betrifft Versionen bis einschließlich 5.2.0.
Was jetzt aber noch wichtiger ist: Mit Version 5.2.1 war die Sache noch nicht abgeschlossen. Diese Korrektur stützte sich auf die Sec-Fetch-Mode und Sec-Fetch-Site Header, die Browser nur für potenziell vertrauenswürdige Ursprünge senden; daher fehlen diese Header bei einfachem HTTP, sodass die Überprüfung vollständig übersprungen wird. Die Sicherheitslücke (CVE-2026-6402) betrifft webpack-dev-server bis einschließlich Version 5.2.3 und wird in Version 5.2.4 durch die Einstellung Cross-Origin-Resource-Policy: same-origin. Die Bereitstellung des Entwicklungsservers über HTTPS ist eher eine dokumentierte Notlösung als ein Ersatz für ein Upgrade. Mit Version 5.2.5 wurde dann die Sicherheitslücke CVE-2026-9595 behoben, bei der ein weitreichender Benutzerproxy mit ws: true würde den eigenen HMR-WebSocket des Entwicklungsservers abfangen und an das Proxy-Ziel weiterleiten, einschließlich Cookies und Origin-Header. Danach wurde in Version 5.2.6 eine Schwachstelle für Cross-Site-Request-Forgery über den internen Open-Editor und die „invalidate“-Endpunkte behoben, ebenso wie ein Denial-of-Service, der durch einen fehlerhaften „Host“- oder „Origin“-Header ausgelöst wurde; das Paket selbst ist inzwischen auf Version 6.0.0 fortgeschritten. Diese Reihe von Korrekturen ist ein gutes Argument dafür, Fundstellen auf dem Entwicklungsserver nicht als „Hintergrundrauschen“ abzutun.
Überlegen Sie, wer dadurch gefährdet ist. Der veröffentlichte Angriff für CVE-2025-30359 umfasst eine bösartige Seite, die ein Bundle von einem Entwicklungsserver auf „localhost“ anfordert – es reicht also bereits aus, wenn ein Entwickler im Internet surft, während ein Entwicklungsserver läuft. Der Angreifer benötigt den Port und den Pfad zum Ausgangspunkt der Ausgabe, und beide sind in der Regel auf die Standardwerte eingestellt. Das betrifft auch Auftragnehmer auf Rechnern, die Sie nicht kontrollieren, sowie jeden, der einen Entwicklungsserver den ganzen Tag über laufen lässt, während er im Internet surft – und nichts davon wird bei einem auf die Produktion ausgerichteten Scan erkannt.
Aus der Praxis: Jemand stellt host zu 0.0.0.0 um es auf einem Smartphone zu testen, vergisst dann aber, die Einstellung wieder zurückzusetzen. Diese eine Änderung verwandelt ein Tool, das nur für den lokalen Rechner (localhost) bestimmt ist, in eines, das auf dem Netzwerk lauscht – was für Fehler von Bedeutung ist, die Netzwerkzugriff erfordern, wie beispielsweise der Denial-of-Service-Angriff durch fehlerhafte Header. Das ist jedoch nicht der Grund für den Cross-Origin-Quellcode-Diebstahl. Dieser funktioniert auch gegen den lokalen Rechner (localhost) einwandfrei.
Bei der Triage ging es also nie um die Frage „localhost“ versus „alles andere“. Es geht vielmehr um die genaue Version, die Sie verwenden, darum, ob Entwickler einen Entwicklungsserver laufen lassen, während sie im Internet surfen, ob dieser über einfaches HTTP bereitgestellt wird und wie leicht der Port und der Ausgabepfad zu erraten sind.
Ein System mit Version 5.2.3 und Standardeinstellungen weist unabhängig von der Bind-Adresse eine tatsächliche Sicherheitslücke auf. HTTPS mindert zwar das Risiko der Quellenoffenlegung in CVE-2026-6402, hebt jedoch die danach veröffentlichten Sicherheitshinweise nicht auf, sodass Version 5.2.4 keine allgemeine Sicherheitsgarantie darstellt. Die Korrekturen für die 5.x-Version reichen bis zur Version 5.2.6, und jede betroffene Sicherheitswarnung muss individuell geprüft werden, anstatt eine pauschale Entscheidung zu treffen.
Die versteckte Migration ist umfangreicher als Webpack
Der Grund, warum diese Pins bestehen bleiben, ist nicht Faulheit. Die Umstellung einer ausgereiften Webpack-Konfiguration ist ein echtes Projekt, und Teams bleiben aus triftigen Gründen dabei – angefangen bei benutzerdefinierten Loadern und Plugins über frameworkspezifische, darüber liegende Build-Systeme bis hin zu Konfigurationen, die sich über Jahre hinweg durch Patches angesammelt haben, ausgabebezogenem Caching, nicht mehr unterstützten Node-Versionen, die noch immer in der CI-Umgebung vorhanden sind, und der schlichten Angst davor, eine Pipeline zu ändern, die niemand vollständig versteht.
Auch eine größere Änderung lässt die Dinge nicht einfach so, wie sie sind. Sie kann sich auf die Chunking-Struktur, die Modulauflösung, das Polyfill-Verhalten, die Verwaltung von Assets und die Form der Ausgabe auswirken. Das bedeutet, dass zwei Testpläne statt nur einem erforderlich sind, da sowohl der Build-Prozess als auch die daraus resultierende Anwendung validiert werden müssen.
Es ist sinnvoll, „Webpack“ nicht mehr als einen einzigen Posten zu betrachten, sondern es danach aufzuteilen, wo die einzelnen Komponenten tatsächlich ausgeführt werden. Genau diese Art von Ausnutzungskontext soll ein Dokument des „Vulnerability Exploitability eXchange“ (VEX) vermitteln, indem es festhält, dass ein Loader auf einem CI-Runner und Laufzeitcode innerhalb eines ausgelieferten Bundles nicht das gleiche Risiko darstellen.
| Komponente | Wo es ausgeführt wird | Erreicht Produktionsleistung | Triage-Priorität |
|---|---|---|---|
| von webpack generierter Laufzeitcode | Zuerst kompilieren, dann im Browser | Ja, wenn sich das betroffene Laufzeitmodul im Bundle befindet | Hoch |
| webpack-dev-server | Entwicklerrechner sowie das lokale Netzwerk, sofern dieses offen zugänglich ist | Nein | Abhängig von Version und Konfiguration; am höchsten bei Versionen, für die entsprechende Sicherheitshinweise vorliegen |
| Lader und Plugins | Build-Dauer, bei CI oder in der Entwicklung | Manchmal, das hängt vom Lader ab | Von Fall zu Fall |
| Transitive Build-Dienstprogramme | Erstellungszeit | Selten | Niedrig, sofern nicht erreichbar |
Ein Entscheidungsrahmen für einen Legacy-Build
Weitermachen in 5.x
Wenn die Konfiguration dokumentiert ist und die zugehörigen Abhängigkeiten gepflegt werden, sollten Sie auf die aktuelle 5.x-Version umsteigen. Das ist der kostengünstigste Weg und stellt Ihre Patch-Versorgung wieder her. Erledigen Sie das noch in diesem Sprint, anstatt es auf das nächste Quartal verschieben zu lassen.
Die Pipeline neu aufbauen
Wenn die historische Komplexität ihren Nutzen überholt hat, sind Rspack, Vite und esbuild alle eine ernsthafte Betrachtung wert. Seien Sie sich jedoch über die Kosten im Klaren. Sie sind zwar schneller, aber das Umschreiben einer ausgereiften Konfiguration mit benutzerdefinierten Ladern, Module Federation oder sorgfältiger Code-Aufteilung ist ein echtes Projekt, bei dem am Ende für den Nutzer nichts Sichtbares dabei herauskommt.
Die angeheftete Version patchen und den Migrationsaufwand gering halten
Wenn die Pipeline zertifiziert ist, wird der Bundler in diesem Jahr nicht entfernt. Hier macht sich der erweiterte Support bezahlt: Er hält den festgesteckten Zweig in einem gepatchten Zustand, während Sie den größeren Umstieg nach Ihrem eigenen Zeitplan planen, anstatt unter Zeitdruck handeln zu müssen. Der „Endless Lifecycle Support“ von TuxCare umfasst Webpack 5.50.0, 5.55.0, 5.76.1, 5.88.2 und 5.94.0 sowie Webpack-Dev-Server-Versionen von 2.7.1 bis 5.2.2, die über npm bereitgestellt werden.
Man sollte sich jedoch darüber im Klaren sein, was bei einem Backport erhalten bleibt. Dabei bleiben Ihre Webpack-Version, Ihre Konfiguration und Ihre API-Oberfläche unverändert, wodurch der Umfang der Neuzertifizierung deutlich geringer ausfällt als bei einer vollständigen Migration der Toolchain. Was ein Backport jedoch nicht leisten kann, ist, das erzeugte Bundle byteweise identisch zu belassen, da die Korrektur von generiertem Laufzeitcode zwangsläufig eine Änderung dieses Codes erfordert.
Wie TuxCare den erweiterten Webpack-Support angeht
Eine erweiterte Unterstützung für ein Build-Tool bedeutet mehr, als nur eine alte Version am Laufen zu halten. Die eigentliche Arbeit steckt im Detail, und das meiste davon ist etwas, das ein internes Team nicht Monat für Monat wiederholen kann.
Zunächst werden Webpack und die damit verbundenen transitiven Abhängigkeiten überwacht; anschließend wird geprüft, ob ein gemeldetes Problem tatsächlich Auswirkungen auf den Legacy-Zweig hat, anstatt sich allein auf einen veröffentlichten Versionsbereich zu verlassen. Diese kontextbezogene Betrachtungsweise, die den EOL-Status und das Risiko transitiver Abhängigkeiten berücksichtigt, ermöglicht es einem Team, echte Sicherheitsrisiken zu priorisieren, anstatt jede einzelne Zeile in einem Scan-Bericht nachzuverfolgen.
Von dort aus werden die Korrekturen zurückportiert, ohne die architektonischen Änderungen mitzubringen, die spätere Versionen enthalten. Jede gepatchte Version wird auf Kompatibilität und Regressionen geprüft, damit etablierte Build-Pipelines weiterhin funktionieren – was in der Regel der eigentliche Einwand gegen das Patchen von Komponenten in einem zertifizierten Stack ist. TuxCare versucht nicht, das Upstream-Webpack zu ersetzen. Die Aufgabe besteht in der langfristigen Betreuung der Versionen, die das Projekt hinter sich gelassen hat, einschließlich der Regressionstests und Kompatibilitätsarbeiten, die Produktionssysteme tatsächlich benötigen. Jede gepatchte Version wird mit einer Software-Stückliste (SBOM) und einem VEX-Dokument ausgeliefert, und die Artefakte tragen separate GPG-Signaturen aus dem eigenen Registry von TuxCare.
OpenJS und die lange Lebensdauer wichtiger Werkzeuge
webpack ist ein OpenJS-Impact-Projekt, und das OpenJS-Ecosystem-Sustainability-Programm ( ESP) wurde ins Leben gerufen, damit archivierte, EOL- und ältere Versionen in den Genuss kommerzieller Sicherheitsleistungen kommen können, wobei ein Teil der Einnahmen an die Projekte und die Stiftung zurückfließt. TuxCare ist Gold-Mitglied und ESP-Partner, und da das Programm nicht exklusiv ist, steht es den Betreuern frei, jede beliebige Version zu unterstützen.
Ihre Build-Pipeline ist Teil des Produkts, auch wenn die Kunden sie nie zu Gesicht bekommen. Ein Legacy-Build verdient denselben Lebenszyklusplan wie die Anwendung, die er hervorbringt – und keine dauerhafte Ausnahme von dem Plan, den Sie bereits überall sonst anwenden.
