| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The Smart Cookie Kit plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'comment' parameter in all versions up to, and including, 2.3.2 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The payload is specifically crafted to survive wp_kses on save by storing hostile characters inside allowed HTML elements, with the attribute-breaking double-quote smuggled inside a permitted <code> body and reconstructed into a <abbr title> attribute only at render time by the plugin's own output buffer; exploitation requires an administrator to approve the comment and subsequently view the affected public post. |
| The Live2DWebCanvas plugin for WordPress is vulnerable to Arbitrary File Upload in all versions up to, and including, 2.2.1 via the download_one_file function. This is due to missing file extension whitelist and MIME type validation in download_one_file() when writing files derived from attacker-controlled manifest entries to the web-served plugin directory. This makes it possible for unauthenticated attackers to upload files that may be executable, which makes remote code execution possible when the plugin's apiType setting is configured as custom-local (self-hosted model mode), a non-default option that requires a paid license and prints the REST nonce and one-time session tokens into every front-end page. |
| The Advanced Members for ACF plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 1.3.0 via the `acf[_amem_local_user_password]` parameter of the `[advanced-members-account-password]` shortcode form submission. This is due to a PHP operator-precedence bug in the `pre_update_value` function of `acf/fields/class-user-password.php` that assigns boolean `true` instead of the resolved user ID to `$user_id`, causing the `_can_edit()` authorization check to pass for any logged-in user via PHP loose equality, and causing `wp_update_user()` to cast `'ID' => true` to integer `1` — unconditionally targeting the primary administrator account. This makes it possible for authenticated attackers, with Subscriber-level access and above, to overwrite the password of user ID 1 (the site's primary administrator) with an attacker-chosen value, granting full administrative access to the site. The intended exclusion guard in `Account::process` that strips the password field before saving is defeated because `amem_save_all_fields()` re-reads the full field list from `amem()->submission` and silently overwrites the caller-supplied excluded fields array with an empty array, ensuring the password field is always processed. |
| The All-in-One Video Gallery – Video Player & Galleries for YouTube, Vimeo & Self-Hosted Videos plugin for WordPress is vulnerable to Stored DOM-Based Cross-Site Scripting via the 'custom_fields[].value.label (for key='track')' parameter in all versions up to, and including, 5.0.0 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. Exploitation requires the site's Player Library option to be configured as Plyr/Vidstack (aiovg_player_settings[player]='vidstack') rather than the Video.js default, as the DOM innerHTML sink exists only in the Plyr/Vidstack template path. |
| The AAA Autoload Optimizer plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'option_page' parameter in all versions up to, and including, 1.7.0 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. Exploitation requires the plugin's Option Tracking setting to be configured to 'Legacy' mode, and succeeds despite WordPress ultimately returning HTTP 403 to the low-privileged caller because the vulnerable 'all' filter fires before the capability check in wp-admin/options.php. |
| The WP Customer Area plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'display_name' parameter in all versions up to, and including, 8.4.0 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 WPSyncSheets For Contact Form 7 – CF7 Google Sheets Connector & Save to Database plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1.8.0 via the 'any non-system CF7 field (e.g., your-message)' parameter parameter. This is due to insufficient sanitization of CF7 submission field values before database storage and the absence of an allowed_classes restriction on maybe_unserialize() during admin retrieval. This makes it possible for unauthenticated attackers to execute code on the server. Successful exploitation of the remote code execution gadget chain requires that a Google Sheets access token be configured in the plugin (its primary advertised feature), as this triggers autoloading of the bundled Monolog 2.10.0 library whose classes form the exploitable gadget chain; however, the underlying PHP Object Injection occurs regardless. |
| The BuddyForms plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 2.10.5 via a form-type confusion attack through the `bf_post_type` parameter. This is due to the public frontend submission handler `buddyforms_form_response_no_ajax()` authorizing logged-out submissions based solely on the target form's `public_submit` flag while independently trusting the attacker-supplied `$_POST['bf_post_type']` to determine the post type of the newly created object — a cross-check introduced in 2.10.2 applies only to existing posts (`post_id != 0`) and is completely bypassed for new-object creation — combined with the `save_post` listener `buddyforms_edit_form_save_meta_box_data()` lacking both a `current_user_can()` capability check and a form-builder nonce, causing it to unconditionally persist attacker-supplied `$_POST['buddyforms_options']` for any newly inserted `buddyforms` CPT post. This makes it possible for unauthenticated attackers to insert a rogue BuddyForms form configuration with an attacker-controlled `new_user_role` value into the live global form registry, then submit a registration through that form to create a new WordPress account with administrator-level privileges and achieve full site takeover. Exploitation requires the WordPress site to have "Anyone can register" enabled and at least one public BuddyForms form attached to a page, both of which are standard BuddyForms deployment configurations. |
| The ELEX WordPress HelpDesk & Customer Ticketing System plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the factory_reset function in all versions up to, and including, 3.3.8 This makes it possible for unauthenticated attackers to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). This vulnerability is exploitable via a two-step chain: an unauthenticated attacker first stores an arbitrary ticket_attachment_path value by submitting a ticket through the nopriv eh_crm_new_ticket_post AJAX endpoint (whose nonce is publicly exposed via the [wsdesk_support] shortcode), then triggers the factory_reset routine via a GET request to wp-admin/admin.php?page=wsdesk_factory_reset, which is guarded only by is_admin() — a request-type check — rather than a capability check, causing unlink() to be called on the attacker-supplied path. |
| The Pubjet | پابجت plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 5.4.8. This is due to the `checkToken()` AJAX handler — registered under `wp_ajax_pubjet-check-token` — performing no capability check and no nonce verification before unconditionally writing the attacker-supplied `token` GET parameter directly into the site-wide `pubjet_settings` option via `pubjet_update_setting()`, prior to any remote validation. This makes it possible for authenticated attackers, with Subscriber-level access and above, to overwrite the plugin's stored REST API credential with an attacker-chosen value, immediately elevating their effective privileges to those of an authorized Pubjet API client and enabling them to invoke otherwise-restricted endpoints — `createReportage`, `updateReportage`, `deleteReportage`, `toggleCopyright`, and `createBacklink` — to create, modify, and delete arbitrary reportage posts and manipulate plugin state that Subscribers cannot normally access. The privilege escalation is self-reinforcing: because `RestApi::isTokenValid()` authenticates solely by comparing the incoming `Authorization` header against the value returned by `pubjet_token()`, which reads from the same option the unprotected handler writes to, the attacker-planted token is trusted as legitimate on all subsequent requests. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| A vulnerability has been identified in armeria versions prior to 1.43.0, where processing malformed Thrift messages can cause excessive memory allocation, potentially resulting in denial of service. |
| HTTP::Body versions before 1.24_02 for Perl parse the trailer in quadratic time.
Everything after the last chunk in the same call to add() is parsed with HTTP::Headers, which takes time quadratic in the number of fields of one name. For example, it takes several seconds to parse 16 KiB of "a:" lines.
A remote attackercan exhause the CPU with a single request.
HTTP::Body version 1.25 limits the size and number of lines in the trailer. |
| In Vulnerability-Lookup 5.5.1 up to but not including 6.4.1, a signed-in user could make the server allocate memory far out of proportion to their input through a webhook notification's payload template. Each placeholder's format specifier was passed unchanged to Python's string formatting, which builds the padded result before its size can be checked. A template of a few dozen bytes, such as {"text": "{title:>999999999}"}, therefore produced a string of about 1 GB when the notification form test-rendered it on save, and repeating such fields multiplied the cost. Templates that passed the save check could also repeat placeholders such as {text} thousands of times; the notification daemon rebuilt those on every webhook delivery. Deeply nested templates raised an unhandled recursion error (HTTP 500). An attacker needs only an account, which the default configuration lets anyone create after e-mail confirmation. They could exhaust the memory of web workers or the notification daemon, causing a denial of service. Version 6.4.1 caps every number in a format specifier at 256, limits a rendered template to 1,000,000 characters both on save and at delivery, and rejects templates nested deeper than 32 levels. |
| A improper handling of parameters vulnerability in Fortinet FortiWeb 7.6.0 through 7.6.3, FortiWeb 7.4.0 through 7.4.7, FortiWeb 7.2.0 through 7.2.10, FortiWeb 7.0.0 through 7.0.10 may allow an unauthenticated remote attacker with non-public information pertaining to the device and targeted user to gain admin privileges on the device via a specially crafted request. |
| The SMS Alert WordPress plugin before 4.0.3 does not bind the account whose password is being changed to the phone number that was actually verified during its OTP password reset, allowing unauthenticated attackers to set a new password on an arbitrary account, including an administrator, by verifying a one-time code sent to a phone number they control. |
| Allocation of Resources Without Limits or Throttling vulnerability in ninenines cowboy allows an unauthenticated remote attacker to exhaust connection process memory over HTTP/1.1.
Once a request has been received in full and its handler is still running, cowboy_http:parse/2 in src/cowboy_http.erl appends every further byte that arrives on the keep-alive connection to the connection buffer and returns to the receive loop without parsing it. The socket stays in active mode and no limit applies to this buffer: max_request_line_length, max_headers and the other parser limits only take effect once the handler returns and parsing resumes, and the only timer in this state is idle_timeout (default 60 seconds), which is reset on every received chunk. A client can therefore send an arbitrary amount of data on one connection for as long as the handler runs, and a few connections to an endpoint that holds requests open can drive the Erlang VM into out-of-memory conditions.
This issue affects cowboy: from 2.18.0 onward. |
| A flaw was found in Keycloak. The Dynamic Client Registration (DCR) endpoint does not properly validate authorization when processing the deprecated defaultRoles field. An authenticated attacker with client creation privileges or an Initial Access Token (IAT) can inject excessive roles into the realm's default roles configuration. This causes clients across the realm to generate bloated access tokens, resulting in performance and memory degradation that can lead to a Denial of Service (DoS). |
| A flaw was found in the login theme rendering component of Keycloak. The issue occurs because the security filter responsible for cleaning user input can be bypassed, allowing a realm administrator to store malicious scripts in display fields. This could result in unauthorized JavaScript execution in the browsers of users visiting the login page, potentially leading to data exposure or session interference. |
| A flaw was found in the OIDC Dynamic Client Registration (DCR) component of Keycloak. A bug in the response serialization causes the backchannel logout offline token revocation setting to be omitted from responses. When a client performs a standard update, this missing information causes the setting to be silently disabled. As a result, offline tokens may remain valid even after a user session is terminated via backchannel logout. |
