Stored-XSS in Embed Google Photos album bedroht WordPress bis 2.2.1

Veröffentlicht am 17.08.2026

Ein einziger präparierter Beitrag kann genügen: Wenn ein Redakteur ihn veröffentlicht und Sie als Administrator ihn öffnen, läuft fremder JavaScript-Code in Ihrem Browser – mit Ihren Rechten. Genau das ermöglicht eine gespeicherte Cross-Site-Scripting-Schwachstelle im WordPress-Plugin Embed Google Photos album. Betroffen sind alle Versionen bis einschließlich 2.2.1. Die Lücke ist unter der Kennung CVE-2026-14290 dokumentiert und mit CVSS 6.8 als „Medium“ eingestuft. Wer das Plugin einsetzt, sollte jetzt handeln – wir zeigen Schritt für Schritt, wie.

Was ist passiert?

Das WordPress-Plugin Embed Google Photos album (technischer Slug: embed-google-photos-album-easily) des Entwicklers pavex dient dazu, Google-Fotoalben in Beiträge und Seiten einzubetten. Genutzt wird dafür ein sogenannter Shortcode – ein kurzer Platzhalter-Befehl in eckigen Klammern, der beim Aufruf der Seite durch echte Inhalte ersetzt wird. Ein typischer Shortcode sieht so aus:

[embed-google-photos-album link="https://…"]

Das Problem: Bis einschließlich Version 2.2.1 hat das Plugin den Wert des Parameters link nicht ausreichend „maskiert“ (auf Fachdeutsch: escaped – also gefährliche Zeichen unschädlich gemacht), bevor es ihn in den HTML-Code der Seite geschrieben hat. Dadurch kann ein angemeldeter Nutzer statt einer harmlosen Google-Fotos-Adresse schädlichen JavaScript-Code in diesem Attribut hinterlegen. Dieser Code wird dauerhaft im Beitrag gespeichert – daher der Name gespeichertes Cross-Site Scripting (Stored XSS).

Sicherheitsdienstleister WPScan hat die Schwachstelle als Stored XSS nach der Kategorie CWE-79 klassifiziert und mit einem CVSS-v3.1-Wert von 6.8 (Medium) bewertet. Der vollständige Vektor lautet AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H.

Der technische Hintergrund – verständlich erklärt

Cross-Site Scripting bedeutet, dass fremder Code in einer eigentlich vertrauenswürdigen Website ausgeführt wird. Bei der „gespeicherten“ Variante wird dieser Code nicht nur einmalig eingeschleust, sondern dauerhaft in der Datenbank abgelegt – etwa als Teil eines Beitrags. Jedes Mal, wenn jemand diesen Beitrag aufruft, wird der Schadcode automatisch im Browser des Besuchers ausgeführt.

Für einen Angriff braucht es hier zunächst ein Benutzerkonto mit mindestens Contributor-Rechten (auf Deutsch: Mitarbeiter – die niedrigste Rolle, die eigene Beiträge verfassen darf). Ein solcher Nutzer legt einen Beitrag mit dem manipulierten Shortcode an. Wird dieser Beitrag später aufgerufen, läuft das eingebettete JavaScript im Browser jedes Betrachters – laut CVE-Beschreibung ausdrücklich auch im Browser von Administratoren.

Warum ist das gefährlich? Läuft Schadcode im Browserkontext eines eingeloggten Administrators, kann er dessen Sitzung missbrauchen, im Namen des Admins Aktionen ausführen oder Daten abgreifen. Der CVSS-Vektor bringt beides auf den Punkt: Der Angriff erfolgt über das Netzwerk und ist technisch wenig komplex, erfordert aber erhöhte Rechte (Contributor oder höher) sowie eine Nutzerinteraktion (jemand muss den Beitrag aufrufen).

Wer ist betroffen?

Betroffen sind ausschließlich WordPress-Websites, die

• das Plugin Embed Google Photos album (Slug embed-google-photos-album-easily) installiert und aktiviert haben,
• eine Version bis einschließlich 2.2.1 einsetzen, und
• über Benutzerkonten mit Contributor-Rechten oder höher verfügen – insbesondere, wenn externe Redakteure, freie Autoren oder mehrere Redaktionskonten existieren.

Laut WordPress.org weist das Plugin über 3.000 aktive Installationen auf (Stand 16.08.2026, gerundete Plattformangabe). Diese Zahl sagt jedoch nichts darüber aus, wie viele Websites tatsächlich verwundbar sind oder ob es zu Vorfällen kam.

