---
id: "CVE-2026-120575"
kind: "vulnerability"
aliases: ["CVE-2026-120575"]
title: "Photo Engine WordPress plugin: stored XSS via hierarchy name parameter"
severity: "medium"
cvss: 6.4
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["package", "photo-engine", "wordpress", "wordpress-plugins"]
not_affected_if: ["plugin-not-installed", "plugin-version-above-6.5.7"]
published_at: "2026-11-03T05:18:34+00:00"
first_seen_at: "2026-11-03T05:48:53+00:00"
updated_at: "2026-11-03T05:49:54+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-120575", "first_seen_at": "2026-11-03T05:48:53+00:00"}]
---

# Photo Engine WordPress plugin: stored XSS via hierarchy name parameter

The Photo Engine (Media Organizer and Lightroom) WordPress plugin up to and including 6.5.7 does not sanitize the 'hierarchy[].name' parameter. An authenticated subscriber can store a script that runs in the browser of any user who opens the injected page.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed Photo Engine plugin version in the WordPress admin plugins list; versions up to and including `6.5.7` are listed as vulnerable.
- Review which accounts have subscriber-level access on the site.

## Fix

- Move the Photo Engine plugin to a version later than `6.5.7`; the sources do not name the fixed version.

## Timeline

- 2026-11-03T05:48:53+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-120575

## From the sources

The Photo Engine (Media Organizer & Lightroom) plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'hierarchy[].name' parameter in all versions up to, and including, 6.5.7 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This is exploitable by Subscribers because the /?wplr-sync-api endpoint authenticates solely via wplr_auth_token usermeta with no capability check, and the current user's token is exposed on every admin page via localized script data due to a commented-out screen-condition guard.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_