| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The NEX-Forms – Ultimate Forms Plugin for WordPress plugin for WordPress is vulnerable to Stored Cross-Site Scripting via '_name[]' Array Parameter in all versions up to, and including, 9.2.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 wp_kses() output filtering pass provides no mitigation because NEXForms_allowed_tags() explicitly permits <script>, <iframe src/srcdoc>, and JS event handlers such as onClick, onBlur, and onChange in its allow-list. |
| Insufficient policy enforcement in Passwords in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| @fastify/middie versions 9.1.0 through 9.3.2 decode the encoded slash %2F inside path parameter values before matching middleware paths, while Fastify's underlying router preserves the encoding during route lookup. The two layers disagree on the canonical request path, so the middleware fails to match a URL that the route handler does match. When middleware is used for authentication, authorization, rate limiting, or auditing on parameterized paths, an attacker can reach the protected handler by sending a single crafted URL with an encoded slash in the parameter position. The bypass is HTTP method agnostic and requires no authentication or special preconditions. Patches: upgrade to @fastify/middie 9.3.3. Workarounds: avoid parameterized middleware paths for security decisions, or enforce authentication at the route handler or via a Fastify hook that runs after the router has resolved the request. |
| In the Linux kernel, the following vulnerability has been resolved:
Revert "wireguard: device: enable threaded NAPI"
This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is
commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream.
We have had three independent production user reports in combination
with Cilium utilizing WireGuard as encryption underneath that k8s Pod
E/W traffic to certain peer nodes fully stalled. The situation appears
as follows:
- Occurs very rarely but at random times under heavy networking load.
- Once the issue triggers the decryption side stops working completely
for that WireGuard peer, other peers keep working fine. The stall
happens also for newly initiated connections towards that particular
WireGuard peer.
- Only the decryption side is affected, never the encryption side.
- Once it triggers, it never recovers and remains in this state,
the CPU/mem on that node looks normal, no leak, busy loop or crash.
- bpftrace on the affected system shows that wg_prev_queue_enqueue
fails, thus the MAX_QUEUED_PACKETS (1024 skbs!) for the peer's
rx_queue is reached.
- Also, bpftrace shows that wg_packet_rx_poll for that peer is never
called again after reaching this state for that peer. For other
peers wg_packet_rx_poll does get called normally.
- Commit db9ae3b ("wireguard: device: enable threaded NAPI")
switched WireGuard to threaded NAPI by default. The default has
not been changed for triggering the issue, neither did CPU
hotplugging occur (i.e. 5bd8de2 ("wireguard: queueing: always
return valid online CPU in wg_cpumask_choose_online()")).
- The issue has been observed with stable kernels of v5.15 as well as
v6.1. It was reported to us that v5.10 stable is working fine, and
no report on v6.6 stable either (somewhat related discussion in [0]
though).
- In the WireGuard driver the only material difference between v5.10
stable and v5.15 stable is the switch to threaded NAPI by default.
[0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/
Breakdown of the problem:
1) skbs arriving for decryption are enqueued to the peer->rx_queue in
wg_packet_consume_data via wg_queue_enqueue_per_device_and_peer.
2) The latter only moves the skb into the MPSC peer queue if it does
not surpass MAX_QUEUED_PACKETS (1024) which is kept track in an
atomic counter via wg_prev_queue_enqueue.
3) In case enqueueing was successful, the skb is also queued up
in the device queue, round-robin picks a next online CPU, and
schedules the decryption worker.
4) The wg_packet_decrypt_worker, once scheduled, picks these up
from the queue, decrypts the packets and once done calls into
wg_queue_enqueue_per_peer_rx.
5) The latter updates the state to PACKET_STATE_CRYPTED on success
and calls napi_schedule on the per peer->napi instance.
6) NAPI then polls via wg_packet_rx_poll. wg_prev_queue_peek checks
on the peer->rx_queue. It will wg_prev_queue_dequeue if the
queue->peeked skb was not cached yet, or just return the latter
otherwise. (wg_prev_queue_drop_peeked later clears the cache.)
7) From an ordering perspective, the peer->rx_queue has skbs in order
while the device queue with the per-CPU worker threads from a
global ordering PoV can finish the decryption and signal the skb
PACKET_STATE_CRYPTED out of order.
8) A situation can be observed that the first packet coming in will
be stuck waiting for the decryption worker to be scheduled for
a longer time when the system is under pressure.
9) While this is the case, the other CPUs in the meantime finish
decryption and call into napi_schedule.
10) Now in wg_packet_rx_poll it picks up the first in-order skb
from the peer->rx_queue and sees that its state is still
PACKET_STATE_UNCRYPTED. The NAPI poll routine then exits e
---truncated--- |
| @fastify/middie versions 9.1.0 through 9.3.2 fail to guard the URL normalization step used by the standalone engine when incoming request paths contain malformed percent-encoded sequences. Inputs such as an incomplete percent escape or a truncated multibyte sequence cause the underlying decoder to throw synchronously, and the exception escapes the middie normalize step and terminates the Node.js process. The bypass affects applications that call middie.run directly on the standalone engine API, causing an immediate denial of service for all connected clients until restart. Applications using the Fastify plugin path are not affected because Fastifys error handler catches the exception. Patches: upgrade to @fastify/middie 9.3.3. Workarounds: migrate from the standalone engine API to the Fastify plugin path, where the framework error handler catches the exception. |
| Uninitialized Use in Skia in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium) |
| Out of bounds read in ANGLE in Google Chrome on Mac prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium) |
| MCO does not correctly validate types of uploaded files. File upload validation functionality relies only on client-side checks, which can be bypassed. An authorized, low-privileged attacker can upload files with arbitrary types to the server.
Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions. |
| MCO does not properly enforce authorization checks in the /customer/servlet/mco/webapi/admin-view-hierarchy/get-acl-tree-structure endpoint. An authenticated, low-privileged user can retrieve administrator access control structures without proper authorization checks.
This may expose sensitive permission mappings and internal configuration details.
Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions. |
| MCO is vulnerable to Account Denial of Service due to improper implementation of password reset functionality. Each password reset request invalidates previously set password as well as previously issued temporary passwords, furthermore, password resets are not limited in any way. An attacker who provides victim's email and answer to their security question, can successfully initiate the reset process and continuously invalidate credentials, effectively locking the victim out of their account. Answering security questions has a limited number of tries which lowers the risk of this vulnerability.
Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions. |
| MCO is vulnerable to an Insecure Direct Object Reference (IDOR) vulnerability in the /customer/servlet/mco/webapi/trading-document/fetchPdfStatement endpoint. The application does not properly validate whether an authenticated user is authorized to access a requested document, allowing direct retrieval based on a user-supplied identifier.
An attacker can access trading documents belonging to other users by providing a valid document ID. Although exploitation requires guessing the identifier, predictable ID patterns enable feasible enumeration, leading to unauthorized disclosure of sensitive information.
Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions. |
| MCO does not properly enforce authorization checks in the /customer/servlet/mco/webapi/profile-sections/group-membership endpoint. An authenticated user can modify their group membership without proper authorization checks, allowing privilege escalation.
An attacker can add themselves to arbitrary groups by supplying a valid group ID, which can be obtained via other application functionalities (e.g. /customer/servlet/mco/webapi/group/picker/groups), provided he has necessary permissions, or potentially inferred through brute-force techniques.
Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions. |
| Incorrect security UI in Chrome for iOS in Google Chrome on iOS prior to 150.0.7871.47 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low) |
| Inappropriate implementation in GPU in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low) |
| Uninitialized Use in GamepadAPI in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low) |
| An attacker with access via network to the Regesta Smart HD-PLC of the provider Teldat (in this case, registration action IS required) who has the vulnerable software could, introduce arbitrary JavaScript by injecting a Cross-site Scripting (XSS) payload into the 'Hostname' field of the configuration file resulting in a XSS in the path /upgrade/query.php?cmd=p+3%3Bversion. This issue affects Regesta Smart HD-PLC - TLDPH16D2:
11.02.05.10.02. |
| An attacker with access via network to the Regesta Smart HD-PLC of the provider Teldat (in this case, NO registration action is required) who has the vulnerable software could, with a Slow Loris attack, cause Denial of Service (DoS) on the web interface of the device. This issue affects Regesta Smart HD-PLC - TLDPH16D2:
11.02.05.10.02. |
| An attacker with access via network to the Regesta Smart HD-PLC of the provider Teldat (in this case, NO registration action is required) who has the vulnerable software could obtain privilege information by using the command Version via the path: /upgrade/query.php?cmd=p+3&3Bversion resulting in a information disclosure. This issue affects Regesta Smart HD-PLC - TLDPH16D2:
11.02.05.10.02. |
| ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.36 in Java applications, allows an attacker to execute arbitrary code circumventing existing protections against CVE-2025-11226 by compromising an existing logback configuration file or by injecting an environment variable before program execution.
A successful attack requires the presence of Janino library to be present on the user's class path. In addition, the attacker must have write access to a
configuration file. Alternatively, the attacker could inject a malicious
environment variable pointing to a malicious configuration file. In both
cases, the attack requires existing privilege.
Please note that in logack version 1.5.37 conditional processing using Janino was removed. |
| The GiveWP – Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'block_id' (and other) shortcode attributes of the 'givewp_campaign_comments' shortcode in versions up to, and including, 4.16.0. This is due to insufficient input sanitization and output escaping on user supplied attributes in CampaignCommentsShortcode::parseAttributes() and BlockRenderController::render(), where the blockId value is interpolated directly into a single-quoted HTML attribute without esc_attr(). This makes it possible for authenticated attackers, with author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. |
