The Search Atlas SEO WordPress plugin before 2.6.12 does not perform a capability or nonce check in one of its AJAX handlers, allowing any authenticated user such as a Subscriber to invoke the site's Google Indexing API integration, submitting or removing the site's URLs from Google's index and consuming its indexing quota.

The MotoPress Hotel Booking WordPress plugin before 6.0.4 does not perform a capability check before returning a booking's full customer details in one of its AJAX actions, allowing any authenticated user with a low-privileged account (Subscriber and above) to read the personal data, including name, email, phone, and address, of any customer.

The Tutor LMS WordPress plugin before 4.0.0 does not properly verify that a user has access to the course a Q&A thread belongs to before returning or writing to that thread, allowing authenticated users with subscriber-level access and above who can access any single course to read the Q&A threads of other courses and to inject replies into them.

The LifterLMS WordPress plugin before 10.0.10 does not perform a capability check in one of its select2 query AJAX handlers, only verifying that the user is logged in, allowing any authenticated user with subscriber-level access to read the titles of internal post types such as coupon codes by supplying the post type.

The Easy Appointments WordPress plugin through 3.12.26 does not require a sufficient capability on one of its appointment-listing REST endpoints, restricting it only to a capability that every authenticated user holds, allowing users with subscriber-level access to read all bookings on the site, including customer names, schedules, and statuses.

The Easy Appointments WordPress plugin through 3.12.26 does not verify ownership or capability when returning stored customer details, allowing users with subscriber-level access to read any customer's personal information by iterating an identifier.

The Frontend Admin by DynamiApps WordPress plugin before 3.29.7 does not perform capability checks on its taxonomy term creation, modification, and deletion operations, allowing authenticated users with low privileges (such as Subscribers) to create, rename, and delete arbitrary taxonomy terms.

The BuddyPress plugin for WordPress is vulnerable to Deserialization of Untrusted Data in all versions up to, and including, 14.5.0 This is due to the `bp_unserialize_profile_field()` function using `@unserialize()` without the `allowed_classes` parameter on user-controlled XProfile field data. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary PHP objects via XProfile textbox fields, which could lead to remote code execution if a suitable POP chain is available in the WordPress environment.

The FleekDash V2 plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 2.6.2.2. 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 overwrite the email address and password of any WordPress user, including administrators, enabling full account takeover and complete site compromise. The public /wp-json/fleekdash/v1/register endpoint auto-provisions a Subscriber-role account and returns a valid REST nonce regardless of the site's users_can_register setting, enabling unauthenticated attackers to self-provision the required credentials and nonce in a single prior request.

In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete() exec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is "harmless" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand); if (!sh) WARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") added a temporary workaround for that in 2010 which surv ---truncated---

The Extra Checkout Options (addon for Extra Product Options & Add-Ons for WooCommerce) plugin for WordPress is vulnerable to Arbitrary File Upload in all versions up to, and including, 2.3.2. This is due to missing authorization and nonce validation in the eco_save_settings() function, which allows low-privileged authenticated users to modify the tc_eco_custom_file_types upload allowlist setting, combined with insufficient authorization on the wc_eco_upload_file AJAX action. This makes it possible for authenticated attackers, with Subscriber-level access and above, to allow PHP uploads, upload a PHP file using the frontend upload nonce exposed on cart and checkout pages, and achieve remote code execution. NOTE: This vulnerability was partially fixed in version 2.3.2.

The Booking System Trafft plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the `bookingWebsiteUrl` setting in all versions up to, and including, 1.0.17 due to a missing capability check on the `set_options` AJAX action when the plugin is operating in agency mode. The `trafftSetOptions()` handler verifies a nonce that is exposed to any authenticated user (it is printed inline on every admin page, including profile.php) but performs no capability check before calling `update_option('trafft_option', ['bookingWebsiteUrl' => ...])`. This setting is then used by `trafftAdminAssets()` to enqueue `<bookingWebsiteUrl>/embed.js` as a script on every front-end page that renders the booking shortcode. This makes it possible for authenticated attackers, with Subscriber-level access and above, to point the embed-script URL at an attacker-controlled origin and execute arbitrary JavaScript in the browser of every site visitor (including admins).

The Easy Appointments WordPress plugin through 3.12.26 does not verify that the appointment targeted by its customer-data update action belongs to the current user; the action only checks a shared nonce that any authenticated user can obtain from their own appointment's edit form. A subscriber-level user with an appointment of their own can therefore reuse that nonce to overwrite the customer metadata (email, name, phone, description) of another user's appointment. Because the Easy Appointments WordPress plugin through 3.12.26 then treats that metadata as the appointment's contact data, a subsequent administrator status change with customer notifications enabled delivers the victim's appointment notification to the attacker-controlled email address.

The Survey Form Block plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the get_all_data() function in all versions up to, and including, 1.0.1. This makes it possible for authenticated attackers, with Subscriber-level access and above, to export all survey submission data and column metadata.

