Summary
The GetPaid WordPress plugin contains a stored cross-site scripting vulnerability caused by insufficient sanitization of the mmdwqzpoxadd parameter and inadequate output escaping. An unauthenticated attacker may store arbitrary browser script that executes when an administrator views the affected invoice's Payment Form Details metabox.
The GetPaid WordPress plugin contains a stored cross-site scripting vulnerability caused by insufficient sanitization of the mmdwqzpoxadd parameter and inadequate output escaping. An unauthenticated attacker may store arbitrary browser script that executes when an administrator views the affected invoice's Payment Form Details metabox.
Affected context
The issue affects WordPress sites using the GetPaid plugin's payment forms, Buy Now buttons, or invoicing features. It becomes risky when user-controlled input reaches the affected parameter, is stored without context-appropriate sanitization, and is later rendered in the invoice administration interface. The publicly emitted getPaid_form_nonce value may allow unauthenticated request flows where no prior authentication or nonce disclosure is required.
The issue affects WordPress sites using the GetPaid plugin's payment forms, Buy Now buttons, or invoicing features. It becomes risky when user-controlled input reaches the affected parameter, is stored without context-appropriate sanitization, and is later rendered in the invoice administration interface. The publicly emitted getPaid_form_nonce value may allow unauthenticated request flows where no prior authentication or nonce disclosure is required.
Exploit preconditions
- Attack surface: WordPress-facing GetPaid payment or invoicing functionality
- Required access: No authenticated account is generally required if the affected unauthenticated input path is reachable
- Trigger point: An administrator views an affected invoice's Payment Form Details metabox
- Why exploitation is possible: The parameter's value can be stored and later rendered without sufficient input sanitization or output escaping, while the related nonce is publicly exposed to visitors
- Attack surface: WordPress-facing GetPaid payment or invoicing functionality
- Required access: No authenticated account is generally required if the affected unauthenticated input path is reachable
- Trigger point: An administrator views an affected invoice's Payment Form Details metabox
- Why exploitation is possible: The parameter's value can be stored and later rendered without sufficient input sanitization or output escaping, while the related nonce is publicly exposed to visitors
Why this happens
The vulnerability results from treating externally supplied parameter data as trusted content when storing and rendering invoice-related fields. Insufficient sanitization during input handling, combined with missing or context-inappropriate output escaping, allows markup or script content to be interpreted by a browser in an administrative context. This behavior maps to CWE-79: Improper Neutralization of Input During Web Page Generation, commonly known as cross-site scripting.
The vulnerability results from treating externally supplied parameter data as trusted content when storing and rendering invoice-related fields. Insufficient sanitization during input handling, combined with missing or context-inappropriate output escaping, allows markup or script content to be interpreted by a browser in an administrative context. This behavior maps to CWE-79: Improper Neutralization of Input During Web Page Generation, commonly known as cross-site scripting.
Potential impact
- An attacker may execute arbitrary script in an administrator's browser session
- The script could perform actions available to the affected administrator
- Sensitive administrative information may be exposed
- Site content, settings, or plugin data could be modified
- The vulnerability can facilitate administrative account compromise or further site abuse
- An attacker may execute arbitrary script in an administrator's browser session
- The script could perform actions available to the affected administrator
- Sensitive administrative information may be exposed
- Site content, settings, or plugin data could be modified
- The vulnerability can facilitate administrative account compromise or further site abuse
General mitigation guidance
Mitigation generally focuses on reducing trust in form and invoice data and applying defenses at both input and output boundaries.
Common defensive patterns include:
- Validate and sanitize values according to their expected type and business purpose
- Apply context-appropriate output escaping immediately before rendering data in HTML, attributes, or JavaScript
- Use framework-provided escaping and validation APIs rather than manually constructed filters
- Treat publicly exposed nonces as request-integrity controls, not authentication or authorization mechanisms
- Enforce capability checks for administrative invoice views and state-changing operations
- Use restrictive browser security policies, such as Content Security Policy, as defense in depth
Mitigation generally focuses on reducing trust in form and invoice data and applying defenses at both input and output boundaries.
Common defensive patterns include:
- Validate and sanitize values according to their expected type and business purpose
- Apply context-appropriate output escaping immediately before rendering data in HTML, attributes, or JavaScript
- Use framework-provided escaping and validation APIs rather than manually constructed filters
- Treat publicly exposed nonces as request-integrity controls, not authentication or authorization mechanisms
- Enforce capability checks for administrative invoice views and state-changing operations
- Use restrictive browser security policies, such as Content Security Policy, as defense in depth
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis rules identifying unescaped user-controlled values in WordPress output contexts
- Code review checks tracing parameters from request handling through storage and administrative rendering
- Tests that submit representative special characters and verify encoded output in every rendering context
- Monitoring for unexpected script-like content in invoice, payment-form, and metadata fields
- Policy enforcement requiring capability checks, validation, and escaping for plugin data flows
- Automated security and code review tools that flag common stored XSS patterns
Organizations can look for this issue through:
- Static analysis rules identifying unescaped user-controlled values in WordPress output contexts
- Code review checks tracing parameters from request handling through storage and administrative rendering
- Tests that submit representative special characters and verify encoded output in every rendering context
- Monitoring for unexpected script-like content in invoice, payment-form, and metadata fields
- Policy enforcement requiring capability checks, validation, and escaping for plugin data flows
- Automated security and code review tools that flag common stored XSS patterns
