jQuery-Sicherheitslücken: CVEs, Sicherheitsrisiken und Lösungen

Wichtigste Erkenntnisse

• Die meisten Risiken im Zusammenhang mit jQuery gehen von alten Versionen aus, die noch in der Produktion im Einsatz sind, und nicht von neu entdeckten Schwachstellen.
• XSS dominiert die Liste mit den Schwachstellen CVE-2020-11022, CVE-2020-11023 und CVE-2015-9251, dicht gefolgt von „Prototype Pollution“.
• jQuery 1.x und 2.x werden nicht mehr unterstützt, für 3.x werden nur noch kritische Fehlerbehebungen bereitgestellt, und 4.x ist der aktuelle Zweig.
• Wenn ein Upgrade noch nicht realistisch ist, verhindert die vom Hersteller unterstützte Patch-Bereitstellung, dass eine alte Version zu einem Risiko wird.

Ein Sicherheitsscanner meldet jQuery 3.4.1 in einer App, die seit drei Jahren niemand mehr angerührt hat, und plötzlich hat man eine CVE, von der man gar nicht wusste, dass man sie hat. Das ist die ganze Geschichte der jQuery-Sicherheitslücken im Jahr 2026. Die Schwachstellen sind alt, die Patches gibt es bereits, und das Risiko lauert in einer Version, von der niemand mehr wusste, dass sie noch im Einsatz war.

Dieser Leitfaden gibt einen Überblick über die konkreten CVEs, welche Möglichkeiten sie einem Angreifer eröffnen, warum sie bei Audits immer wieder übersehen werden und wie man sie beheben kann – unabhängig davon, ob ein Upgrade möglich ist oder nicht.

Übersicht über jQuery-Sicherheitslücken

jQuery-Sicherheitslücken sind Schwachstellen in bestimmten Bibliotheksversionen, die es einem Angreifer ermöglichen können, nicht vertrauenswürdiges JavaScript im Browser auszuführen, Prototypen gemeinsam genutzter Objekte zu verfälschen oder eine Seite zum Absturz zu bringen. Sie werden als CVEserfasst, wie jede andere gemeldete Schwachstelle auch.

Das Problem dabei ist, dass jQuery so gut wie nie aktiv von einem Team gepflegt wird. Es wird gebündelt, auf eine funktionierende Version festgelegt und dann vergessen. In dieser Lücke zwischen „Es gibt einen Patch“ und „Der Patch wurde angewendet“ liegt das eigentliche Risiko.

Arten von jQuery-Sicherheitslücken

Die Schwachstellen lassen sich in den folgenden fünf CVEs in drei Kategorien einteilen. XSS dominiert, obwohl auch Prototyp-Verunreinigung und Denial-of-Service-Angriffe die Scan-Ergebnisse vervollständigen.

 Cross-Site-Scripting (XSS)

XSS ist das größte Problem bei jQuery. CVE-2020-11022 bezieht sich auf allgemein nicht vertrauenswürdigen HTML-Code, der an die DOM-Manipulationsmethoden von jQuery übergeben wird, und lässt sich darauf zurückführen, wie jQuery.htmlPrefilter Markup normalisiert. CVE-2020-11023 betrifft HTML, das „option“-Elemente enthält. Zusammen betreffen diese Schwachstellen alle Versionen von 1.0.3 bis einschließlich aller Versionen vor 3.5.0, wozu auch jQuery 3.4.1 gehört, das in der Praxis nach wie vor sehr verbreitet ist. Unter den entsprechenden Bedingungen kann von einem Angreifer kontrolliertes Markup, das an eine dieser Methoden übergeben wird, dazu führen, dass Skriptcode auf der Seite ausgeführt wird – selbst nachdem dieser bereinigt wurde. Bei allen Versionen älter als 3.0.0 besteht zudem die Schwachstelle CVE-2015-9251, das domänenübergreifende Ajax-XSS, wobei 1.12.2 die einzige gepatchte Ausnahme in diesem Bereich ist.

Prototyp-Verschmutzung

CVE-2019-11358 betrifft Versionen von 1.1.4 bis einschließlich 3.4.0. Ein speziell gestaltetes Objekt, das über jQuery.extend(true, {}, …) , kann in Object.prototypeschreiben, sodass vom Angreifer kontrollierte Eigenschaften von anderen Objekten geerbt werden, die auf diese Prototyp-Kette angewiesen sind. Für sich genommen handelt es sich dabei um eine einfache Manipulationsmöglichkeit. Je nachdem, wie die manipulierten Eigenschaften weiter unten verwendet werden, kann dies zu XSS oder anderen anwendungsspezifischen Auswirkungen führen. Die Schwachstelle trat besonders deutlich in Drupal und Backdrop CMS zutage, was mit ein Grund dafür ist, dass man ihr auch weit außerhalb von handgeschriebenem jQuery-Code begegnet.

