CVE-2026-19985

Executive Summary

CVE-2026-19985 is a reflected Cross-Site Scripting (XSS) vulnerability in the Relevanssi – A Better Search WordPress plugin affecting versions up to and including 4.28.1. The flaw resides in the relevanssi_debug_array() function within lib/debug.php, which dumps user-supplied query variables via print_r() inside a <pre> block without HTML escaping. Because the debug gate is a configuration-only check lacking capability, nonce, or authentication verification, unauthenticated attackers can inject arbitrary scripts into pages rendered for users who are tricked into clicking a crafted link, provided the site administrator has enabled "Debugging mode" and "relevanssi_debug=on" is supplied. The CVSS score is 6.1 (Medium).

Technical Analysis

The vulnerability is a classic reflected XSS (CWE-79) arising from insufficient input sanitization and output escaping. Relevanssi is a full-text search replacement plugin for WordPress, and it ships a debugging subsystem in lib/debug.php. When an administrator has enabled the "Debugging mode" plugin setting, the debug path can be activated per-request by supplying the relevanssi_debug=on parameter.

Once activated, the relevanssi_debug_array() function takes user-supplied query variables and dumps them using PHP's print_r() function, wrapping the output in a <pre> HTML block. Crucially, the output is not passed through HTML-escaping functions (e.g., esc_html(), htmlspecialchars()). Any HTML metacharacters present in the attacker-controlled values are therefore emitted verbatim into the response body. Because the dump is rendered inside a <pre> tag, injected markup such as <script> survives into the DOM and executes in the victim's browser context.

The attack surface is reachable by unauthenticated requests. The gate controlling debug mode is described as a configuration check only: it verifies that the administrator previously enabled debugging, but performs no capability check, no nonce verification, and no logged-in check. The description further notes that the vendor explicitly suppresses nonce verification on that line. This means an attacker does not need any WordPress account or valid nonce to reach the vulnerable code path — they only need the site to have debugging enabled, which is a common diagnostic posture but not the default.

The three vulnerable request parameters are s, post_types, and orderby, all of which are standard search-related inputs and accept arbitrary attacker strings. Since the vulnerable function reflects these values directly, the payload is fully attacker-controlled.

Two preconditions constrain exploitation: (1) the site administrator must have enabled the "Debugging mode" setting, and (2) the resulting reflected page must be delivered to and rendered by a victim, which is why the CVSS vector includes UI:R (User Interaction: Required). The scope change (S:C) reflects that a script executing in the victim's session can pivot beyond the immediate page context — for instance, acting with the victim's privileges in the WordPress admin interface. Confidentiality and Integrity impacts are Low (C:L/I:L), with no availability impact (A:N).

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (reflected XSS) and the mechanism described in the NVD entry. No specific function names, endpoints, or parameters beyond those stated in the description are assumed.

1. Reconnaissance / target identification. An attacker identifies WordPress sites running the Relevanssi plugin at a version at or below 4.28.1. This can be done passively via Shodan-style enumeration of http.html fingerprints referencing the plugin path, or via standard WordPress plugin enumeration. The attacker then needs to determine whether the "Debugging mode" setting is enabled. Because the debug gate is a configuration check with no authentication, an attacker can probe candidate URLs by appending the relevanssi_debug=on request parameter and observing whether debug output is returned — a low-noise way to confirm the precondition.

2. Triggering the flaw class. With debugging enabled, the attacker crafts a search URL that includes relevanssi_debug=on together with a malicious value in one of the injectable parameters (s, post_types, or orderby). The value contains HTML/JavaScript markup. The request reaches relevanssi_debug_array() in lib/debug.php, which reflects the unescaped input through print_r() inside a <pre> block. No nonce, capability, or login is required because the vendor suppressed nonce verification on the gate.

