Summary (short)

• Vulnerability: Stored Cross‑Site Scripting (XSS) via admin_post_wpgmza_save_settings (missing authorization).
• Affected versions: WP Go Maps <= 10.0.05
• Patched in: 10.0.06
• CVE: CVE‑2026‑4268
• CVSS (reported): 6.5 (Medium)
• Required attacker privilege to initiate: Subscriber (authenticated, low‑privilege WordPress role)
• User interaction: Required (an admin or other privileged user must view or interact with a page that renders the stored payload)
• Immediate action: Update to 10.0.06 or later; if you cannot update immediately, apply short‑term mitigations and virtual patching via a WAF or server rules.

What happened — vulnerability in plain English

A settings save handler registered by WP Go Maps exposed an endpoint that allowed low‑privileged authenticated users (Subscriber role and above) to submit data saved in plugin settings and later rendered in admin pages without sufficient sanitization and/or authorization checks. Because the endpoint lacks required authorization checks, an authenticated subscriber can submit specially crafted input that includes JavaScript or HTML payloads. When a privileged user (for example, an Administrator) later views the affected admin screen, the stored malicious script runs in the context of that user’s browser.

This is stored XSS: data is stored on the server and then served back to another user, resulting in script execution in an admin’s browser. An attacker can leverage this for account takeover, privilege escalation, persistent defacement, session theft, or to install further backdoors.

Why this is serious for WordPress sites

• Only a Subscriber account is needed to initiate the exploit. Many sites allow registrations for comments, memberships, newsletters, etc.
• Payloads are stored in plugin settings and executed in admin pages — admin browsers often have active bearer cookies and high privileges, making this particularly dangerous.
• Attackers can pivot from a stored XSS in admin UI to create admin users, inject content, or perform privileged actions via authenticated requests from the admin’s browser.
• Because the vulnerability affects plugin settings rather than visible posts, it can go unnoticed until significant damage occurs.

Technical details (high level, safe)

• Vulnerability location: admin_post_wpgmza_save_settings action — a POST handler used to save plugin settings.
• Root cause: missing authorization checks (insufficient capability checks and nonce verification) combined with improper input sanitization/escaping when rendering saved settings.
• Attack vector: an authenticated user (Subscriber+) submits a POST to admin-post.php?action=wpgmza_save_settings with malicious payload fields. The payload is written to the database and later rendered in admin UI without proper escaping.
• Result: stored XSS executed in the browser of a user who views or interacts with the affected admin page.

Note: exploit code or step‑by‑step proofs of concept are intentionally omitted to avoid aiding attackers. The focus here is on detection, mitigation, and secure coding fixes.

Affected versions and patch status

• Affected: WP Go Maps versions <= 10.0.05
• Fixed in: 10.0.06 — site owners should update immediately

If you cannot update right now (compatibility or testing reasons), apply virtual patching and the mitigations below until you can update.

How attackers could abuse this (attack scenarios)

1. Registration abuse: Open registration or automated account creation can be abused to submit persistent payloads into plugin settings.
2. Social engineering: An attacker submits a payload and then entices an administrator to visit the affected admin page, triggering script execution.
3. Multi‑stage compromise: Executed scripts can perform privileged AJAX calls, exfiltrate cookies, or create admin accounts via the admin’s authenticated session.
4. Mass exploitation: Automated scanners can find vulnerable installs and attempt large‑scale submissions, followed by attempts to get admins to load affected pages.

Indicators of Compromise (IoCs) — what to look for now

Search both the database and logs for suspicious signs.

1. HTTP access logs

Look for POST requests to admin‑post.php with action=wpgmza_save_settings. Example:

grep -E "POST .*admin-post.php.*action=wpgmza_save_settings" /var/log/apache2/access.log

Check for unexpected IPs, rapid sequences of similar requests, or requests from accounts you do not recognise.

2. Database searches

The plugin stores settings in wp_options (or similar). Search option values for