Base de CVEs

The WP Business Intelligence Lite plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.2.0. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with Subscriber-level access and above, to modify stored SQL queries, which can lead to privilege escalation via arbitrary SQL execution when the modified query is viewed by an administrator.

The Chat Help – Click to Chat Button & Form plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 3.1.3 via the REST API endpoints /wp-json/chat-help/v1/leads and /wp-json/chat-help/v1/leads/{id}. This is due to the plugin not performing any authentication and authorization checks. This makes it possible for unauthenticated attackers to extract sensitive data including customer names, email addresses, phone numbers, WhatsApp messages, complete geolocation data (IP addresses, city, country, ISP, coordinates), device fingerprinting information (browser, OS, screen resolution), and WordPress account credentials (user IDs, usernames, emails, names) for logged-in users who submit forms.

Kirby is an open-source content management system. Prior to 4.9.4 and 5.4.4, Kirby sites where a role has the pages.access permission disabled allowed authenticated users who know or guess page IDs or UUIDs to retrieve page information, including full content and metadata, for arbitrary published pages through the /api/site/find route without authorization to access those pages. This issue is fixed in versions 4.9.4 and 5.4.4.

The implementation of an internal and undocumented Dashboard API endpoint (POST /api/users/~/{user}/tokens) forgot to ensure an HTTP request for creating an API Token for another user had sufficient permission to do so. Precondition for successful exploitation was a preexisting internal user (with more privileges than the attacker), the attacker knowing its login name and the attacker being able to authenticate to the Dashboard via OAuth/OIDC. The attacker would then have had to forge a token creation API request on behalf of the other user and could have authenticated and finalized the token creation with their own OAuth/OIDC credentials. In the worst case, this would mean an attacker could have become Dashboard Administrator and been able to perform all administrative actions if the preexisting internal user had administrative privileges. In combination with a separate weakness, this could have further led to code execution on the host system running the Dashboard with the privileges of the OS-User running the Dashboard server.