3. Payload / execution. The attacker delivers the crafted link to a victim (for instance, an authenticated administrator or any site user) via phishing email, a chat message, or a forum post. When the victim clicks the link, the page renders and the injected script executes in the victim's browser under the site's origin. The attacker does not need to host anything themselves — the vulnerable site is the injection point.

4. Post-exploitation impact. The executed script runs with the origin of the targeted WordPress site. Depending on what privileges the victim holds, the script can read page content and tokens accessible to the DOM, perform actions as the victim, modify content presented to the victim, or exfiltrate data to an attacker-controlled endpoint. The CVSS scope change (S:C) reflects the potential to affect resources beyond the immediately vulnerable component — for example, interacting with the WordPress administrative interface if an administrator is the victim. Because the reflected page is transient and requires user interaction, the vulnerability is best suited to targeted attacks rather than mass opportunistic exploitation.

Impact Assessment

The CVSS 3.1 base score is 6.1 (Medium), with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. The subscores indicate:

• Attack Vector (Network, AV:N): exploitable remotely over the web.
• Attack Complexity (Low, AC:L): no specialized conditions beyond the debug-enabled configuration.
• Privileges Required (None, PR:N): the vulnerable code path is unauthenticated due to the missing capability and nonce checks on the debug gate.
• User Interaction (Required, UI:R): a victim must click a crafted link and render the reflected page.
• Scope (Changed, S:C): impact can extend beyond the vulnerable component into the victim's session context.
• Confidentiality (Low, C:L) and Integrity (Low, I:L): script execution can read and alter data available to the victim's browser session; Availability (None, A:N).

Business impact centers on session and content integrity on affected WordPress sites. If an administrator is the victim, script execution can leverage the admin session rather than obtaining credentials directly, potentially enabling content manipulation or lateral actions within the admin interface consistent with XSS impact. Blast radius is limited to sites with Relevanssi <= 4.28.1 and debugging mode enabled, and to users who interact with a crafted link. There is no evidence of CISA KEV listing, active exploitation, or public exploit code at the time of this report; EPSS is not yet scored by FIRST.org. The patch confidence is 0/4 and no vendor fix has been published, so affected deployments remain exposed until an update is released or debugging mode is disabled.

Detection Guidance

Sigma Rule

title: Relevanssi Reflected XSS Debug Parameter Abuse (CVE-2026-19985)
id: 9f2c4b1a-7e3d-4c88-9a11-3d5e6f7a8b90
status: experimental
description: Detects requests to WordPress sites using the relevanssi_debug=on parameter, which activates the vulnerable debug path in Relevanssi <= 4.28.1 and may carry XSS payloads.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-19985
author: valtersit.com
date: 2026-01-01
logsource:
  category: webserver
detection:
  selection_debug:
    cs-uri-query|contains: 'relevanssi_debug=on'
  selection_payload:
    cs-uri-query|contains:
      - '<script'
      - '%3Cscript'
      - 'onerror='
      - 'onload='
      - 'javascript:'
      - '<img'
      - '<svg'
  condition: selection_debug or (selection_debug and selection_payload)
fields:
  - c-ip
  - cs-uri-query
  - cs-user-agent
falsepositives:
  - Legitimate administrators manually enabling debug on a search page
level: high

YARA Rule

rule CVE_2026_19985_Relevanssi_XSS
{
    meta:
        description = "Detects Relevanssi plugin files with the vulnerable debug dump routine (print_r inside <pre>) in lib/debug.php"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-19985"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $fn   = "relevanssi_debug_array"
        $dbg  = "relevanssi_debug"
        $dump = "print_r"
        $pre  = "<pre"

    condition:
        uint32(0) == 0x3C3F7068 or       // "<?ph" PHP opener heuristic
        ( $fn and $dbg and $dump and $pre )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-19985 Relevanssi Reflected XSS via relevanssi_debug Parameter"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"relevanssi_debug=on"; nocase; http.uri; pcre:"/(%3C|<)script|onerror=|onload=|javascript:/i"; reference:cve,2026-19985; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-19985; classtype:web-application-attack; sid:202619985; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where http.request.method == "GET" and
      http.request.uri : "*relevanssi_debug=on*" ]