When applying replicated changes for a row that is missing one or more columns, pglogical evaluates the affected table's default expressions on the subscriber. Because the apply worker runs at a privilege level equivalent to a PostgreSQL superuser in default installations, any function invoked by such a default expression also runs at that privilege. A party acting as the publisher can use this path to cause functions to be executed on the subscriber as superuser, escalating from a role permitted to use pglogical to full superuser. This is a second, independent path to the same superuser escalation tracked under CVE-2026-50736 (the pglogical queue issue). To exploit the issue an attacker must be able to direct a subscription at an endpoint they control. In default installations this requires privileges normally reserved for a superuser, so the issue is most relevant to managed deployments where the ability to create subscriptions has been delegated to non-superuser roles.

The pglogical queue mechanism, used to convey out-of-band commands such as replicated DDL from a publisher to a subscriber, executes message payloads on the subscriber at the privilege level of the apply worker, which is equivalent to a PostgreSQL superuser in default installations. A party acting as the publisher can send crafted queue messages that cause arbitrary SQL to be executed on the subscriber as superuser, escalating from a role permitted to use pglogical to full superuser and breaking the isolation between tenants in shared deployments. To exploit the issue an attacker must be able to direct a subscription at an endpoint they control. In default installations this requires privileges normally reserved for a superuser, so the issue is most relevant to managed deployments where the ability to create subscriptions has been delegated to non-superuser roles.

pglogical's apply worker does not sufficiently validate the length of certain fields in incoming replication protocol messages before copying them, resulting in an out-of-bounds read. A party acting as the publisher for a subscription, for example a non-PostgreSQL endpoint that speaks the pglogical replication protocol, can return crafted messages that cause the subscriber's apply worker to read beyond the bounds of an allocated buffer, disclosing adjacent process memory or crashing the worker. To exploit the issue an attacker must be able to direct a subscription at an endpoint they control. In default installations this requires privileges normally reserved for a superuser, so the issue is most relevant to managed deployments where the ability to create subscriptions has been delegated to non-superuser roles.

The WP Password Policy plugin for WordPress is vulnerable to Privilege Escalation in all versions up to and including 3.7.1. This is due to missing authorization checks and nonce verification in the `get_user()` function of the `Module_Password_Hint` class, which unconditionally calls `WP_User::set_role()` with the attacker-supplied `role` parameter on any account resolved via `$_POST['user_login']`, without confirming the requesting user holds the capability to assign roles. This makes it possible for authenticated attackers, with subscriber-level access and above, to escalate their own privileges to Administrator by submitting a crafted POST request — with `action` set to `createuser` and `role` set to `administrator` — to the password-reset form endpoint. The vulnerable code path is reachable via the `password_hint` filter hooked during the WordPress password-reset form render, meaning an attacker need only possess a valid password-reset cookie to reach the sink.

The Plugin Organizer plugin for WordPress is vulnerable to SQL Injection via the 'PO_plugin_path' parameter in versions up to, and including, 10.2.4. This is due to insufficient escaping on the user-supplied parameter in the perform_plugin_search() function, where esc_sql() output is passed as the replacement string to preg_replace(), which collapses backslash escapes and defeats the quoting protection; additionally, the AJAX handler lacks both nonce verification and capability checks. This makes it possible for authenticated attackers, with subscriber-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

The Paid Memberships Pro – Content Restriction, User Registration, & Paid Subscriptions plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Readonly User Field via [pmpro_member_profile_edit] Shortcode in all versions up to, and including, 3.8.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Uncanny Automator – Easy Automation, Integration, Webhooks & Workflow Builder plugin for WordPress is vulnerable to Missing Authorization in versions up to, and including, 7.3.2 via the automator_google_contacts_fetch_labels, automator_mautic_segment_fetch, automator_mautic_tags_fetch, and automator_mautic_render_contact_fields AJAX actions due to a missing capability check and missing nonce verification in the corresponding handlers (ajax_fetch_labels, segments_fetch, tags_fetch, and render_contact_fields). This makes it possible for authenticated attackers, with Subscriber-level access and above, to enumerate sensitive Google Contacts groups/labels and Mautic segments, tags, and contact-field definitions retrieved via integration credentials configured by an administrator, and to consume third-party API quota.

The Eazy Plugin Manager – Powerful Plugin Management Solution for WordPress plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 4.4.1. This is due to insufficient authorization on the `wp_ajax_pos_get_option` AJAX handler, which verifies only a nonce that is localized to every logged-in admin-area user via `admin_enqueue_scripts` — without any capability check — before returning the value of any arbitrary WordPress option via `get_option()`, combined with the `admin_login_endpoint_handler` REST endpoint (`GET /wp-json/epm/v1/admin/login`) being registered as publicly accessible and authenticating callers solely by a whirlpool hash of values stored in those same options. This makes it possible for authenticated attackers, with Subscriber-level access and above, to read the `site_url`, `connection_key`, and `remote_user_id` values stored in the `eazywp_connecting_info` and `eazywp_connection` options, compute the required `auth_key`, call the `admin/login` REST endpoint to obtain Administrator authentication cookies, and fully take over the site. Exploitation requires the plugin's remote connection feature to have been configured, as the `eazywp_connecting_info` and `eazywp_connection` options must be populated with valid credentials.