| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The Backup Migration plugin for WordPress is vulnerable to OS Command Injection in all versions up to, and including, 2.1.5.1 due to insufficient sanitization of the `file` POST parameter on the `restoreBackup()` AJAX handler. The handler applies `esc_attr()` — an HTML-context sanitizer that does not strip shell metacharacters — and concatenates the result, unquoted, into a `php-cli -f … bmi_restore <file> <remote>` command passed to `exec()`. This makes it possible for authenticated attackers, with Administrator-level access (or any user granted the plugin's `do_backups` capability) and above, to execute arbitrary OS commands as the web-server user, bypassing WordPress hardening constants such as `DISALLOW_FILE_EDIT` and `DISALLOW_FILE_MODS` that would otherwise prevent code execution from the admin UI. This is an incomplete fix of CVE-2023-7002, which patched the same pattern only in the `$_POST['url']` path of `handleQuickMigration()`; the equivalent mitigations (`rawurlencode()` + explicit shell-metachar replacement + double-quoting in `exec()`) were never applied to `$backupName`. |
| In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: fix race between xmit and reset
There is a race between reset and the transmit paths that can lead to
ibmvnic_xmit() accessing an scrq after it has been freed in the reset
path. It can result in a crash like:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000016189f8
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]
LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
Call Trace:
[c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)
[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
[c000000000c9cfcc] sch_direct_xmit+0xec/0x330
[c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0
[c000000000c00ad4] __dev_queue_xmit+0x394/0x730
[c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]
[c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]
[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
[c000000000c00ca4] __dev_queue_xmit+0x564/0x730
[c000000000cf97e0] neigh_hh_output+0xd0/0x180
[c000000000cfa69c] ip_finish_output2+0x31c/0x5c0
[c000000000cfd244] __ip_queue_xmit+0x194/0x4f0
[c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0
[c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0
[c000000000d2d984] tcp_retransmit_skb+0x34/0x130
[c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0
[c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330
[c000000000d317bc] tcp_write_timer+0x5c/0x200
[c000000000243270] call_timer_fn+0x50/0x1c0
[c000000000243704] __run_timers.part.0+0x324/0x460
[c000000000243894] run_timer_softirq+0x54/0xa0
[c000000000ea713c] __do_softirq+0x15c/0x3e0
[c000000000166258] __irq_exit_rcu+0x158/0x190
[c000000000166420] irq_exit+0x20/0x40
[c00000000002853c] timer_interrupt+0x14c/0x2b0
[c000000000009a00] decrementer_common_virt+0x210/0x220
--- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c
The immediate cause of the crash is the access of tx_scrq in the following
snippet during a reset, where the tx_scrq can be either NULL or an address
that will soon be invalid:
ibmvnic_xmit()
{
...
tx_scrq = adapter->tx_scrq[queue_num];
txq = netdev_get_tx_queue(netdev, queue_num);
ind_bufp = &tx_scrq->ind_buf;
if (test_bit(0, &adapter->resetting)) {
...
}
But beyond that, the call to ibmvnic_xmit() itself is not safe during a
reset and the reset path attempts to avoid this by stopping the queue in
ibmvnic_cleanup(). However just after the queue was stopped, an in-flight
ibmvnic_complete_tx() could have restarted the queue even as the reset is
progressing.
Since the queue was restarted we could get a call to ibmvnic_xmit() which
can then access the bad tx_scrq (or other fields).
We cannot however simply have ibmvnic_complete_tx() check the ->resetting
bit and skip starting the queue. This can race at the "back-end" of a good
reset which just restarted the queue but has not cleared the ->resetting
bit yet. If we skip restarting the queue due to ->resetting being true,
the queue would remain stopped indefinitely potentially leading to transmit
timeouts.
IOW ->resetting is too broad for this purpose. Instead use a new flag
that indicates whether or not the queues are active. Only the open/
reset paths control when the queues are active. ibmvnic_complete_tx()
and others wake up the queue only if the queue is marked active.
So we will have:
A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()
->resetting = true
->tx_queues_active = false
disable tx queues
...
->tx_queues_active = true
start tx queues
B. Tx interrupt in ibmvnic_complete_tx():
if (->tx_queues_active)
netif_wake_subqueue();
To ensure that ->tx_queues_active and state of the queues are consistent,
we need a lock which:
- must also be taken in the interrupt path (ibmvnic_complete_tx())
- shared across the multiple
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command
When control vq receives a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command
request from the driver, presently there is no validation against the
number of queue pairs to configure, or even if multiqueue had been
negotiated or not is unverified. This may lead to kernel panic due to
uninitialized resource for the queues were there any bogus request
sent down by untrusted driver. Tie up the loose ends there. |
| changedetection.io's /settings save handler builds an update dict from form.data['application'] and blind-merges it into the stored application settings via .update(). Because WTForms represents an unchecked checkbox as False rather than 'unchanged', and only the 'password' field is special-cased against this problem, a POST to /settings that omits the api_access_token_enabled field (e.g. a minimal scripted request) silently disables API key enforcement for the entire REST API, exposing the full watch list, history, and configuration to unauthenticated requests. |
| changedetection.io's /login route checks the submitted password against a single PBKDF2-HMAC-SHA256 hash with no per-IP or per-session rate limiting, failed-attempt counter, or lockout (no rate-limiting library is present in requirements.txt). Because the entire application is protected by one shared password with no per-user accounts, a successful brute-force guess grants full administrative access, including the ability to view/regenerate the API token. |
| audiobookshelf's authentication-exemption check (server/routers/Auth.js) matches unauthenticated-allowed GET routes against req.path via a regex requiring a literal /items/:id/cover or /authors/:id/image shape, where req.path retains %2F sequences URL-encoded. Express's router decodes the :id route parameter before handler code runs, so a %2F-encoded '../' sequence in :id (e.g. ..%2f..%2f..%2ftmp%2fpwned) passes the literal-path auth-exemption check while resolving to a real path-traversal payload once decoded. CacheManager.handleCoverCache then joins this decoded value into a cache file path and streams the result before any database-backed ownership check. This bypasses the fix applied for CVE-2025-25205 (which anchored the exemption regex and switched it to req.path) and results in unauthenticated arbitrary file read of any file matching the pattern *_<width>[x<height>].<ext> that the service account can read. |
| Mealie's AsyncSafeTransport SSRF guard (mealie/pkgs/safehttp/transport.py) resolves a target hostname once, checks the resolved IP against private-range rules, but then issues the actual outbound HTTP request using the original hostname, which the underlying async transport re-resolves independently. Because the validated IP is never pinned to the actual connection, a DNS-rebinding attacker (returning a public IP to the validation lookup and a private/metadata IP to the real connection) defeats the guard. This is reachable by any authenticated user via /api/recipes/create/url, /api/recipes/test-scrape-url, and /api/recipes/{slug}/image, and the scraper reflects fetched content back to the requester, allowing an authenticated user to read internal HTTP services and cloud-metadata endpoints. |
| Typemill's login endpoint (POST /tm/login, ControllerWebAuth::login()) performs no rate-limiting, failed-attempt counting, or account lockout when captcha is disabled, which is the default configuration. An unauthenticated attacker can send unlimited password-guessing requests against any account, including administrators, with no throttling. The only attempt-counting/lockout logic present in the same file protects an optional secondary email-authcode step and does not apply to the primary password check. |
| It was not possible to govern the rate at which the broker would respond to an echo flow, enabling an authenticated attacker to cause excessive resource usage and potential denial of service.
This issue affects Apache Qpid Broker-J: through 10.0.1.
Users are recommended to upgrade to version 10.1.0, which fixes the issue. |
| The Ajax Load More WordPress plugin before 8.0.1 does not properly sanitise and escape a parameter before using it in a SQL query, allowing unauthenticated attackers to perform time-based blind SQL injection and extract sensitive data from the database. |
| The Xpro Addons plugin for WordPress is vulnerable to unauthorized creation of data due to a missing capability check on the `get_menu_content_editor()` function in all versions up to, and including, 1.5.1. This makes it possible for authenticated attackers, with Subscriber-level access and above, to create arbitrary published posts of the `xpro_content` custom post type with attacker-controlled titles. The created posts are publicly queryable on the front-end, enabling content injection, SEO spam, and database pollution. |
| KubeSphere's cluster-controller reconciliation (pkg/utils/clusterclient/clusterclient.go, addCluster) processes every Cluster custom resource's connection configuration and immediately calls Discovery().ServerVersion() against the CRD-specified Kubernetes API endpoint, which is parsed only for URL syntax (url.Parse) with no allow/deny-list for loopback, RFC1918 private ranges, link-local, or cloud-metadata addresses (e.g. 169.254.169.254). A user able to create or update a Cluster CRD can force the controller-manager and apiserver pods to issue outbound requests to arbitrary internal or metadata endpoints. |
| A flaw was found in GStreamer's RealMedia demuxer in the gst-plugins-ugly package. When processing a RealMedia file containing a specially crafted FILEINFO metadata section, the demuxer parses variable-name and variable-value pairs using re_skip_pascal_string() without validating that offsets remain within the mapped buffer. Additionally, the element count controlling the parsing loop is read from attacker-controlled data without validation, which can cause an infinite loop. A crafted RealMedia file can cause the application to crash, hang, or potentially read limited adjacent memory contents. |
| A vulnerability was found in the GStreamer RealMedia demuxer (gst-plugins-ugly). When processing a RealMedia (.rm) file, the demuxer parses MDPR (media properties) chunks to configure audio streams. For audio stream header versions 4 and 5, the parser reads fields such as codec type, packet size, sample rate, channel count, and extra codec data length from fixed offsets within the chunk without first checking that the chunk contains enough data. If a malicious file provides an MDPR chunk that is too small to contain a complete audio stream header, the parser reads beyond the end of the buffer. This can cause the application to crash. In some cases, bytes read past the buffer boundary may be incorporated into stream metadata, which could result in limited information disclosure. |
| Cross-Site request forgery (CSRF) vulnerability in Melapress WP Activity Log and Melapress WP Activity Log Premium allows Cross Site Request Forgery.
This issue affects WP Activity Log: through 5.6.4; WP Activity Log Premium: through 5.6.4. |
| The ZTE Smart Life app contains an SQL injection vulnerability that allows attackers to execute UNION SELECT statements to query sensitive data in the feedback.db database across tables, including user accounts, phone numbers, feedback content, and local debug log paths, thereby enabling the theft of local privacy data. |
| 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. |
| 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. |
| 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). Any authenticated user can invoke getSetupData with an arbitrary userId to read that user's live TOTP secret, or disable2FA to strip another account's two-factor authentication entirely, fully defeating account-level 2FA protection. This is related to CVE-2026-15509, which covers a similar missing-authorization pattern in the JSON-RPC editUser/addUser role-assignment path in the same application; the TwoFA service methods addressed here are a distinct, independently fixable set of RPC endpoints. |
| An authenticated attacker could exceed the session flow control incoming window potentially leading to denial of service.
This issue affects Apache Qpid Proton-J: through 0.34.1.
Users are recommended to upgrade to version 0.35.0, which fixes the issue. |
