CVE-2024-1380

What it actually does

The vulnerability is a missing authorization check in the Relevanssi WordPress plugin function relevanssi_export_log_check(), affecting Relevanssi Free versions up to and including 4.22.0 and Relevanssi Premium versions up to and including 2.25.0. Because the vulnerable function can be reached without a valid authenticated WordPress session or required capability check, a remote unauthenticated attacker can export Relevanssi query log data. The impact is limited to confidentiality: the flaw does not directly allow code execution, data modification, privilege escalation, or denial of service, but it can disclose search queries and related logging metadata that may contain sensitive business, user, or operational information. The supplied package metadata also references Debian 12 fixes at version 6.1.112-1; reconcile this against asset inventory because the described vulnerability is specific to the Relevanssi WordPress plugin.

Why it matters to the business

An attacker can obtain search log data from affected WordPress sites without logging in. Search logs may reveal what users, staff, or customers searched for, including names, email addresses, order details, internal terminology, product plans, support issues, or other sensitive text entered into site search. While the direct severity is moderate, exploit maturity is listed as weaponized and EPSS is high at approximately 50%, so internet-facing WordPress sites using the affected plugin should be treated as likely to be probed. The issue is not currently listed in CISA KEV and is not marked as used in ransomware campaigns, but leaked search data can still support phishing, social engineering, competitive intelligence gathering, and follow-on attacks.

How an attack unfolds

An attacker first identifies a WordPress site running the Relevanssi search plugin, often by checking public plugin paths, page behavior, or automated vulnerability scanner fingerprints. The attacker then sends a crafted unauthenticated web request to the WordPress AJAX/admin endpoint or plugin-exposed path that invokes the vulnerable export-log check functionality. Because the affected function does not properly verify that the requester is logged in and has an administrative capability, the application processes the request and returns or enables retrieval of query log export data. The attacker saves the exported data and reviews it for sensitive search terms, user identifiers, business information, or clues that can be used for targeted phishing, credential attacks, or reconnaissance. Weaponized exploitation means this can be automated at scale across exposed WordPress installations.

How to fix it

Upgrade Relevanssi to a version newer than the affected range: Relevanssi Free later than 4.22.0 and Relevanssi Premium later than 2.25.0, or the latest version available from the vendor. If an immediate upgrade is not possible, temporarily disable the Relevanssi query logging/export functionality, restrict access to WordPress administrative and AJAX endpoints with WAF or reverse proxy controls where operationally feasible, and monitor or block unauthenticated requests containing the vulnerable export action. Review whether query logging is necessary and minimize retention of search logs to reduce exposure. If the asset is tracked through Debian 12 package metadata, the provided fixed version is 6.1.112-1 or later; however, validate applicability because the vulnerability description maps to a WordPress plugin rather than the Linux kernel package metadata.

How to confirm the fix worked

Confirm the installed Relevanssi version is no longer within the affected range: Free must be newer than 4.22.0 and Premium must be newer than 2.25.0. From an unauthenticated browser session or test client, attempt to access the vulnerable export-log action and verify the response is denied, redirected to authentication, or returns an authorization failure rather than query log data or an export file. Review WordPress plugin files or vendor changelog for an added capability/authorization control around relevanssi_export_log_check(). Check web server and WAF logs after remediation to ensure unauthenticated requests to the export action return 401, 403, 302-to-login, or another non-disclosing response. For package-managed assets using the supplied Debian metadata, confirm the relevant package version is at least 6.1.112-1 where applicable.

Typical attack path

1. Scan the internet or a target domain for WordPress sites using the Relevanssi plugin.
2. Confirm the site is running an affected Relevanssi Free version up to 4.22.0 or Premium version up to 2.25.0, or simply attempt the vulnerable request.
3. Send an unauthenticated HTTP request that triggers the relevanssi_export_log_check() functionality, commonly through WordPress AJAX/admin request handling.
4. Receive a successful response or export artifact containing Relevanssi query log data.
5. Analyze exported search logs for sensitive search terms, personal data, internal vocabulary, business context, or information useful for follow-on attacks.
6. Use the disclosed information for reconnaissance, social engineering, phishing, credential targeting, or competitive intelligence.

How to detect it

Look for evidence that unauthenticated users accessed Relevanssi query log export functionality. Primary log sources are web server access logs, CDN/WAF logs, reverse proxy logs, WordPress application logs, PHP error logs, and any endpoint telemetry that records request parameters. Search for requests to WordPress AJAX or admin endpoints containing the action or function name relevanssi_export_log_check, especially from requests without WordPress authentication cookies such as wordpress_logged_in or wp-settings. High-confidence suspicious events include HTTP 200 responses, file-download content types, CSV/export-like responses, or response sizes larger than normal for unauthenticated admin-ajax requests. Correlate source IPs with repeated WordPress probing, plugin enumeration, requests to /wp-content/plugins/relevanssi/, and other vulnerability-scan traffic. If query logs contain sensitive terms, assume those terms may have been exposed if matching export requests succeeded before remediation. Review WAF blocked/allowed events for parameter names containing relevanssi, export, log, or query log, and preserve any response metadata that indicates successful data transfer.

• relevanssi_export_log_check
• action=relevanssi_export_log_check
• /wp-admin/admin-ajax.php
• /wp-content/plugins/relevanssi/
• /wp-content/plugins/relevanssi-premium/
• relevanssi
• export_log
• query_log
• wordpress_logged_in

What your security team should do

• Prioritize internet-facing WordPress sites running Relevanssi because exploit maturity is weaponized and EPSS is high despite the moderate CVSS score.
• Inventory WordPress installations and identify Relevanssi Free versions up to 4.22.0 and Relevanssi Premium versions up to 2.25.0.
• Upgrade affected Relevanssi installations to the latest available release and remove unused copies of the plugin.
• If patching is delayed, block or challenge unauthenticated requests containing the vulnerable Relevanssi export action at the WAF, CDN, or reverse proxy layer.
• Search web access logs, WAF logs, and WordPress logs for evidence of unauthenticated access to the export-log functionality, especially responses with HTTP 200 and unusually large response sizes.
• Review exported or stored search logs for sensitive data exposure and apply data minimization or retention limits.
• Treat exposed search terms as potentially compromised and assess whether they contain personal data, credentials, customer identifiers, confidential project names, or regulated information.
• Reconcile the conflicting product metadata: the CVE description is for the Relevanssi WordPress plugin, while supplied fixed versions reference Debian 12 version 6.1.112-1.