Denial of Service (DoS)

Die leisere Kategorie. CVE-2016-10707 betrifft ausschließlich jQuery 3.0.0-rc.1. Dieser Release-Kandidat behandelte Attributnamen mit gemischter Groß- und Kleinschreibung falsch, sodass der betroffene Getter in eine unendliche Rekursion geriet und den Aufrufstapel erschöpfte. Eine andere Art von Auswirkung als bei den beiden XSS-Schwachstellen, und das Erreichen dieses Codepfads führt dennoch zum Absturz der Seite, auf der der Code ausgeführt wird. In der endgültigen Version 3.0.0 wurde das Problem behoben.

Wusstest du schon: Der OSSRA-Bericht 2026 (Black Duck) stellte fest, dass vier jQuery-CVEs zu den zehn häufigsten Schwachstellen gehörten und zusammen 25 % bis 28 % der geprüften Codebasen betrafen. Jahrelange Sicherheitslücken, für die schon lange Patches verfügbar sind, tauchen immer noch in mehr als einem Viertel der kommerziellen Software auf.

Risiken bei der Nichtbehebung von jQuery-Sicherheitslücken

Eine jQuery-CVE ist kein abstraktes Risiko. Die Bibliothek ist im Frontend eines Großteils des Internets im Einsatz, und je nachdem, welche CVE vorliegt und wie Ihre Anwendung diese nutzt, reichen die Folgen von Code, der in den Browsern Ihrer Nutzer ausgeführt wird, bis hin zu einem Eintrag in einem Auditbericht oder einer Seite, die nicht mehr reagiert.

Kontoübernahme und Sitzungsdiebstahl

XSS ist die Hauptfolge der am häufigsten auftretenden jQuery-CVE-Schwachstellen, und XSS bedeutet, dass ein Angreifer JavaScript im Browser Ihres Benutzers ausführen kann. In der Praxis bedeutet dies das Abfangen von Anmeldedaten in einem Anmeldeformular, den Diebstahl aller Sitzungsdaten, auf die JavaScript zugreifen kann, oder das heimliche Ausführen von Aktionen als der angemeldete Benutzer.

HttpOnly-Cookies machen das Cookie selbst unzugänglich, was zwar hilfreich ist, einen Angreifer jedoch nicht daran hindert, innerhalb dieser Sitzung aktiv zu werden. Bei einer kleineren SaaS-Anwendung, bei der das Admin-Dashboard noch mit jQuery 3.4.1 läuft, reicht bereits eine einzige gespeicherte Nutzlast aus, um Zugriff auf die Sitzung eines Administrators zu erlangen.

Versäumnisse bei Compliance und Audit

Bekannte Schwachstellen in Produktionsabhängigkeiten tauchen bei PCI-DSS-Prüfungen, Schwachstellenscans und Sicherheitsüberprüfungen in Unternehmen ständig auf, und die Ausrede „Es handelt sich doch nur um die Frontend-Bibliothek“ reicht nicht aus, um den Bericht zu bereinigen. Sie müssen dennoch nachweisen, dass die Komponente gepatcht oder auf andere Weise behoben wurde. Bei den zugrunde liegenden CVEs handelt es sich hier um echte Schwachstellen und nicht um falsche Positive, auch wenn ein einzelner Scan-Befund noch anhand Ihres tatsächlichen Codes und des aktuellen Patching-Status überprüft werden muss. Es lohnt sich, diese Unterscheidung parat zu haben, bevor ein Prüfer danach fragt.

Ein größerer Explosionsradius, als man denkt

jQuery kommt so gut wie nie als Einzelinstanz vor. Themes, Plugins und CMS-Kerne binden es alle ein, sodass eine EOL-Version auf Dutzenden von Seiten oder in Dutzenden von Teilsystemen vorkommen kann. Diese Verbreitung im Blick zu behalten, erfordert gezielten Aufwand, und das Lesen von korrekte Auswertung der CVSS-Bewertung ist entscheidend, sobald man damit beginnt, die Warteschlange nach Prioritäten zu ordnen.

Achtung: Viele Schwachstellen- und Compliance-Scanner leiten Sicherheitsrisiken aus der von ihnen erkannten jQuery-Versionszeichenfolge ab. Ein zurückportierter Fix, bei dem die Upstream-Versionsnummer beibehalten wird, kann dennoch einen Befund auslösen. Dokumentieren Sie den Patch daher ausdrücklich.

