CVE-2026-119747
The GetPaid plugin for WordPress before 2.8.63 contains an incorrect authorization vulnerability where the check_post_permissions() method i
CVSS
7.1
Alto
EPSS
—
KEV
—
Exploit Today
—
0-100
Publicado: 4 nov 2026 · Última mod.: 4 nov 2026 · CWE-863
Sin historial EPSS suficiente todavía.
The GetPaid plugin for WordPress before 2.8.63 contains an incorrect authorization vulnerability where the check_post_permissions() method in includes/api/class-getpaid-rest-posts-controller.php maps REST operations to generic WordPress post capabilities instead of enforcing the plugin's manage_invoicing permission. Authenticated users with lower-privileged roles such as Editor or Author can exploit this flaw to list other users' invoices, mark pending invoices as paid without recording payment transactions, or create published items and new invoices through the REST API.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-118516——
———The Symfony Routing components CompiledUrlMatcher and UrlMatcher interpret the host and path information differently, allowing path-based authorization rules to be bypassed in Symfony versions prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11.
For routes that define a host, CompiledUrlMatcher matches the string $host.'.'.$pathinfo against the host regular expression followed by the path regular expression, while UrlMatcher matches the host and the path separately. A host placeholder can therefore match /, and consume the beginning of the path, so the request is routed to a controller, while UrlMatcher would find no route. Rules that look at the path, such as access_control entries and firewall patterns, are evaluated against the actual request path, so they do not apply while the controller of the route runs, potentially allowing an unauthenticated request to reach a protected controller. For example, with the route /admin/report/{id}, the host app.{domain} and the rule access_control: [{ path: ^/admin, roles: ROLE_ADMIN }], an anonymous request for /admin/report/1 is sent to the login page. A request with the Host header app and path /x./admin/report/1 instead reaches the controller, with domain="/x". With the required domain: .+, the real hostname works: app.example.com and /x./admin/report/1 match with domain="example.com./x".
Applications are affected if they have routes with host placeholders protected by path-based rules. With the default requirement, the Host header must be the host of the route without its last labels, such as app: framework.trusted_hosts blocks that, while a web server that only serves known names may not, for instance, Nginx passing the raw Host header to FastCGI for a request line that carries an absolute URI. If the requirement accepts /, such as .+, a real hostname works, and trusted_hosts does not help.7hCVE-2026-100252——
——0Improper Authorization vulnerability in Apache ZooKeeper.
When SASL authentication is enabled on the client port, the server's SASL callback handler grants every authorization identity (authzid) that a client requests, without checking it against the principal the client authenticated as. The server then tries to replace the requested identity with a canonical form of the authenticated principal, derived from the zookeeper.security.auth_to_local rules. If no rule applies to the principal, canonicalization fails and the error is only logged. The client-requested authzid then becomes the session's SASL identity for all ACL checks.
An authenticated client whose principal is not covered by the auth_to_local rules can therefore claim any SASL identity. With the default rules, this includes any Kerberos principal from a realm other than the server's default realm, such as a principal from a cross-realm trusted realm. The client then gets the permissions granted to that identity in sasl ACLs. If the requested identity matches a configured zookeeper.superUser, it gets superuser access to the whole data tree.
Users are recommended to upgrade to version 3.8.8 or 3.9.7, which fixes the issue.4hCVE-2026-1205548.8 ALT—
——0The Import and export users and customers plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 2.5.11 This is due to a non-atomic multi-option write sequence in the `ACUI_Cron::save_settings()` function, which persists `acui_cron_activated`, `acui_cron_configured_by`, `acui_cron_user_id`, and `acui_cron_path_to_file` before reaching the authorization gate that calls `wp_die()` when a non-promoter submits a role. This makes it possible for authenticated attackers holding a custom delegated role with `create_users` but without `promote_users` or `edit_users` to escalate their privileges to Administrator, provided a prior administrator cron-tab save exists and no successful save intervenes before the next unattended cron tick processes the attacker's repointed CSV file.10hCVE-2026-921918.8 ALT—
——0Quest Foglight for Databases runScript Incorrect Authorization Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Quest Foglight for Databases. Authentication is required to exploit this vulnerability.
The specific flaw exists within the runScript function. The issue results from incorrect authorization prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of SYSTEM. Was ZDI-CAN-29192.20hCVE-2026-1166674.2 MED—
——0Tanium addressed an improper access controls vulnerability in Discover.21hCVE-2026-1166643.1 BAJ—
——0Tanium addressed an improper access controls vulnerability in Discover.21h