Tên plugin	Recurring PayPal Donations
Type of Vulnerability	Tấn công xuyên trang web (XSS)
CVE Number	CVE-2025-57891
Tính cấp bách	Thấp
CVE Publish Date	2025-08-22
Source URL	CVE-2025-57891

Vulnerability Advisory — Recurring PayPal Donations Plugin (≤ 1.8): Cross‑Site Scripting (XSS) — CVE‑2025‑57891

Đã xuất bản: 22 August 2025
Reported: 15 July 2025 (researcher: Nabil Irawan)
Mức độ nghiêm trọng: Low (CVSS 5.9)
Required privilege to trigger: Administrator
Đã sửa trong: 1.9

This advisory explains the Cross‑Site Scripting (XSS) vulnerability affecting versions 1.8 and earlier of the “Recurring PayPal Donations” WordPress plugin (assigned CVE‑2025‑57891). It is written from the perspective of WP‑Firewall, with practical guidance for site administrators, developers and security teams: how the issue works, how to detect exploitation, how to mitigate it immediately using configurations and monitoring, and secure coding fixes plugin authors should apply.

NOTE: The correct remediation is to update to plugin version 1.9 or later. If you cannot update immediately, follow the mitigations and detection steps below.

---

Executive summary

• What happened: A stored Cross‑Site Scripting (XSS) vulnerability was discovered in the Recurring PayPal Donations plugin affecting versions ≤ 1.8. Administrator‑level inputs are stored and later rendered without adequate escaping or filtering, allowing injected HTML/JS to be executed in the context of visitors and administrators.
• Risk: Low (CVSS 5.9) — exploitation requires Administrator privileges to insert the payload. However, impact of successful XSS can be significant: session theft, redirecting donations, defacement, or injecting external malware.
• Immediate fix: Upgrade the plugin to version 1.9 (or later), which contains the security fix.
• Interim mitigations (if you cannot update immediately): use a Web Application Firewall (WAF) virtual patch, add strict Content Security Policy (CSP) headers, sanitize stored data via a maintenance script, and limit admin access by IP or 2‑factor authentication.

---

How this XSS works — technical overview

From the report and analysis of plugin behavior, the vulnerability is best described as a stored XSS originating from admin‑entered content that is later rendered without proper escaping. Typical vectors in donation plugins are:

• Donation descriptions, thank‑you messages, receipt templates, or custom HTML fields exposed in the plugin settings page and later displayed on public pages or in admin previews.
• If the plugin allows administrators to enter HTML (or accepts strings without sanitization) and later prints those strings using raw echo/print without esc_html(), esc_attr(), hoặc wp_kses(), an injected script will execute in the context of any visitor that views the affected page.

Because the attacker must be an Administrator to save the malicious content, this is not an unauthenticated remote code execution bug. But stolen or compromised admin accounts, rogue employees, or insecure developer accounts can be used to plant payloads that then affect site visitors and other administrators.

Key indicators of the vulnerability:

• The plugin stored user content (in options or postmeta) that is later output to pages without escaping.
• The plugin accepted input fields where HTML was allowed and did not call safe filtering functions on save or proper escaping on render.

---

Reproduction (high level)

I will not publish exploit code, but here are the high‑level steps an attacker with Administrator privileges would follow:

1. Log in to WP Admin as an Administrator.
2. Navigate to the Recurring PayPal Donations plugin settings or any plugin UI that allows free text or custom messages.
3. Insert HTML/JavaScript into a field that is persisted (for example, a “donation message”, “thank you page content”, or similar).
4. Save settings. The content is stored in the options/postmeta table.
5. A visitor or other Administrator views the frontend or a plugin preview where the stored content is printed out; the malicious script executes in that user’s browser.

Because the payload is stored, it can persist across requests and affect multiple visitors and admins until removed.

---

Immediate actions for site administrators (priority order)

1. Upgrade the plugin to version 1.9 or later
   • This is the only complete, vendor‑maintained fix. If you can update immediately, do so during a maintenance window.