Wie entstehen jQuery-Sicherheitslücken?

Drei Ursachen sind für fast alle Probleme verantwortlich: die Verwendung einer veralteten Version, die Übernahme von jQuery, das man nie selbst ausgewählt hat, und die Eingabe von nicht vertrauenswürdigen Daten.

Veraltete jQuery-Versionen

Dies ist die Hauptursache für die meisten Teams. jQuery 1.x und 2.x hatten am 20. Mai 2016 ihre letzten Veröffentlichungen, 1.12.4 und 2.2.4, und seitdem gab es keine weiteren Upstream-Veröffentlichungen mehr. Der 3.x-Zweig erhält nun nur noch kritische Sicherheitspatches und Fehlerbehebungen, wobei 3.7.1 vom August 2023 nach wie vor die aktuellste Version ist, und das Projekt rät allen, auf 4.x umzusteigen.

Sobald eine Version nicht mehr vom Upstream-Entwickler unterstützt wird, werden neu entdeckte Fehler darin vom jQuery-Projekt nicht mehr behoben, es sei denn, Sie führen ein Upgrade durch oder übernehmen Patches aus einer anderen unterstützten Quelle. Das ist genauso wie bei jeder anderen Software, deren Lebenszyklus abgelaufen ist. Die Upstream-Entwickler kümmern sich nicht mehr darum, und Ihre Produktionssysteme laufen einfach weiter.

Vererbtes und transitives jQuery

Man geht selten absichtlich ein Risiko ein. WordPress, Drupal und eine lange Liste von Themes und UI-Plugins binden jQuery automatisch ein. Es landet in Ihrem Stack, ohne dass jemand darüber entscheidet – in der Regel in der Version, mit der der Plugin-Autor getestet hat. Um diese Kopien zu finden, muss man das System durchsuchen und kann sich nicht einfach nur die eigene „package.json“. Das gleiche Problem mit versteckten Abhängigkeiten, das auch bei der PHP-Sicherheitslücken und in vielen anderen Ökosystemen auftritt.

Unsichere DOM-Muster

Selbst in einer aktuellen Version kann nicht vertrauenswürdiger HTML-Code über .html() oder .append() einzufügen, kann immer noch zu XSS auf Anwendungsebene führen. Die Bibliothek macht genau das, was du verlangt hast. Der Fehler liegt in der Eingabe, der du vertraut hast.

Auch das tiefgreifende Zusammenführen nicht vertrauenswürdiger Objekte verdient die gleiche sorgfältige Prüfung, obwohl eine gepatchte Version das Problem CVE-2019-11358 selbst behebt, sodass das Risiko bei $.extend liegt eher in dem, was man ihr übergibt, als in der Funktion selbst. Durch das Patchen der Version wird die Schwachstelle auf Seiten der Bibliothek behoben. Bei der Code-Überprüfung muss dieses Muster jedoch weiterhin erkannt werden.

Realitätscheck: „Wir nutzen jQuery 3, also sind wir auf der sicheren Seite“ ist die häufigste falsche Annahme. CVE-2020-11022 und CVE-2020-11023 wurden erst ab Version 3.5.0 behoben, sodass 3.4.1 und alle früheren 3.x-Versionen weiterhin anfällig sind.

So beheben Sie jQuery-Sicherheitslücken

Es gibt eine klare Reihenfolge der Maßnahmen: Führen Sie ein Upgrade durch, wenn möglich; besorgen Sie sich vom Hersteller bereitgestellte Patches, wenn dies nicht möglich ist; und richten Sie in jedem Fall zusätzliche Schutzmaßnahmen ein.

1. Aktualisieren Sie auf eine unterstützte Version.

Die sauberste Lösung. Ein Upgrade auf jQuery 3.5.0 oder höher schließt die XSS-Sicherheitslücke, und ein Upgrade auf die neueste 4.x-Version bringt Sie auf den aktuellen Zweig mit vollständiger Upstream-Unterstützung. Der Haken dabei sind kompatibilitätsbrechende Änderungen, da ab Version 4.0 veraltete APIs wie jQuery.trim und jQuery.isArray entfernt wurden.

Beginnen Sie mit einer Bestandsaufnahme:

npm ls jquery

