Cross Site Scripting Threat in Payment Plugin(CVE20260751)

Cross Site Scripting (XSS) in WordPress Payment Page Plugin
Plugin Name WordPress Payment Page Plugin
Type of Vulnerability Cross-Site Scripting
CVE Number CVE-2026-0751
Urgency Medium
CVE Publish Date 2026-02-13
Source URL CVE-2026-0751

CVE-2026-0751: Deep Dive — Authenticated (Author) Stored XSS in Payment Page Plugin

Update (13 Feb 2026): A stored Cross‑Site Scripting (XSS) vulnerability affecting the Payment Page (Payment Form for Stripe) WordPress plugin (versions ≤ 1.4.6) has been disclosed. The flaw permits an authenticated user with Author privileges to save content via the parameter pricing_plan_select_text_font_family that is later rendered to visitors without sufficient sanitization or escaping. Below is a technical analysis, impact assessment, detection guidance, and practical mitigations written in the concise, pragmatic tone I use when advising Hong Kong site owners and security teams.


Executive summary

  • Software: Payment Page (Payment Form for Stripe) WordPress plugin
  • Vulnerable versions: ≤ 1.4.6
  • Vulnerability: Stored Cross‑Site Scripting (XSS) via pricing_plan_select_text_font_family
  • CVE: CVE‑2026‑0751
  • Required privilege: Author (authenticated)
  • CVSS (reported): ~5.9 (Medium) — requires authenticated Author and some user interaction
  • Reported by: Athiwat Tiprasaharn (Jitlada) — published 13 Feb 2026

Summary: an authenticated Author can supply a malicious value intended for a font parameter that the plugin stores and later outputs to site visitors without proper validation/escaping. The stored nature means many visitors can be affected; consequences range from UI tampering and phishing to session theft depending on the site context.

Why this matters: stored XSS in a payment UI

Payment and pricing interfaces are high‑trust areas on web sites. Stored XSS in those components is especially dangerous because:

  • JavaScript executes in the site’s origin — attackers may access cookies, perform actions as users, or intercept form inputs if same‑origin policies permit.
  • Injected UI can mislead visitors (phishing or fraudulent prompts) and cause financial or reputational harm.
  • Stored payloads persist and affect every visitor who views the infected page, amplifying impact.

In Hong Kong and other jurisdictions with active eCommerce and payment activity, the reputational and regulatory consequences make prompt mitigation essential.

Technical summary of the flaw

  • Entry point: parameter pricing_plan_select_text_font_family, intended for font selection or label text.
  • Weakness: plugin accepts and stores input, later rendering it in HTML without context‑aware escaping or strict validation.
  • Attack vector: authenticated user (Author role or higher) injects malicious content via the plugin UI or settings. When visitors load the page, the stored content is rendered and executed.
  • Outcome: stored XSS — arbitrary JavaScript execution in visitors’ browsers.

The root cause appears to be lack of validation/whitelisting for values expected to be plain font names and failure to escape at output. A secure approach would whitelist fonts and ensure all stored values are rendered as plain text or safely escaped.

Who’s at risk?

  • Sites running Payment Page (Payment Form for Stripe) plugin versions ≤ 1.4.6.
  • Sites that grant Authors (or equivalent roles) the ability to edit pricing settings or plugin UI.
  • Multi‑author blogs, membership sites, editorial platforms, and any site where third parties can modify displayed content.

If Authors are tightly controlled and fully vetted, immediate risk is lower; if accounts are shared, reused, or managed by external contractors, risk increases.

Exploitability and impact assessment

Exploitability: Medium — attacker needs an authenticated Author account. No unauthenticated remote exploit is indicated.

Impact: Variable. Possible outcomes include:

  • Low–medium: UI tampering, redirects, nuisance scripts.
  • High: session theft, credential harvesting, capture of payment or personal data when forms share origin, or distribution of malicious payloads.

Because the vulnerability is stored, a single injection may compromise many visitors over time.

Practical detection: indicators you can check now

  1. Inventory: Confirm plugin presence and version via WordPress admin (Plugins > Installed Plugins). Identify pages that display pricing plan UI.
  2. Audit user roles: List accounts with Author privileges or higher and review recent changes to pricing or plugin settings.
  3. Search stored data: Query database tables (e.g., wp_postmeta, plugin options) for suspicious strings containing HTML tags (