2. If you cannot update immediately, put temporary mitigations in place:
   • Enable a WAF rule (virtual patch) blocking XSS payloads for POST/OPTIONS to plugin admin pages. See suggested WAF rules later.
   • Restrict access to wp‑admin and plugin settings pages by IP (where possible) or require VPN.
   • Enforce strong admin account controls: rotate passwords for all admin accounts, enable 2‑factor authentication, and inspect admin user list for unknown accounts.
   • Add a strict CSP header to reduce impact of inline scripts:
     • Example minimal CSP header:
       Content‑Security‑Policy: default‑src 'self'; script‑src 'self' https://trusted.paypal.com; object‑src 'none'; base‑uri 'self';
     • Note: CSP tuning must be tested; it can interfere with site functionality if too strict.
3. Search for and remove any malicious stored content:
   • Search options and postmeta for script tags and suspicious external domains. Example SQL (run in a read‑only manner first):

   SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%';
   SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';
   SELECT ID, user_login FROM wp_users WHERE user_login NOT IN ('admin','your_known_usernames');
       

   • Use a trusted malware scanner to check for injected files and database entries.
4. Monitor and notify:
   • Check webserver logs for suspicious POSTs against admin endpoints and for requests that include suspicious strings.
   • Notify team members and the organization that a vulnerability exists; if you detect signs of compromise, escalate to incident response.

---

Detection: how to tell if your site was exploited

Look for the following signals:

• Unexpected scripts or <script> tags in pages that previously contained plain text (donation descriptions, receipts).
• Redirects from donation pages to suspicious domains or PayPal links with altered parameters.
• New or modified admin pages, posts, or options that include HTML/JS.
• New administrator accounts or changes to existing accounts.
• Outgoing connections from the server to unfamiliar external domains.
• Browser console errors referencing inline scripts where none existed before.

Automated checks you can run:

SELECT option_name, LENGTH(option_value) as L, option_value
FROM wp_options
WHERE option_value LIKE '%<script%';

grep -R --exclude-dir=wp-content/uploads -n "<script" /var/www/html

find /var/www/html -type f -mtime -7 -print

Check for suspicious cron events and scheduled tasks.

If you detect exploitation, contain first (take site offline or enable maintenance mode), then follow incident response steps below.

---

Incident response (recommended steps)

1. Contain
   • Put the site into maintenance mode OR restrict access to admin by IP.
   • Do not delete logs or evidence.
2. Preserve evidence
   • Make full backups of files and the database (forensics copies).
   • Export webserver access and error logs.
3. Eradicate
   • Remove malicious content from database and files.
   • Disable the affected plugin if immediate update is not possible.
   • Revoke and rotate all administrator passwords and API keys (including PayPal API credentials if you suspect they were targeted).
   • Check for webshells or backdoors in uploads and plugin/theme directories.
4. Recover
   • Update plugin to 1.9 or later.
   • Restore clean backups if necessary.
   • Rebuild admin accounts after forensic review.
5. Post‑incident
   • Enforce 2‑factor authentication for all admin users.
   • Increase monitoring and schedule regular scans.
   • Conduct a root cause analysis (RCA) and document lessons learned.

---

Suggested WAF / Virtual patch rules (examples)

If you run WP‑Firewall (or any WAF), create a targeted virtual patch to block likely exploit payloads until the plugin update can be applied. Below are general rule ideas — tune to fit your environment to reduce false positives. Replace parameter names with actual plugin field names when known (for example, donation_message, receipt_text, recurring_description).

Warning: overly broad rules can create false positives and break legitimate functionality. Test in blocking → monitoring mode first.

Example ModSecurity (Apache) rule — basic XSS detection in request parameters:

# Block suspicious script tags and inline event handlers in request fields
SecRule ARGS_NAMES|ARGS "@rx (?:<\s*script\b|javascript:|on\w+\s*=)" \
    "id:1001001,phase:2,deny,status:403,log,msg:'Potential XSS - blocking request',severity:2"

More specific rule targeting plugin admin pages (only block when URI contains the plugin slug):