Wichtig zur Einordnung: Zum Zeitpunkt der Recherche gab es keinen bestätigten Hinweis auf eine aktive Ausnutzung genau dieser Schwachstelle. Die CVE war nicht im KEV-Katalog der US-Behörde CISA (einer autoritativen Liste tatsächlich in freier Wildbahn ausgenutzter Schwachstellen) enthalten. Die GitHub Advisory Database wies einen EPSS-Wert von 0,29 % aus – eine Modellschätzung der Ausnutzungswahrscheinlichkeit, kein Nachweis. Das Fehlen solcher Belege beweist aber nicht, dass keine Ausnutzung stattfindet.

Ein Detail zur Dringlichkeit: WPScan hat angekündigt, seinen Proof of Concept (einen technischen Nachweis, wie die Lücke ausgenutzt werden kann) am 25. August 2026 zu veröffentlichen. Das Unternehmen begründet dies ausdrücklich damit, Nutzern Zeit zum Update zu geben:

„The PoC will be displayed on August 25, 2026, to give users the time to update.“ (WPScan)

Mit anderen Worten: Ab diesem Datum steigt die Wahrscheinlichkeit, dass Angreifer über den öffentlichen Nachweis verfügen. Wer bis dahin nicht aktualisiert hat, verspielt seinen Vorsprung.

So prüfen Sie, ob Sie betroffen sind

1. Melden Sie sich im WordPress-Backend an und gehen Sie zu Plugins > Installierte Plugins. Suchen Sie nach „Embed Google Photos album“. Achten Sie auf den exakten Slug embed-google-photos-album-easily – es gibt ähnlich benannte Google-Photos-Plugins.
2. Lesen Sie die installierte Versionsnummer ab. Version 2.2.1 oder niedriger ist betroffen. Version 2.2.2 oder höher enthält den vom Hersteller dokumentierten Fix.
3. Haben Sie keinen Dashboard-Zugang, prüfen Sie auf dem Server die Plugin-Metadaten im Verzeichnis wp-content/plugins/embed-google-photos-album-easily/ – oder beauftragen Sie Ihren Hosting- bzw. Wartungspartner mit genau diesem Slug und der Versionsgrenze. Prüfen Sie stets auf einer Kopie oder nach aktuellem Backup.
4. Durchsuchen Sie Beiträge, Seiten, Entwürfe und Revisionen nach dem Shortcode [embed-google-photos-album. Kontrollieren Sie den Parameter link: Er sollte nur erwartete, öffentliche Google-Fotos-Adressen enthalten. Alle unerwarteten Anführungszeichen, Event-Handler oder Script-Fragmente sind Verdachtsfälle. Testen Sie einen vermuteten Schadcode niemals im Live-System.
5. Prüfen Sie unter Benutzer > Alle Benutzer sämtliche Konten mit Contributor-, Autor-, Editor- oder Administratorrechten. Deaktivieren oder entfernen Sie externe Redakteure, ehemalige Mitarbeitende und nicht mehr benötigte Konten.

Das müssen Sie jetzt tun

Die gute Nachricht: Es gibt bereits eine Lösung. Der Hersteller-Changelog auf WordPress.org dokumentiert Version 2.2.2 (Release am 04.08.2026) ausdrücklich als Sicherheitsfix. Der Eintrag beschreibt die Korrektur so:

„security fix: escaped data-link, data-title, class, data-background-color and object data attributes with esc_attr()/esc_url() in get_embed_player_html_code(), fixing a stored XSS via the link shortcode attribute“ (Projekt-Changelog auf WordPress.org)

Ein Hinweis zur Quellenlage: WPScan zeigte zeitgleich noch „No known fix“ an. Diese Angabe ist gegenüber dem aktuellen Hersteller-Changelog veraltet. Für Ihre Entscheidung ist der Changelog des Herstellers maßgeblich – der Fix existiert.

1. Backup erstellen. Sichern Sie vor jeder Änderung Dateien und Datenbank und testen Sie, dass das Backup wiederherstellbar ist.
2. Plugin aktualisieren. Bringen Sie das Plugin auf mindestens Version 2.2.2 und prüfen Sie anschließend, ob die betroffenen Seiten weiterhin korrekt funktionieren.
3. Kein zeitnahes Update möglich? Deaktivieren oder entfernen Sie das Plugin vorübergehend, sofern die Website-Funktion das zulässt.
4. Inhalte untersuchen. Prüfen Sie vor und nach dem Update alle Beiträge mit dem Plugin-Shortcode. Löschen Sie verdächtige Beiträge nicht einfach, sondern sichern Sie zuerst eine verwertbare Kopie samt Zeitstempel und Autoreninformationen. Entfernen Sie danach den schädlichen Inhalt oder erstellen Sie den Beitrag mit einem sauberen Shortcode neu.
5. Rollen aufräumen. Reduzieren Sie Contributor- und höhere Rollen nach dem Least-Privilege-Prinzip (jeder erhält nur so viele Rechte wie unbedingt nötig). Entfernen Sie ungenutzte Konten und erzwingen Sie starke, individuelle Passwörter sowie Mehrfaktor-Authentisierung für Redaktions- und Administrationskonten.
6. Protokolle prüfen. Kontrollieren Sie Zugriffs- und Aktivitätsprotokolle, die Publikationshistorie und Administratoraktivitäten im relevanten Zeitraum. Bei begründetem Verdacht auf ausgeführten Schadcode: Sitzungen beenden und Zugangsdaten risikobasiert zurücksetzen. Im Zweifel eine qualifizierte Incident-Response-Prüfung veranlassen.
7. Dauerhaft absichern. Überwachen Sie Plugin-, Kern- und Server-Updates kontinuierlich, entfernen Sie nicht mehr benötigte Erweiterungen und etablieren Sie einen dokumentierten Patch- sowie Backup-/Recovery-Prozess.

Diese Grundmaßnahmen – Aktualität, Zugriffsbeschränkung, Backups und Monitoring – empfiehlt auch die offizielle WordPress-Sicherheitsdokumentation.

Einordnung und DSGVO-Relevanz

Dies ist keine Rechtsberatung. Die bloße Existenz einer XSS-Lücke ist nicht automatisch eine meldepflichtige Datenschutzverletzung. Relevant wird die DSGVO erst, wenn der Vorfall zu einer unbefugten Offenlegung, einem unbefugten Zugriff, zum Verlust, zur Veränderung oder Zerstörung personenbezogener Daten führt – bei einem XSS-Angriff beispielsweise durch Zugriff auf Sitzungsdaten oder Kontaktformular-Einträge.

Sollte das der Fall sein, muss der Verantwortliche eine dokumentierte Risikobewertung durchführen: Welche Datenarten und Personengruppen sind betroffen, welche Folgen sind wahrscheinlich, welche Abhilfemaßnahmen wurden getroffen? Ergibt sich voraussichtlich ein Risiko für die Rechte und Freiheiten natürlicher Personen, greift Art. 33 DSGVO: Meldung unverzüglich und möglichst binnen 72 Stunden nach Kenntnisnahme an die zuständige Datenschutzaufsicht. Bei voraussichtlich hohem Risiko müssen nach Art. 34 DSGVO zusätzlich die Betroffenen unverzüglich benachrichtigt werden.

Verstöße gegen Pflichten aus den Art. 32 bis 34 DSGVO ordnet Art. 83 Abs. 4 DSGVO grundsätzlich der Bußgeldstufe von bis zu 10 Mio. EUR oder 2 % des weltweiten Vorjahresumsatzes zu – je nachdem, welcher Betrag höher ist. Das ist ein Rahmen, kein automatisch fälliges Bußgeld; die konkrete Bewertung hängt vom Einzelfall ab.

Kein Einzelfall in diesem Plugin

Bereits zuvor war das Plugin von einer – technisch anderen – Schwachstelle betroffen: CVE-2024-32775 beschreibt eine authentifizierte SSRF-Lücke (Server-Side Request Forgery, bei der ein Server zu unerwünschten Anfragen verleitet wird) bis einschließlich Version 2.2.0, ebenfalls ab Contributor-Rolle, CVSS 6.4 (Medium), behoben in 2.2.1 und veröffentlicht am 22.04.2024. Das zeigt: Wer dieses Plugin einsetzt, sollte Updates besonders aufmerksam verfolgen.

Zum breiteren Lagebild: Das BSI meldet für seinen Berichtszeitraum vom 01.07.2024 bis 30.06.2025 eine um 38 % gestiegene Exploitation gegenüber dem vorangehenden Zeitraum sowie 950 angezeigte Ransomware-Angriffe. Das sind allgemeine Kennzahlen zur Bedrohungslage – keine Statistik zu diesem Plugin, zu XSS oder zu CVE-2026-14290.

Fazit

CVE-2026-14290 ist mit CVSS 6.8 (Medium) keine kritische Lücke – aber unterschätzen sollte man sie nicht. Die erforderlichen Contributor-Rechte und die nötige Nutzerinteraktion dämpfen das Risiko, doch wenn ein präparierter Beitrag von einem Administrator geöffnet wird, kann fremder Code in dessen privilegiertem Browserkontext laufen. Das kann schwer wiegen.

Die Handlungsanweisung ist klar und die Lösung liegt vor: Aktualisieren Sie das Plugin nach einem getesteten Backup auf mindestens Version 2.2.2, prüfen Sie Ihre Beiträge auf verdächtige Shortcodes und räumen Sie Ihre Benutzerrollen auf. Besonders drängt die Zeit, weil WPScan seinen technischen Nachweis für den 25. August 2026 angekündigt hat – ab dann steht Angreifern eine detaillierte Anleitung zur Verfügung. Wer bis dahin gehandelt hat, ist auf der sicheren Seite.