Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- jQuery UI befindet sich seit Oktober 2021 im reinen Wartungsmodus, und nur die neueste Nebenversion erhält Fehlerbehebungen.
- jQuery UI 1.10.4 enthält drei bekannte XSS-Schwachstellen, die alle erst in Version 1.13.0 behoben wurden.
- jQuery-Versionen unter 3.5.0 weisen eine von der CISA gelistete, bereits ausgenutzte XSS-Sicherheitslücke auf, und eine jQuery-UI-Version aus dem Jahr 2014 erschwert dieses Upgrade.
- Realistische Möglichkeiten sind ein Upgrade auf 1.14.x, der Austausch der Widgets oder der Erwerb von erweitertem Support.
Zahlreiche Unternehmen, die zwischen 2008 und 2018 Webanwendungen entwickelt haben, verwenden immer noch irgendwo jQuery UI. Der Datumswähler in einem Spesenformular. Der modale Dialog in einem Admin-Panel. Die Autovervollständigung in einem internen Suchfeld. Diese Widgets funktionieren nach wie vor – und genau deshalb hat seit Jahren niemand mehr Hand daran gelegt. Das Problem ist, dass das Ende der Lebensdauer von jQuery UI still und leise eingetreten ist, während diese Anwendungen weiterliefen, und dass für ältere Versionen keine Sicherheitskorrekturen mehr aus dem Upstream-Projekt zurückportiert werden.
In diesem Beitrag geht es darum, wie es derzeit um die Unterstützung von jQuery UI steht, welche CVEs die noch im Einsatz befindlichen Versionen betreffen, warum die Abhängigkeit von jQuery mehr Beachtung verdient als die Bibliothek selbst und welche Optionen Ihnen nun offenstehen.
Abbildung 1: Die Widgets, die Sie sicher wiedererkennen werden.
Ist jQuery UI tatsächlich nicht mehr weiterentwickelt?
Für alle Versionszweige außer dem neuesten gilt dies in der Tat. Im Oktober 2021 haben die jQuery-Betreuer jQuery UI in den reinen Wartungsmodus versetzt und 1.13.0 als letzte geplante Version des Projekts angekündigt. Die Pläne haben sich seitdem etwas geändert, und es wurden weiterhin Versionen veröffentlicht, jedoch ausschließlich für Sicherheits-, Kompatibilitäts- und Regressionsarbeiten und nur für die neueste Nebenversion.
Da es keinen veröffentlichten EOL-Kalender für jQuery UI gibt, basieren die unten aufgeführten Daten auf der Richtlinie, wonach nur die neuesten Minor-Versionen berücksichtigt werden, und nicht auf offiziell angekündigten EOL-Mitteilungen.
| Zweigstelle | Status | Anmerkungen |
|---|---|---|
| 1.14.x | Wartung, erhält Fehlerbehebungen | Die aktuellste Version ist 1.14.2, veröffentlicht im Januar 2026. Es gibt keine Unterstützung für Internet Explorer oder Edge Legacy. |
| 1.13.x | Seit August 2024 nicht mehr unterstützt | Der Support endete mit der Veröffentlichung von Version 1.14.0 am 5. August 2024. Die letzte Version war 1.13.3 im April 2024. |
| 1.12.x | Seit Oktober 2021 nicht mehr unterstützt | 1.12.1 war die aktuelle Version von September 2016 bis zur Veröffentlichung von 1.13.0. |
| 1.11.x | Seit Juli 2016 nicht mehr unterstützt | Der Support endete mit der Veröffentlichung von Version 1.12.0. Die letzte Version war 1.11.4 im März 2015. |
| 1.10.x und früher | Seit Juni 2014 nicht mehr unterstützt | Die Version 1.10.4 wurde im Januar 2014 veröffentlicht und im Juni desselben Jahres durch die Version 1.11.0 abgelöst. |
In den unteren Zeilen wird es dann heikel. 1.12.1 war fünf Jahre lang die aktuelle Version und ist die Version, bei der viele Teams stehen geblieben sind, aber viele Anwendungen haben es nie so weit geschafft. 1.10.4 wurde im Januar 2014 veröffentlicht und erhielt noch im selben Jahr keine Fehlerbehebungen mehr, sodass alles, was noch darauf läuft, seit mehr als einem Jahrzehnt ohne einen Sicherheitspatch vom Upstream-Entwickler auskommt. Wenn Ihre App vor 2014 entwickelt wurde und niemand das Frontend bewusst aktualisiert hat, sollten Sie dies als Erstes überprüfen.
Abbildung 2: Die Unterstützungslücke über die verschiedenen Release-Linien hinweg.
Was das Ende der Unterstützung für jQuery UI für Ihre Anwendungen bedeutet
Eine veraltete UI-Bibliothek weist andere Schwachstellen auf als eine veraltete Server-Laufzeitumgebung. Der anfällige Code wird in den Browsern Ihrer Nutzer ausgeführt, auf Seiten, mit denen diese täglich interagieren, und bei den im Folgenden beschriebenen jQuery-UI-Schwachstellen handelt es sich ausschließlich um Cross-Site-Scripting-Schwachstellen und nicht um serverseitige Probleme.
Die bereits registrierten CVEs
In der Version 1.13 wurden vier XSS-Schwachstellen behoben. Drei davon reichen bis zur Version 1.10.4 zurück. Die vierte betrifft nur Version 1.12.0 und neuere Versionen, da das betroffene Widget zuvor noch nicht existierte.
41182 und 41183 ermöglichen die Einfügung von Skripten über den Datumswähler altField Option und deren *Text jeweilige Optionen. 41184 macht dasselbe über die of Option des .position() Dienstprogramm, das Widgets wie Tooltip und Autocomplete im Hintergrund nutzen. Alle drei wurden in Version 1.13.0 behoben, sodass eine Installation der Version 1.10.4 jedes einzelne davon enthält. Das vierte, 31160, handelt es sich um einen XSS-Angriff, der durch das Aktualisieren eines „Checkboxradio“-Widgets mit einer HTML-ähnlichen Beschriftung ausgelöst wird und in Version 1.13.2 behoben wurde. Dieses Widget wurde mit Version 1.12.0 eingeführt, sodass der anfällige Codepfad in den Versionen 1.10.4 und 1.11.x nicht vorhanden ist. Es lohnt sich jedoch, dies zu wissen, bevor Ihr nächster Scan-Bericht eintrifft, da der veröffentlichte Sicherheitshinweis alle Versionen unterhalb von 1.13.2 als betroffen kennzeichnet, ohne eine Untergrenze anzugeben; ein Scanner wird dies daher bei 1.10.4 ohnehin als Problem melden.
Ein Blick auf den zeitlichen Ablauf lohnt sich. Drei der vier Schwachstellen wurden bereits in Version 1.13.0 selbst behoben – jener Version, die zeitgleich mit der Ankündigung des Wartungsmodus veröffentlicht wurde –, wobei die entsprechenden Sicherheitshinweise erst einige Wochen später erschienen. Die vierte Schwachstelle wurde neun Monate nach Eintritt in den Wartungsmodus behoben. Auch nach Einstellung der aktiven Entwicklung tauchten weiterhin Schwachstellen auf. Was sich geändert hat, ist, wie weit die Korrekturen in der Vergangenheit zurückreichen.
Abbildung 3: Wo sich die CVEs in der Benutzeroberfläche befinden.
Was niemals zurückportiert wird
Die Wartungsrichtlinie gilt nur für die neueste Minor-Version. Wenn der nächste Fehler im Datepicker oder im Dialogfeld auftritt, wird er anhand von 1.14.x bewertet, dort behoben, sofern ein Patch erforderlich ist, und an allen anderen Stellen unverändert belassen.
In der Sicherheitsmitteilung wird wahrscheinlich angegeben, dass Ihr Zweig betroffen ist, da in jQuery-UI-Sicherheitsmitteilungen die betroffenen Bereiche wie folgt benannt werden: < 1.13.0 und < 1.13.2. Was es nicht geben wird, ist ein Backport. Für Teams, die mit „eingefrorenen“ Versionen arbeiten, beschreibt jeder zukünftige Sicherheitshinweis, der ihren Zweig erreicht, eine Sicherheitslücke, die niemand im Upstream schließen wird.
Wo Compliance-Rahmenwerke ihre Wirkung entfalten
Die Prüfungslogik ist für jede nicht mehr gepflegte Komponente dieselbe, wird jedoch je nach dem für Sie geltenden Rahmenwerk unterschiedlich umgesetzt. PCI DSS 4.x verlangt, dass Patches für kritische Sicherheitslücken innerhalb eines Monats nach ihrer Veröffentlichung installiert werden, während für alle anderen Fälle von Ihnen festgelegte, risikobasierte Zeitpläne gelten – und keine dieser Fristen lässt sich durch das Aufspielen von Patches leicht einhalten, wenn kein unterstützter Fix verfügbar ist. Wenn Ihre SOC-2-Kontrollen das Schwachstellenmanagement umfassen, erschwert eine nicht unterstützte Komponente den Nachweis, dass identifizierte Risiken tatsächlich behoben werden, sobald kein Fix vom Hersteller verfügbar ist – und genau an diesem Punkt beginnen die Auditoren zu hinterfragen, was Ihr Schwachstellenmanagement-Prozess tatsächlich leistet. Die Sicherheitsvorschrift der HIPAA verlangt von regulierten Einrichtungen, Risiken für ePHI zu identifizieren und auf ein angemessenes und geeignetes Maß zu reduzieren; daher wird ein bekanntes, nicht behebbares XSS-Problem in einem patientenorientierten Portal Teil dieser Analyse – ob Sie das wollen oder nicht.
Die Arbeit auf Bundesebene hat sich in letzter Zeit weiterentwickelt, und die alte Abkürzung ist mittlerweile veraltet. Die CISA hat die Richtlinie BOD 22-01 im Juni 2026 aufgehoben und durch die Richtlinie BOD 26-04 ersetzt, die die Fristen für Abhilfemaßnahmen für zivile Bundesbehörden nach dem Risiko der betroffenen Ressourcen, dem KEV-Status, der Automatisierung von Exploits und den technischen Auswirkungen staffelt, wobei die Fristen in den schlimmsten Fällen bereits nach drei Tagen ablaufen. FedRAMP orientiert sich an demselben risikobasierten Ansatz, und seine Vorschriften zur Erkennung und Behebung von Schwachstellen werden am 7. Dezember 2026 für Cloud-Dienstleister verbindlich; damit wird die pauschale 30-Tage-Frist für Schwachstellen mit hohem Schweregrad durch eine risikobasierte Bewertung ersetzt. Für Produkthersteller gilt eine eigene Regelung im Rahmen des Cyber-Resilience-Gesetzes der EU, wonach die Meldepflichten für aktiv ausgenutzte Schwachstellen am 11. September 2026 in Kraft treten, während die vollständigen Anforderungen zum Umgang mit Schwachstellen im Dezember 2027 folgen.
Keines dieser Frameworks stuft „Legacy-jQuery erkannt“ automatisch als Befund ein, da der Geltungsbereich, die Sichtbarkeit und die Ausgleichsmaßnahmen eine Rolle spielen. Doch Scanner melden veraltete Frontend-Stacks schnell, und unter jedem dieser Rahmenbedingungen bedeutet diese Meldung einen Arbeitsaufwand, den Sie rechtfertigen müssen.
Wie EOL jQuery UI das alte jQuery beibehält
Der Abhängigkeitsbaum von jQuery UI könnte kaum einfacher sein. Im aktuellen npm-Paket ist jQuery die einzige deklarierte Laufzeitabhängigkeit, die wie folgt festgelegt ist: jquery >=1.12.0 <5.0.0. Älterer jQuery-UI-Code wies zwar eine Abhängigkeit auf Komponentenebene vom jQuery-Mousewheel-Plugin innerhalb des Spinner-Widgets auf, die in Version 1.14.2 im Januar 2026 entfernt wurde, doch handelte es sich dabei nie um eine zweite explizit deklarierte Abhängigkeit. So oder so handelt es sich hierbei nicht um eine Komponente, die in einer Laufzeit-Binärdatei verborgen ist. jQuery wird in einem eigenen Script-Tag geladen, normalerweise in der Zeile über dem von jQuery UI, und die meisten Teams können ihre jQuery-Version schneller benennen als ihre jQuery-UI-Version. Das Risiko ist hier nicht versteckt. Es besteht eine Kopplung.
Beginnen wir mit dem, was bei dieser offensichtlichen Abhängigkeit auf dem Spiel steht. CVE-2020-11023, eine XSS-Schwachstelle, die alle jQuery-Versionen von 1.0.3 bis 3.4.1 betrifft, wurde im Januar 2025 in den Katalog der „Known Exploited Vulnerabilities“ der CISA aufgenommen, nachdem Hinweise auf eine Ausnutzung in der Praxis vorlagen; die Frist für die Behebung auf Bundesebene wurde auf den 13. Februar 2025 festgelegt. Die verwandte Schwachstelle CVE-2020-11022 betrifft dieselbe Familie von DOM-Manipulationen, und CVE-2019-11358 betrifft eine Prototyp-Verunreinigung in Versionen unter 3.4.0. Die Prototyp-Verunreinigung wurde in Version 3.4.0 behoben, die beiden XSS-Schwachstellen in Version 3.5.0, sodass alle hier genannten Probleme seit 2020 im Upstream-Code gepatcht wurden.
Warum laufen also sechs Jahre später immer noch Stacks mit jQuery 1.x oder 2.x? Für einige von ihnen ist jQuery UI ein Grund dafür, dass die Umstellung schwierig ist. jQuery UI 1.10.4 wurde im Januar 2014 veröffentlicht, mehr als zwei Jahre bevor es jQuery 3.0 gab, und das Projekt beschrieb später den Schwerpunkt von 1.13.0 als „Verbesserung der Kompatibilität mit aktuellen jQuery-Versionen“. Eine so alte Version kann unmöglich mit einer jQuery-Version getestet worden sein, die es damals noch gar nicht gab. Daher ist ein jQuery-Upgrade unter einer eingefrorenen 1.10-Bereitstellung eher eine Kompatibilitätsmaßnahme als eine Versionserhöhung. Das jQuery-Upgrade wartet auf das jQuery-UI-Upgrade, das wiederum auf ein QA-Fenster wartet, das nie ganz eintrifft. Eine Widget-Bibliothek am Ende ihrer Lebensdauer (EOL) verdeckt das jQuery-Risiko nicht. Sie kann jedoch dazu beitragen, es an Ort und Stelle zu fixieren.
Abbildung 4: Wie eine veraltete Widget-Bibliothek das jQuery-Upgrade erschweren kann.
Der erweiterte Support ist ein Weg, um aus dieser Sackgasse herauszukommen, ohne dass eines der beiden Upgrades vorzeitig erzwungen wird, und TuxCare stellt bereits Sicherheitspatches für ausgewählte jQuery-Versionen mit abgelaufenem Support (EOL) von 1.8.2 bis 3.4.1 bereit, sodass die jQuery-Schicht genau dort gepatcht bleibt, wo sie sich befindet.
Ihre Optionen nach dem Ende der Lebensdauer von jQuery UI
Welcher Weg der richtige ist, hängt davon ab, wie viel Frontend-Arbeit Sie derzeit bewältigen können. Wenn Sie die Patches installieren müssen, ohne eine funktionierende Benutzeroberfläche zu verändern, verschafft Ihnen der erweiterte Support für die jQuery-Schicht etwas Zeit. Wenn Sie eine jQuery-Migration und einen echten QA-Durchlauf einplanen können, ist ein Upgrade auf 1.14.x die sauberste Lösung. Und wenn das Frontend ohnehin neu entwickelt werden muss, ist es besser, jQuery UI im Rahmen dieses Projekts zu entfernen, als die Arbeit doppelt zu erledigen.
Gewinnen Sie Zeit durch erweiterten Support
Der „Endless Lifecycle Support“ von TuxCare für EOL-Versionen von jQuery sorgt dafür, dass die von Ihnen bereits verwendete Version stets auf dem neuesten Stand bleibt, und es gibt ein entsprechendes ELS-Paket für jQuery UI 1.10.4. Die Korrekturen werden auf diese Version zurückportiert, hinsichtlich des bestehenden Verhaltens getestet, signiert, durch ein SLA abgesichert und über npm bereitgestellt, sodass die Übernahme lediglich eine Änderung der Abhängigkeitskonfiguration und keine Framework-Migration erfordert. TuxCare deckt zudem ausgewählte EOL-Kernversionen von jQuery ab, sodass ein Team, das mit jQuery UI 1.10.4 und einer abgedeckten jQuery-Version arbeitet, beide Ebenen abdecken kann, ohne auf einer der beiden Seiten eine Framework-Migration durchführen zu müssen. Die öffentliche Support-Matrix listet bestimmte Versionen statt ganzer Zweige auf, und 1.10.4 ist die derzeit dokumentierte jQuery-UI-Version. Vergleichen Sie daher Ihre Version damit, bevor Sie entsprechende Planungen vornehmen.
TuxCare tut dies als Gold-Mitglied der OpenJS Foundation und als strategischer Partner im Rahmen des „Ecosystem Sustainability Program“ – einem nicht-exklusiven Programm, mit dem die Stiftung ihre Projekte mit kommerzieller Unterstützung für Versionen verknüpft, die sie nicht mehr selbst pflegt. Aktuelle Sicherheitslücken und Korrekturen können Sie außerdem im TuxCare CVE Tracker einsehen.
Der Sinn des erweiterten Supports besteht nicht darin, Sie für immer an einer alten Version festzuhalten. Er nimmt Ihnen den Zeitdruck, sodass das spätere Upgrade nach Ihrem eigenen Zeitplan erfolgt und ordnungsgemäß durchgeführt wird.
Auf 1.14.x aktualisieren
Am besten ist es, bei der unterstützten Nebenversion zu bleiben, auch wenn der Weg dorthin für eine App aus der 1.10-Ära deutlich länger ist, als die Versionsnummer vermuten lässt. Mit Version 1.14 wurde die Unterstützung für jQuery 1.7 bis 1.11, 2.0 bis 2.1 und 3.0 bis 3.5 eingestellt, was in der Praxis bedeutet, dass alles außer der neuesten Version jeder Hauptversion von jQuery nicht mehr unterstützt wird.
Das führt zu einer Falle, die es wert ist, erwähnt zu werden. jQuery UI 1.14.x wird nach wie vor mit jQuery 1.12.4 und 2.2.4 getestet, sodass eine bereits auf einer dieser Versionen basierende Bereitstellung kein jQuery-Upgrade benötigt, um auf 1.14 umzusteigen. Auch in puncto Sicherheit bringt dies keinen Vorteil, da beide Versionen unter 3.5.0 liegen und weiterhin die von KEV aufgeführte CVE enthalten. Es ist durchaus möglich, auf einer unterstützten jQuery-UI-Nebenversion zu landen und gleichzeitig bei der anfälligen jQuery-Version zu bleiben.
Was jQuery betrifft, so wurde im Januar 2026 die Version 4.0.0 veröffentlicht, die Internet Explorer 10 und ältere Versionen nicht mehr unterstützt, IE 11 jedoch vorerst beibehält; jQuery UI 1.14.2 wurde mit dieser Version getestet. Wenn Sie bei der 3.x-Reihe bleiben, ist eine aktuelle Version wie 3.7.1 eine bessere Wahl als die Mindestversion, die zufällig die alten CVEs behebt.
Mit Version 1.14 wird zudem die Unterstützung für Internet Explorer und Edge Legacy vollständig eingestellt und die alte 1.11-API-Kompatibilitätsschicht standardmäßig deaktiviert, obwohl die Einstellung jQuery.uiBackCompat zu true stellt das Verhalten von Version 1.13 wieder her, falls Sie eine sanftere Umstellung benötigen. Wenn Sie direkt von Version 1.10.4 umsteigen, müssen Sie sich außerdem mit den kompatibilitätsbrechenden Änderungen aus den Versionen 1.11 und 1.12 auseinandersetzen, darunter die Änderungen an der Button-API und die überarbeitete Effects-API, wobei diese Kompatibilitätsschicht auf der 1.11-API basiert und nicht auf dem vollständigen Verhalten von Version 1.10. Beides ist gerade für jene Art von internen Unternehmensanwendungen von Bedeutung, in denen jQuery UI weiterhin zum Einsatz kommt. Und der Wartungsaufwand geht auch nach der Umstellung weiter, da 1.14 nur so lange unterstützt wird, bis die nächste Minor-Version erscheint.
Migration weg von jQuery UI
Für die Widgets gibt es moderne Entsprechungen. Native Steuerelemente wie <input type="date"> Die einfacheren Fälle werden abgedeckt, und Komponentenbibliotheken, die für React oder Vue entwickelt wurden, oder standardbasierte Webkomponenten decken den Rest ab. Wenn die Anwendung ohnehin für eine Neugestaltung des Frontends ansteht, ist es die richtige Entscheidung, die Entfernung von jQuery UI in dieses Projekt zu integrieren. Als eigenständige Maßnahme im Zusammenhang mit dem EOL ist dies in der Regel die kostspieligste Option, da sie bedeutet, dass jede interaktive Oberfläche, die derzeit von diesen Widgets gestützt wird, neu entwickelt und getestet werden muss.
Die Risiken einer überstürzten Aktualisierung
Ein jQuery-UI-Upgrade ist eine für den Benutzer sichtbare Änderung, weshalb eine überstürzte Umsetzung hier stärker ins Auge fällt als bei einer Backend-Änderung. Die Migration auf jQuery 3.x kann das Verhalten verändern, auf das sich Code aus den 2010er Jahren stillschweigend verlassen hat. Das Markup der Widgets und das Theming haben sich über die verschiedenen Versionen hinweg verändert, sodass benutzerdefiniertes CSS aus der ThemeRoller-Ära überprüft werden muss. Und die Überprüfung darf sich nicht auf die Durchführung von Unit-Tests beschränken. Sie umfasst visuelle und funktionale Regressionstests auf jeder Seite, die einen Datumswähler, ein Dialogfeld, ein Akkordeon oder eine Autovervollständigung enthält – und zwar in jedem Browser, den Ihre Nutzer noch verwenden.
Teams, die dies in einen Eilsprint pressen, laufen Gefahr, fehlerhafte Layouts und fehlerhaft funktionierende Formulare direkt an die Nutzer auszuliefern und dann die folgenden Wochen mit Support-Tickets und Hotfixes zu verbringen. Die technische Schuld wächst still und leise an, denn die in der Eile hinzugefügten Notlösungen werden zum nächsten Problem, an das sich niemand mehr herwagen will. Upgrades von Bibliotheken, die für die Nutzer sichtbar sind, belohnen Planung und bestrafen Termindruck.
Sichere Legacy-Frontends auch nach Ablauf der Supportfrist mit TuxCare
TuxCare sorgt seit mehr als einem Jahrzehnt dafür, dass Open-Source-Software in der Produktionsumgebung von Tausenden von Unternehmen stets auf dem neuesten Stand bleibt. Dies wird durch einen Patching-Prozess gewährleistet, der automatisierte CVE-Überwachung und Backporting mit Tests und einer obligatorischen Überprüfung durch Experten kombiniert. Für ein „eingefrorenes“ Frontend bedeutet dies, dass der Code, auf den Ihr Unternehmen nach wie vor angewiesen ist, weiterhin Sicherheitsupdates erhält, ohne dass eine Neuprogrammierung des Frontends zu einem Notfall wird.
Entdecken Sie ELS für jQuery oder beginnen Sie mit dem CVE-Tracker, um zu sehen, für welche Sicherheitslücken bereits Korrekturen vorliegen.