Wenn der Code-Baum sauber ist, führen Sie ein Upgrade durch und nutzen Sie die Entwicklungsversion des jQuery-Migrate-Plugins, damit Kompatibilitätswarnungen bereits vor der Produktionsumgebung und nicht erst danach auftreten. Sollte eine ältere Anwendung durch das Upgrade nicht mehr funktionieren, ist die unten aufgeführte Option zwei der realistischere Weg.

2. Vom Hersteller unterstützte Patches, wenn ein Upgrade nicht möglich ist

Viele Teams stecken wirklich in der Klemme. Ein veraltetes Unternehmens-Dashboard, das an jQuery 1.x gebunden ist, oder ein CMS-Theme, das bei einem größeren Versionssprung versagt, lässt sich nicht kurzfristig auf 4.x umstellen. Genau darin liegt die Lücke , den der „Endless Lifecycle Support“ (ELS) von TuxCare für jQuery schließt.

ELS portiert CVE-Korrekturen in die von Ihnen bereits verwendete Version zurück und stellt sie über npm bereit. Die Abdeckung erstreckt sich auf zehn Versionen, von jQuery 1.8.2 bis 3.4.1, deren Lebensdauer seitens des Upstream-Entwicklers bereits seit Langem abgelaufen ist. Der praktische Vorteil besteht darin, dass die Sicherheit gewährleistet bleibt, ohne dass eine sofortige Migration und Neuprogrammierung des Frontends erforderlich ist. So kann eine Anwendung mit tiefgreifenden jQuery-Abhängigkeiten weiterhin mit Patches versorgt werden, während das Team die Umstellung sorgfältig plant.

Diese Abdeckung erstreckt sich zudem über jQuery hinaus und umfasst die Ökosysteme von Java, JavaScript, Python, PHP und .NET.

3. Mehrschichtige Verteidigung

Das Schließen von Sicherheitslücken ist die Lösung. Diese Schichten mindern den Schaden, falls doch einmal etwas durchrutscht. Behandeln Sie von Angreifern kontrolliertes HTML als unsicher, bevorzugen Sie nach Möglichkeit textsichere DOM-APIs und greifen Sie auf einen bewährten HTML-Sanitizer zurück, wenn die Anwendung wirklich nicht vertrauenswürdiges Markup rendern muss. Legen Sie darüber hinaus eine strenge Content Security Policy fest. Und erstellen Sie eine SBOM , damit jede jQuery-Kopie, die in Ihren Abhängigkeitsmetadaten erfasst ist, dokumentiert wird.

Profi-Tipp: Ein Grep nach Versionszeichenfolgen übersieht minimierte und gebündelte Kopien, und eine aus Ihren Manifesten und Lockfiles erstellte SBOM übersieht diejenigen, die von vornherein keine npm-Metadaten enthielten. Führen Sie daher auch einen inhaltsbasierten Scanner wie retire.js über Ihre gebauten Assets aus, da dieser speziell dafür entwickelt wurde, Bibliotheken zu erkennen, die heruntergeladen und committet, aber nicht installiert wurden.

Minimieren Sie geschäftliche Risiken bei EOL-jQuery

Das Problem mit jQuery ist nicht, dass die Bibliothek unverständlich ist. Das Problem ist, dass sie überall zu finden ist, meist veraltet ist und kaum jemand sie aktiv im Auge behält. So landet eine CVE, die irgendwann zwischen 2015 und 2020 veröffentlicht wurde, schließlich in Ihrem nächsten Audit. Laut W3Techs wird jQuery auf etwa 66 % aller Websites, und etwas mehr als jede fünfte dieser Seiten läuft noch auf einem 1.x- oder 2.x-Zweig, dessen letzte Upstream-Version aus dem Jahr 2016 stammt.

Finden Sie alle Vorkommen. Aktualisieren Sie, was Sie können. Für das, was Sie nicht aktualisieren können, sollten Sie eine vom Anbieter unterstützte Lösung nutzen, anstatt es ungeschützt zu lassen. Wenn Sie an einer EOL-Version festhängen, sorgt der „Endless Lifecycle Support“ von TuxCare für jQuery sorgt dafür, dass sie während Ihrer Migrationsplanung weiterhin gepatcht wird, ohne dass Sie eine Neuprogrammierung vornehmen müssen, bevor Sie dazu bereit sind.

Zusammenfassung

Artikel Name

jQuery-Sicherheitslücken: CVEs, Sicherheitsrisiken und Lösungen

Beschreibung

Erfahren Sie mehr über häufige jQuery-Sicherheitslücken, darunter CVEs und Sicherheitsrisiken im Jahr 2026, und wie Sie Ihre Webanwendungen vor diesen Bedrohungen schützen können.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers