Stored XSS in Embed Google Photos album threatens WordPress up to 2.2.1

Published on 17 August 2026

A single crafted post can be enough: if an editor publishes it and you, as an administrator, open it, someone else's JavaScript code runs in your browser – with your privileges. That's exactly what a stored cross-site scripting vulnerability in the WordPress plugin Embed Google Photos album makes possible. All versions up to and including 2.2.1 are affected. The flaw is documented under the identifier CVE-2026-14290 and rated "Medium" with a CVSS score of 6.8. Anyone using the plugin should act now – we'll show you step by step how.

What happened?

The WordPress plugin Embed Google Photos album (technical slug: embed-google-photos-album-easily) by developer pavex is used to embed Google photo albums into posts and pages. It does this via a so-called shortcode – a short placeholder command in square brackets that gets replaced with actual content when the page is loaded. A typical shortcode looks like this:

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

The problem: up to and including version 2.2.1, the plugin did not adequately "escape" the value of the link parameter (in technical terms: escaping – rendering dangerous characters harmless) before writing it into the page's HTML code. As a result, a logged-in user can place malicious JavaScript code in this attribute instead of a harmless Google Photos address. This code is stored permanently in the post – hence the name stored cross-site scripting (Stored XSS).

Security service provider WPScan classified the vulnerability as Stored XSS under category CWE-79 and assessed it with a CVSS v3.1 score of 6.8 (Medium). The full vector reads AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H.

The technical background – explained clearly

Cross-site scripting means that foreign code is executed within an otherwise trustworthy website. In the "stored" variant, this code isn't just injected once but is stored permanently in the database – for instance as part of a post. Every time someone opens this post, the malicious code is automatically executed in the visitor's browser.

For an attack, you first need a user account with at least Contributor privileges (the lowest role permitted to write its own posts). Such a user creates a post with the manipulated shortcode. When this post is later opened, the embedded JavaScript runs in every viewer's browser – according to the CVE description, explicitly including administrators' browsers.

Why is this dangerous? If malicious code runs in the browser context of a logged-in administrator, it can hijack their session, carry out actions in the admin's name or harvest data. The CVSS vector sums both up: the attack is carried out over the network and is technically not very complex, but requires elevated privileges (Contributor or higher) as well as user interaction (someone has to open the post).

Who is affected?

Only WordPress websites are affected that

• have the Embed Google Photos album plugin (slug embed-google-photos-album-easily) installed and activated,
• use a version up to and including 2.2.1, and
• have user accounts with Contributor privileges or higher – particularly if external editors, freelance authors or multiple editorial accounts exist.

According to WordPress.org, the plugin has over 3,000 active installations (as of 16/08/2026, rounded platform figure). This number, however, says nothing about how many websites are actually vulnerable or whether any incidents have occurred.

Important for context: at the time of research, there was no confirmed indication of active exploitation of this specific vulnerability. The CVE was not included in the KEV catalogue of the US agency CISA (an authoritative list of vulnerabilities actually exploited in the wild). The GitHub Advisory Database indicated an EPSS score of 0.29% – a model estimate of exploitation probability, not proof. However, the absence of such evidence does not prove that no exploitation is taking place.

One detail regarding urgency: WPScan has announced that it will publish its proof of concept (a technical demonstration of how the flaw can be exploited) on 25 August 2026. The company explicitly justifies this by giving users time to update:

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

In other words: from this date onwards, the likelihood increases that attackers will have access to the public demonstration. Anyone who hasn't updated by then throws away their head start.

How to check whether you are affected

1. Log in to the WordPress backend and go to Plugins > Installed Plugins. Search for "Embed Google Photos album". Pay attention to the exact slug embed-google-photos-album-easily – there are similarly named Google Photos plugins.
2. Read off the installed version number. Version 2.2.1 or lower is affected. Version 2.2.2 or higher contains the fix documented by the vendor.
3. If you don't have dashboard access, check the plugin metadata on the server in the directory wp-content/plugins/embed-google-photos-album-easily/ – or task your hosting or maintenance partner with exactly this slug and version threshold. Always check on a copy or after a current backup.
4. Search through posts, pages, drafts and revisions for the shortcode [embed-google-photos-album. Check the link parameter: it should only contain expected, public Google Photos addresses. Any unexpected quotation marks, event handlers or script fragments are suspicious cases. Never test suspected malicious code on the live system.
5. Under Users > All Users, check all accounts with Contributor, Author, Editor or Administrator privileges. Deactivate or remove external editors, former staff and accounts no longer needed.

What you need to do now

The good news: a solution already exists. The vendor changelog on WordPress.org explicitly documents version 2.2.2 (released on 04/08/2026) as a security fix. The entry describes the correction as follows:

"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" (project changelog on WordPress.org)

A note on the sources: at the same time, WPScan still displayed "No known fix". This information is outdated compared to the current vendor changelog. For your decision, the vendor's changelog is authoritative – the fix exists.

1. Create a backup. Before making any changes, back up files and the database and test that the backup can be restored.
2. Update the plugin. Bring the plugin to at least version 2.2.2 and then check whether the affected pages still function correctly.
3. No prompt update possible? Temporarily deactivate or remove the plugin, provided the website's functionality allows it.
4. Examine the content. Before and after the update, check all posts with the plugin shortcode. Don't simply delete suspicious posts – first secure a usable copy including timestamps and author information. Then remove the malicious content or recreate the post with a clean shortcode.
5. Clean up roles. Reduce Contributor and higher roles according to the least-privilege principle (everyone gets only as many privileges as strictly necessary). Remove unused accounts and enforce strong, individual passwords as well as multi-factor authentication for editorial and administration accounts.
6. Check the logs. Review access and activity logs, the publication history and administrator activities within the relevant period. If there is well-founded suspicion of executed malicious code: end sessions and reset credentials on a risk-based basis. When in doubt, commission a qualified incident-response review.
7. Secure it permanently. Continuously monitor plugin, core and server updates, remove extensions no longer needed and establish a documented patch as well as backup/recovery process.

These basic measures – staying up to date, restricting access, backups and monitoring – are also recommended by the official WordPress security documentation.

Assessment and GDPR relevance

This is not legal advice. The mere existence of an XSS flaw is not automatically a reportable data breach. The GDPR only becomes relevant once the incident leads to an unauthorised disclosure, unauthorised access, loss, alteration or destruction of personal data – in the case of an XSS attack, for example through access to session data or contact-form entries.

Should that be the case, the controller must carry out a documented risk assessment: which types of data and groups of people are affected, which consequences are likely, and which remedial measures have been taken? If a risk to the rights and freedoms of natural persons is likely, Art. 33 GDPR applies: notification to the competent data protection supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. In the case of a likely high risk, the affected individuals must additionally be notified without undue delay under Art. 34 GDPR.

Violations of obligations under Art. 32 to 34 GDPR are, in principle, assigned by Art. 83(4) GDPR to the fine tier of up to EUR 10 million or 2% of the worldwide annual turnover of the preceding year – whichever amount is higher. That is a framework, not an automatically levied fine; the specific assessment depends on the individual case.

Not an isolated case for this plugin

The plugin was already affected earlier by a – technically different – vulnerability: CVE-2024-32775 describes an authenticated SSRF flaw (Server-Side Request Forgery, in which a server is tricked into making unwanted requests) up to and including version 2.2.0, likewise from the Contributor role, CVSS 6.4 (Medium), fixed in 2.2.1 and published on 22/04/2024. This shows: anyone using this plugin should follow updates especially attentively.

For the broader picture: the BSI reports, for its reporting period from 01/07/2024 to 30/06/2025, an exploitation figure up by 38% compared to the preceding period, as well as 950 reported ransomware attacks. These are general figures on the threat situation – not statistics on this plugin, on XSS or on CVE-2026-14290.

Conclusion

At CVS 6.8 (Medium), CVE-2026-14290 is not a critical flaw – but you shouldn't underestimate it. The required Contributor privileges and the necessary user interaction dampen the risk, yet if a crafted post is opened by an administrator, someone else's code can run in their privileged browser context. That can carry serious weight.

The course of action is clear and the solution is available: after a tested backup, update the plugin to at least version 2.2.2, check your posts for suspicious shortcodes and clean up your user roles. Time is particularly pressing because WPScan has announced its technical proof of concept for 25 August 2026 – from then on, attackers will have detailed instructions available. Anyone who has acted by then is on the safe side.