CVE Database

In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: num_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); io_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = <N> here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.

In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG.

** UNSUPPORTED WHEN ASSIGNED ** Stack-based Buffer Overflow vulnerability in Apache Lucy. This issue affects Apache Lucy: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

** UNSUPPORTED WHEN ASSIGNED ** Memory Allocation with Excessive Size Value vulnerability in Apache Lucy. This issue affects Apache Lucy: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

** UNSUPPORTED WHEN ASSIGNED ** Deserialization of Untrusted Data vulnerability in Apache Lucy. This issue affects Apache Lucy: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

** UNSUPPORTED WHEN ASSIGNED ** Uncontrolled Recursion vulnerability in Apache Lucy. This issue affects Apache Lucy: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

The Askeet plugin for WordPress is vulnerable to SQL Injection via the 'sql_query' parameter in multiple AJAX actions (askeet_execute_sql_query, askeet_export_all_results) in all versions up to, and including, 3.0. This is due to the askeet_is_safe_query() filter being bypassable using MySQL conditional comments (e.g., /*!UNION*/). The filter strips regular block comments before checking for forbidden SQL keywords, but MySQL interprets conditional comments as executable code. This makes it possible for authenticated attackers, with Administrator-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 Multi Uploader for Gravity Forms plugin for WordPress is vulnerable to unauthorized arbitrary media deletion in all versions up to, and including, 1.1.8. This is due to missing capability checks in the `plupload_ajax_delete_file()` function, which is registered via `wp_ajax_nopriv_gfmu_delete_file`. The nonce intended for CSRF protection is exposed on any public-facing page containing a multi-uploader form field via the `GFMU_options` JavaScript object. This makes it possible for unauthenticated attackers to permanently delete any WordPress media attachment by supplying its attachment ID, potentially leading to complete media library destruction.

The Contact Form 7 – Dynamic Text Extension plugin for WordPress is vulnerable to Stored Cross-Site Scripting in all versions up to, and including, 5.0.5. This is due to insufficient output escaping on form shortcode keys displayed in the admin "Scan Forms for Post Meta and User Data Keys" page. This makes it possible for authenticated attackers, with Editor-level access and above, to inject arbitrary web scripts that execute when an Administrator runs the scan feature.

The Super Progressive Web Apps plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the `superpwa_settings[offline_message_txt]` setting in all versions up to, and including, 2.2.43. This is due to insufficient input sanitization and output escaping. The offline message value is stored without sanitization, passed to the frontend via `wp_localize_script()` without escaping, and rendered using `innerHTML` in the JavaScript snackbar component. This makes it possible for authenticated attackers, with Administrator-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user triggers the offline snackbar.

When API audit logging is enabled, the middleware reads the entire HTTP request body into memory without enforcing a size limit on login endpoints. Because the audit middleware is positioned earlier in the handler chain than Rancher's APIBodyLimitingHandler, the body-size cap (default 1 MiB) is bypassed for requests that pass through the audit copyReqBody path. An unauthenticated attacker can send arbitrarily large request bodies to the public login endpoints, causing the Rancher Manager server process to allocate memory proportional to the supplied body size. With just a few concurrent connections, this can exhaust available memory and terminate the Rancher Manager plane process, making the Rancher API and UI unavailable and interrupting management of all downstream clusters.

The endpoint /v3/import/{token}_{clusterId}.yaml retrieves the cluster object before validating the token. When a valid cluster ID references a cluster that has private registry secrets configured, a nil pointer dereference in pkg/systemtemplate/private_registry.go causes the request to return HTTP 502 Bad Gateway. For cluster IDs that do not exist, the endpoint returns HTTP 200. This observable difference in response codes constitutes a reliable enumeration oracle.

Rancher issues long-lived registration tokens to authenticate nodes and agents joining a downstream cluster. These tokens were stored and exposed in plaintext with no expiration, so a malicious user could obtain one either through the Rancher API, etcd, stored automation, or direct file access on a node, and could use it at any time to register a rogue node into the cluster.