Splunk SPL Query

index=web sourcetype=access_combined
| eval q=urldecode(uri_query)
| where like(q, "%relevanssi_debug=on%")
| eval xss=if(like(lower(q), "%<script%") OR like(lower(q), "%onerror=%") OR like(lower(q), "%javascript:%") OR like(lower(q), "%<svg%") OR like(lower(q), "%<img%"), 1, 0)
| stats count values(uri) as uris values(clientip) as src_ips by xss, host
| sort - count

Wazuh OSSEC Rule

<group name="web,appsec,relevanssi,">
  <rule id="2026198" level="10">
    <decoded_as>web-accesslog</decoded_as>
    <url>relevanssi_debug=on</url>
    <regex type="pcre2">(?i)(%3Cscript|&lt;script|onerror=|onload=|javascript:)</regex>
    <description>CVE-2026-19985: Relevanssi reflected XSS attempt via relevanssi_debug parameter with script payload</description>
    <mitre>
      <id>T1189</id>
    </mitre>
    <group>web_attack,xss,</group>
  </rule>

  <rule id="2026199" level="6">
    <decoded_as>web-accesslog</decoded_as>
    <url>relevanssi_debug=on</url>
    <description>CVE-2026-19985: Relevanssi debug parameter accessed (possible recon for reflected XSS)</description>
    <group>web_recon,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations

• Disable the Relevanssi "Debugging mode" setting on all production WordPress sites. Because the vulnerable path is gated behind this configuration, disabling it removes the primary exploitation precondition.
• If debugging is required for troubleshooting, restrict it to maintenance windows and immediately re-disable it afterward.
• Where feasible, deploy a WAF or reverse-proxy rule that blocks or strips requests containing relevanssi_debug=on, and that blocks obvious XSS encodings (<script, %3Cscript, javascript:, event handlers) in search parameters.
• Monitor web access logs for the detection patterns in the Detection Guidance section to identify reconnaissance or exploitation attempts.

2. Patch / upgrade steps

• No vendor patch is currently available; vulnerable versions are up to and including 4.28.1. Track the Relevanssi plugin changelog and WordPress plugin repository for a fixed release.
• As soon as a patched version is published, update the plugin through the WordPress admin or via WP-CLI (wp plugin update relevanssi), then verify the installed version.
• Because no vendor fix exists, do not assume that a version bump on unrelated plugins resolves this issue.

3. Long-term hardening

• Adopt a plugin governance process that inventories third-party plugins, tracks their CVE exposure, and removes unused plugins.
• Apply defense-in-depth against XSS: enforce a Content-Security-Policy that restricts inline script execution, and configure cookies with HttpOnly and Secure attributes (WordPress core sets HttpOnly by default for auth cookies) to limit session theft.
• Require that debugging and diagnostic features are disabled by default in production and gated behind authenticated, nonce-verified, capability-checked code paths during development.
• Perform periodic vulnerability scanning of WordPress deployments and subscribe to plugin-specific advisories.

References

1. NVD — CVE-2026-19985: https://nvd.nist.gov/vuln/detail/CVE-2026-19985
2. CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): https://cwe.mitre.org/data/definitions/79.html
3. WordPress Plugin Security / Hardening guidance: https://developer.wordpress.org/plugins/security/
4. MITRE ATT&CK T1189 — Drive-by Compromise: https://attack.mitre.org/techniques/T1189/
5. OWASP Cross Site Scripting Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

No known threat actor campaigns or exploit-in-the-wild evidence are associated with this CVE at the time of writing. CISA KEV listing: NO. Public PoC/exploit code: None. Nuclei template: NO. EPSS has not yet been scored by FIRST.org. This report is based solely on the supplied CVE intelligence; any implementation details not present in the NVD description have been described at the vulnerability-class level rather than fabricated.