CVE-2026-3569: Site Prober Information Disclosure Flaw

CVE-2026-3569 Overview

The Liaison Site Prober plugin for WordPress contains an Information Exposure vulnerability in all versions up to and including 1.2.1. The vulnerability exists in the /wp-json/site-prober/v1/logs REST API endpoint, where the permissions_read() permission callback unconditionally returns true (via __return_true()) instead of verifying appropriate user capabilities. This security flaw allows unauthenticated attackers to retrieve sensitive audit log data including IP addresses, user IDs, usernames, login/logout events, failed login attempts, and detailed activity descriptions.

Critical Impact

Unauthenticated attackers can access sensitive audit logs containing user credentials, IP addresses, and authentication activity data, potentially enabling targeted attacks against site users and administrators.

Affected Products

• Liaison Site Prober plugin for WordPress version 1.2.1 and earlier
• WordPress installations with Liaison Site Prober plugin enabled
• All WordPress sites exposing the REST API with this plugin active

Discovery Timeline

• 2026-04-24 - CVE-2026-3569 published to NVD
• 2026-04-24 - Last updated in NVD database

Technical Details for CVE-2026-3569

Vulnerability Analysis

This vulnerability is classified as CWE-862 (Missing Authorization), a common security flaw where access control checks are not properly implemented. The Liaison Site Prober plugin registers a REST API endpoint at /wp-json/site-prober/v1/logs that is intended to provide access to site audit logs. However, the endpoint's permission callback function uses WordPress's __return_true() helper, which unconditionally grants access to any requestor regardless of authentication status.

The exposed audit logs contain highly sensitive information that could be leveraged for further attacks. IP addresses can reveal user locations and be used for targeted phishing or network reconnaissance. User IDs and usernames provide valuable intelligence for credential stuffing or brute force attacks. Login/logout events and failed login attempts can reveal authentication patterns and potential security weaknesses in user accounts.

Root Cause

The root cause is an improper implementation of the REST API permission callback in the class-liaison-rest-controller.php file. Instead of implementing proper capability checks using WordPress functions like current_user_can(), the developer used __return_true() as the permission callback. This function is a WordPress utility that always returns true, effectively bypassing all authentication and authorization requirements for the endpoint.

Attack Vector

The attack can be performed remotely over the network by any unauthenticated user. An attacker simply needs to send an HTTP GET request to the vulnerable REST API endpoint. No user interaction is required, and the attack complexity is low since the endpoint accepts standard HTTP requests without any authentication headers or tokens.

The attacker crafts a request to the /wp-json/site-prober/v1/logs endpoint on a target WordPress site. The server processes this request, and because the permission callback returns true without verification, the full audit log data is returned in the API response. This data can then be used for reconnaissance, social engineering, or to plan additional attacks against the WordPress site and its users.

Detection Methods for CVE-2026-3569

Indicators of Compromise

• Unusual or frequent requests to /wp-json/site-prober/v1/logs from external IP addresses
• Access log entries showing unauthenticated requests to the Site Prober REST API endpoint
• Multiple sequential requests to the logs endpoint from the same source, indicating automated data harvesting
• Requests to the vulnerable endpoint from known threat actor IP ranges or Tor exit nodes

Detection Strategies

• Monitor web server access logs for GET requests to /wp-json/site-prober/v1/logs without authentication cookies
• Implement Web Application Firewall (WAF) rules to alert on unauthenticated REST API access attempts
• Review WordPress REST API access patterns for anomalous activity targeting plugin endpoints
• Deploy endpoint detection tools to identify reconnaissance activity against WordPress installations

Monitoring Recommendations

• Enable detailed logging for WordPress REST API endpoints and aggregate logs to a SIEM platform
• Configure alerts for high volumes of requests to plugin-specific REST API routes
• Implement rate limiting on REST API endpoints to slow down automated data exfiltration
• Regularly audit installed plugins for exposed REST API endpoints with insufficient access controls

How to Mitigate CVE-2026-3569

Immediate Actions Required

• Update Liaison Site Prober plugin to a patched version when available from the WordPress plugin repository
• Deactivate the Liaison Site Prober plugin immediately if it is not essential to site operations
• Review web server logs for evidence of prior exploitation targeting the vulnerable endpoint
• If the plugin was active, consider audit log data as potentially compromised and assess impact

Patch Information

The vulnerability has been identified in version 1.2.1 and all prior versions of the Liaison Site Prober plugin. A code change has been committed to address this issue. For technical details on the vulnerable code and the fix, refer to the WordPress Plugin Change Set. Additional vulnerability information is available in the Wordfence Vulnerability Report.

Workarounds

• Block access to /wp-json/site-prober/v1/logs at the web server level using .htaccess or nginx configuration rules
• Use a security plugin like Wordfence to restrict REST API access to authenticated users only
• Implement a custom mu-plugin to add proper permission checks to the vulnerable endpoint
• Consider placing the WordPress site behind a reverse proxy with access control rules for sensitive API endpoints

# Apache .htaccess workaround to block unauthenticated access to vulnerable endpoint
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-json/site-prober/v1/logs [NC]
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in
RewriteRule .* - [F,L]
</IfModule>