A denial-of-service vulnerability was identified in multiple TLS listeners in Rancher. Both the cattle-cluster-agent component running in downstream clusters and the Rancher server itself use the dynamiclistener library to serve TLS traffic. Without an effective CN filter configured, dynamiclistener automatically appended to each serving certificate any hostname presented via Server Name Indication (SNI) in incoming TLS requests. An unauthenticated attacker with network access within the affected cluster could send a large number of TLS requests with distinct hostnames, causing the serving certificate to accumulate an unbounded number of Subject Alternative Names (SANs). Eventually, the certificate grows large enough that TLS handshakes fail with an excessive message size error, causing a denial of service on the affected listeners.

The pocketflow-coding-agent cookbook example in The-Pocket/PocketFlow implements a helper as a thin os.path.join(workdir, p) wrapper with no canonicalization or containment check, used unguarded by the ReadFile, ListFiles, PatchRead, and PatchApply file-access tools. Severity reflects that this affects an illustrative cookbook example rather than a core library API; applications that copy this pattern into production are affected.

Crater isolates data per company_id, and its Invoice/Estimate/Payment/Expense policies enforce both a Bouncer ability check and ->hasCompany(->company_id). CustomerPolicy's view/update/delete methods omit the company-ownership check entirely, checking only the blanket ability. Route-model-bound customer lookups and the bulk Customer::deleteCustomers method are similarly unscoped (self::find with no company filter).

Leantime through 3.6.2 exposes the JSON-RPC methods leantime.rpc.TwoFA.TwoFA.getSetupData, saveSecret, verifyAndEnable, and disable2FA, which act on a caller-supplied userId parameter with no ownership check, session pinning, or permission-attribute gate (unlike other RPC-exposed methods in the same dispatcher).

Pluck CMS through 4.7.21 restricts dangerous file uploads in its admin file-management feature using a fixed blacklist in data/inc/files.php ('.php','php3','php4','php5','php6','php7','phtml','.phtm','.pht','.ph3','.ph4','.ph5','.asp','.cgi','.phar'), checked against the last 4-5 characters of the filename.

The Easy Post Submission plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the `create_post()` function in all versions up to, and including, 2.3.0. This is due to the `rbsm_submit_post` AJAX action being registered for unauthenticated users via `wp_ajax_nopriv_rbsm_submit_post` without any authorization checks when a `postId` parameter is supplied. This makes it possible for unauthenticated attackers to modify the title, content, excerpt, categories, and tags of arbitrary posts, as well as change the post status to draft (effectively unpublishing them) via the 'postId' parameter.

The TableOn – WordPress Posts Table Filterable plugin for WordPress is vulnerable to blind SQL Injection via the `filter_data[comment_count]` parameter of the public `tableon_get_table_data` AJAX action in all versions up to, and including, 1.0.5.1. This is due to insufficient escaping on the user-supplied parameter and lack of sufficient preparation on the existing SQL query — the value is split on `:` and both halves are interpolated directly into a `posts_where` SQL clause without `intval()` casting or `$wpdb->prepare()`. This makes it possible for unauthenticated attackers to append additional SQL queries into the already-existing query that can be used to extract sensitive information from the database (researcher demonstrated extraction of database(), wp_users.user_login, and wp_users.user_pass).

The Seraphinite Accelerator plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the 'seraph_accel_prep' parameter in versions up to, and including, 2.29.15. This is due to the CacheExtractPreparePageParams() function using PHP's loose inequality operator (!=) to compare the expected HMAC string against the JSON-decoded 'nonce' value — supplying the JSON boolean true causes any non-empty HMAC string to compare as loosely equal, bypassing the signature check — combined with insufficient output escaping in the _CbContentFinishSkip() function, which concatenates the attacker-controlled 'selfTest' field directly into the HTML response body. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a specially crafted link.

The Translate Multilingual sites – TranslatePress plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the 's' parameter in versions up to, and including, 3.2.5. This is due to the translate_page() function unconditionally replacing the plugin's internal #!trpst# and #!trpen# marker tokens with literal angle brackets across the entire HTML page output after WordPress has already sanitized and escaped user input — allowing the attacker to bypass WordPress's normal HTML escaping by using these tokens, which are not HTML special characters, in the search query. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a specially crafted link.