SecRule REQUEST_URI "@contains recurring-donation" "phase:1,id:1001002,pass,nolog,chain"
  SecRule ARGS "@rx (?:<\s*script\b|javascript:|on\w+\s*=)" "id:1001003,phase:2,deny,log,msg:'WAF: recurring-donation XSS attempt'"

Nginx (ngx_lua) example — block requests with script tags:

# inside server/location
access_by_lua_block {
  local args = ngx.req.get_uri_args()
  local suspicious = false
  for k, v in pairs(args) do
    if type(v) == "table" then
      v = table.concat(v, " ")
    end
    if v:lower():find("<script") or v:lower():find("javascript:") or v:lower():find("on%w+=") then
      suspicious = true
      break
    end
  end
  if suspicious then
    ngx.log(ngx.ERR, "Blocked suspicious XSS request")
    return ngx.exit(403)
  end
}

WordPress‑level hardening (PHP hook) — sanitize incoming options before saving:

add_filter( 'pre_update_option_recurring_donation_custom_message', function( $new_value, $old_value, $option ) {
    // Strip scripts; allow limited HTML if needed.
    return wp_kses( $new_value, array(
        'a' => array( 'href' => true, 'title' => true ),
        'strong' => array(), 'em' => array(), 'p' => array()
    ) );
}, 10, 3 );

These examples are starting points. Where possible, block requests only when they target the vulnerable plugin pages and when they carry suspicious payloads.

---

Fixes plugin developers must implement

If you maintain or develop plugins, the secure design fixes are straightforward:

1. Validate input on save
   • Sử dụng vệ sinh trường văn bản(), sanitize_email(), sanitize_hex_color(), intval(), hoặc wp_kses() depending on the expected input.
   • If admin can input HTML intentionally, use wp_kses() with a strict allowed tags list.
2. Escape output on render
   • Sử dụng esc_html(), esc_attr(), esc_url(), hoặc wp_kses_post() when printing content to the page.
   • Do not rely on “trusted admin input” — escape at render time as well.
3. Capability checks and nonces
   • Verify current_user_can( 'manage_options' ) or equivalent capability before processing settings.
   • Sử dụng wp_nonce_field() Và check_admin_referer() to avoid CSRF that could be used to inject content.
4. Store structured data
   • Where possible, store data in structured arrays or serialized objects with well known keys, rather than arbitrary HTML blobs.
5. Unit tests and security review
   • Add tests that assert that HTML tags are escaped/filtered in rendered outputs.
   • Include static analysis and threat modeling in your development lifecycle.

Example save handler (secure):

if ( isset( $_POST['recurring_message'] ) && current_user_can( 'manage_options' ) ) {
    check_admin_referer( 'recurring_save_settings', 'recurring_nonce' );
    $clean = wp_kses( wp_unslash( $_POST['recurring_message'] ), array(
        'a' => array( 'href' => true, 'title' => true ),
        'strong' => array(), 'em' => array(), 'p' => array()
    ) );
    update_option( 'recurring_message', $clean );
}

And when rendering:

echo wp_kses_post( get_option( 'recurring_message' ) ); // already cleaned, but safe double-check

---

Long‑term security recommendations for site owners

• Keep WordPress core, plugins and themes updated automatically where safe, or at least patch critical fixes promptly.
• Limit Administrator accounts to only those who need full privileges. Use Editor/Author when possible.
• Enforce MFA (2FA) for all privileged accounts.
• Harden wp-admin access by IP whitelisting or VPN for administrators.
• Use a managed WAF with virtual patching capabilities so your site can stay protected between disclosure and patching.
• Enable file integrity monitoring and scheduled malware scans.
• Regularly back up your site and database and test restores.
• Monitor web application logs and set alerts for suspicious POST requests and unusual URIs.

---

Example search queries and commands for responders

Search database for script tags:

SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%<script%';
SELECT meta_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%';

Find suspicious tags inside theme and plugin files:

grep -R --exclude-dir=wp-content/uploads -n "<script" wp-content/plugins wp-content/themes

Check for recent admin account creation:

SELECT ID, user_login, user_registered FROM wp_users WHERE user_registered > DATE_SUB(NOW(), INTERVAL 30 DAY);

List recently modified files:

find /var/www/html -type f -mtime -30 -ls

---

Câu hỏi thường gặp

Q: My site uses this plugin but I don’t see any signs of compromise. What should I do?
A: Update the plugin to 1.9 immediately. Then perform the detection checks listed above (database search for script tags, recent logins, new admin users). If nothing suspicious is found you are likely safe, but keep monitoring logs for a while.

Q: Does this vulnerability allow attackers to run arbitrary code on the server?
A: No. This is an XSS issue (client‑side). It executes JavaScript in visitors’ browsers, not server code. However, XSS can be used to steal admin sessions, which could then be used to make server‑side changes.

Q: My WordPress site uses a managed firewall. Am I safe?
A: A managed WAF significantly reduces risk, especially if it provides virtual patching for new vulnerabilities. However, WAF signatures should be designed to catch the specific injection vectors; always apply vendor plugin updates when available.

---

Timeline & credit

• Reported by researcher: Nabil Irawan — 15 July 2025
• Public advisory published: 22 August 2025
• CVE assigned: CVE‑2025‑57891
• Fixed in Recurring PayPal Donations plugin: version 1.9

We thank the researcher for responsible disclosure and encourage plugin developers to adopt secure coding patterns.

---

How WP‑Firewall can help (and why temporary protection matters)

As a WordPress security provider, WP‑Firewall recommends the following layered approach for fast protection:

• Apply the vendor patch (plugin update) as your primary remediation.
• Enable WP‑Firewall virtual patching to block known exploit patterns while you plan updates.
• Turn on continuous malware scanning to detect any injected scripts or backdoors.
• Use granular IP restrictions and user account hardening to reduce privileged account risk.
• Schedule regular security reports and vulnerability scans so your team learns about potentially vulnerable plugins before they are exploited.

If you need immediate, frictionless protection, you can start with our Basic Free plan which includes managed firewall, WAF, malware scanning, and mitigation of OWASP Top 10 risks. See details below.

---

Get Essential Protection with WP‑Firewall Free Plan

Protecting your site today doesn’t have to mean cost or complexity. WP‑Firewall’s Basic Free plan provides essential defenses that block common exploitation techniques like XSS, SQL injection, and file inclusion attacks. The free plan includes a managed firewall with a WAF, unlimited bandwidth, scheduled malware scanning, and automatic mitigations against OWASP Top 10 threats — everything you need to reduce the window of exposure while maintaining site performance.

• Cơ bản (Miễn phí)
  • Managed firewall and WAF
  • Băng thông không giới hạn
  • Malware scanner
  • Giảm thiểu 10 rủi ro hàng đầu của OWASP
• Standard ($50/year)
  • Everything in Basic, plus:
  • Tự động xóa phần mềm độc hại
  • Blacklist & whitelist up to 20 IPs
• Pro ($299/year)
  • Everything in Standard, plus:
  • Báo cáo an ninh hàng tháng
  • Auto virtual patching for vulnerabilities
  • Premium add‑ons: Dedicated Account Manager, Security Optimization, WP Support Token, Managed WP Service, and Managed Security Service

Enroll in the free plan today and keep your WordPress site protected while you apply shop‑floor fixes: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Closing recommendations — what to do now

1. Update the Recurring PayPal Donations plugin to 1.9 immediately.
2. If you cannot update now, enable a WAF rule (virtual patch), restrict admin access by IP, and enforce 2FA.
3. Search your database and files for injected scripts and suspicious entries; remove and restore from clean backups if you find active malicious content.
4. Harden admin account security and rotate credentials.
5. Consider adding a CSP to reduce inline script impact, and add scheduled malware scans.

XSS vulnerabilities like CVE‑2025‑57891 are straightforward to fix, but they can be used as a stepping stone to larger compromises if administrative accounts are weak or credentials are stolen. Patch promptly, harden admin access, and use layered protection to reduce both the chance and impact of exploitation.

If you need help implementing virtual patches or creating tuned WAF rules for your environment, WP‑Firewall support can assist — and our free plan is a good place to start to get immediate managed protection while you apply permanent fixes.