The User Access Manager plugin for WordPress is vulnerable to Second-Order SQL Injection via the 'id' parameter of the wp_ajax_save-attachment-compat AJAX action in versions up to, and including, 2.3.12. This is due to insufficient validation on the objectId value stored in the saveAjaxAttachmentData() function and subsequent unparameterized concatenation in the addQueryExcludedPostFilter() function — the stored value is later retrieved from the database and used as an array key, then directly imploded into a SQL NOT IN() clause without integer casting or prepared statements. 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 Page and Post Restriction plugin for WordPress is vulnerable to Sensitive Information Exposure in versions up to and including 1.4.0 via the WordPress core REST endpoints /wp-json/wp/v2/pages, /wp-json/wp/v2/pages/<id>, /wp-json/wp/v2/posts, and /wp-json/wp/v2/posts/<id>. This is due to the plugin's REST guards — papr_restrict_page_post_rest_api() and the the_posts filter registered by papr_filter_posts() — sourcing their restricted-ID list exclusively from papr_get_restricted_posts_id(), which only reads the per-page metabox options papr_allowed_redirect_for_pages and papr_allowed_redirect_for_posts and never consults the two global toggles papr_access_for_only_loggedin and papr_access_for_only_loggedin_posts that the plugin's own UI describes as 'Make all Pages Private' / 'Make all Posts Private'. This makes it possible for unauthenticated attackers to read the full rendered content of every published page and post on sites configured with the documented global toggles, bypassing the security boundary enforced on the frontend by papr_restrict_logged_in_users().

The WP Post Author – Author Box, Multiple Authors, Guest Authors & Custom Avatars plugin for WordPress is vulnerable to generic SQL Injection via the 'wpma_metabox_authors_list' parameter in all versions up to, and including, 3.9.1 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with author-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. Exploitation is a two-step chain: an attacker first saves a crafted guest-author token via the wpma_metabox_authors_list parameter during post creation or editing, then triggers the injection when any admin user loads the post list screen at /wp-admin/edit.php, causing the injected SQL result to be rendered in the Authors column.

The WP TripAdvisor Review Slider plugin for WordPress is vulnerable to generic SQL Injection via 'curselrevs[]' Parameter in all versions up to, and including, 14.3 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with administrator-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 JoomSport – for Sports: Team & League, Football, Hockey & more plugin for WordPress is vulnerable to time-based SQL Injection via the 'order' parameter in all versions up to, and including, 5.7.9 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with administrator-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 affected admin page lacks nonce or CSRF protection on the GET request, meaning an unauthenticated attacker could exploit this vulnerability by tricking an authenticated administrator into issuing a crafted request. Additionally, the vulnerability is only triggered when the 'orderby' parameter is also present and non-empty alongside the 'order' parameter.

The Groundhogg — CRM, Newsletters, and Marketing Automation plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.5.2 via the GET /wp-json/gh/v4/contacts/<id> REST endpoint. The endpoint's permission callback checks only the role-level view_contacts capability and read_single() returns the full contact record by sequential integer ID without the object-level view_contact ownership check applied elsewhere in the codebase. This makes it possible for authenticated attackers holding view_contacts but not view_others_contacts — notably Groundhogg's built-in Sales Rep role, designed to see only its own contacts — to read any contact record on the site, including PII, contact meta, owner IDs, the admin edit URL, and (for contacts linked to a WordPress user) that user's full capability set.

In OpenStack Ironic through 38.0.0, a project reader that makes a crafted request to Ironic can return Portgroups assigned to Nodes owned or leased by another project.

HashBrown CMS through 1.4.6 contains an OS Command Injection vulnerability (CWE-78) in the Git deployer component. GitDeployer.pullRepo in src/Server/Entity/Deployer/GitDeployer.js executes AppService.exec, interpolating the configured branch value directly into a shell command with no escaping.