Search vulnerabilities

Results 34,351

CVE-2026-124814

Ultimate Addons for Elementor Forms < 1.0.8 - Unauthenticated Arbitrary File Upload via 'type' Parameter

The Ultimate Addons for Elementor Forms WordPress plugin before 1.0.8 does not properly validate the extension of uploaded files in its bundled file upload field, allowing unauthenticated users to upload arbitrary files such as PHP scripts and achieve remote code execution.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
CVE-2026-126859

chromium-browser: Link following in FileSystem

Link following in FileSystem in Google Chrome prior to 157.0.8103.78 allowed a remote attacker leveraging social engineering to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)

CVSS 3.1 · 9.6 Critical EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-110003

Azul Payara Administration REST Interface Authentication Bypass via X-GlassFish-authToken Header Leading to Remote Code Execution

A vulnerability in the administration REST interface of Azul Payara allows a remote, unauthenticated attacker to bypass secure-admin remote-access restrictions by supplying an arbitrary value in the X-GlassFish-authToken HTTP header. The header's presence waives the remote-rejection check before the token is validated, and an invalid token falls through to password-based authentication, which succeeds without credentials on default domains configured with an empty administrative password. Successful exploitation grants execution of arbitrary administrative commands, equivalent to complete compromise of the server.

CVSS 4.0 · 9.3 Critical EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-121370

Security Advisory 0224

On affected platforms running Arista EOS with Precision Time Protocol (PTP) configured, an unauthenticated attacker with network access to a PTP-enabled port can create a denial of service (DoS) condition by sending traffic to the system.

CVSS 4.0 · 9.2 Critical EPSS < 1% KEV · Not listed
Vendors
Products
Eos
CVE-2026-56712

Replicate Cog through 0.23.1 SSRF via cog.File and cog.Path URL Inputs

Replicate Cog through 0.23.1 contains a server-side request forgery vulnerability that allows attackers to cause the Cog process to make server-side HTTP requests by submitting prediction inputs with attacker-controlled URLs that are not validated against the resolved destination host or IP before fetching. Attackers can supply malicious URLs or exploit HTTP redirects in cog.File and cog.Path predictor inputs to force requests to internal addresses, potentially exposing sensitive internal services or credentials.

CVSS 4.0 · 7.8 High EPSS < 1% KEV · Not listed
Vendors
Products
Cog
CVE-2026-63984

ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()

In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-115735

Somatic Framework <= 1.8.14 - Subscriber+ Arbitrary File Deletion

The Somatic Framework WordPress plugin through 1.8.14 does not perform an authorization check or validate a user-supplied file path before deleting it, allowing any authenticated user, such as a subscriber, to delete arbitrary files on the server, which can lead to a full site takeover.

CVSS 3.1 · 9.6 Critical EPSS < 1% KEV · Not listed
CVE-2026-121497

Askany < 2.2.0 - Unauthenticated Arbitrary File Upload

The AskAny WordPress plugin before 2.2.0 does not validate the extension or content of files attached to chat messages, trusting the browser-supplied file type instead, which allows unauthenticated users to upload PHP files and execute arbitrary code when visitor attachments are enabled.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Products
CVE-2026-115734

Pay With a Tweet <= 1.0.5 - Subscriber+ Arbitrary File Deletion via Button Download Path

The Pay with a tweet WordPress plugin through 1.0.5 does not validate a file path before deleting it, nor does it restrict access to the relevant administration screens, allowing users with a role as low as Subscriber to delete arbitrary files on the server, which can lead to a full site compromise.

CVSS 3.1 · 9.6 Critical EPSS < 1% KEV · Not listed
Products
CVE-2026-115733

PrintAura WooCommerce API <= 4.0.2 - Unauthenticated WooCommerce REST API Authentication Bypass

The Printaura-Woocommerce WordPress plugin through 4.0.2 does not properly restrict access to the WooCommerce REST API, causing every WooCommerce REST route to accept unauthenticated requests, which allows unauthenticated attackers to read and modify store data including customer orders and personal information, store and payment settings, and webhooks.

CVSS 3.1 · 9.1 Critical EPSS < 1% KEV · Not listed
CVE-2026-63979

net/handshake: hand off the pinned file reference to accept_doit

In the Linux kernel, the following vulnerability has been resolved: net/handshake: hand off the pinned file reference to accept_doit handshake_req_next() removes the request from the per-net pending list and drops hn_lock before handshake_nl_accept_doit() reads req->hr_sk->sk_socket and dereferences sock->file (once in FD_PREPARE() and again in get_file()). In that window a consumer running tls_handshake_cancel() followed by sockfd_put() (svc_sock_free) or __fput_sync() (xs_reset_transport) releases sock->file. sock_release() then runs sock_orphan(), zeroing sk_socket, and frees the struct socket. The accept-side code either reads NULL through sk_socket or chases freed memory. The submit-side sock_hold() does not prevent this. sk_refcnt protects struct sock, but struct socket and sock->file are independently refcounted via the file descriptor the consumer owns. Pinning sk leaves sock and sock->file unprotected. Retarget the accept-side dereferences at req->hr_file, which was pinned at submit time, instead of req->hr_sk->sk_socket->file. Pinning on its own is not sufficient: a consumer that cancels between handshake_req_next() returning and accept_doit reaching FD_PREPARE() takes the !remove_pending() branch in handshake_req_cancel() and drops hr_file before the accept side takes its own reference. Hand off an additional file reference inside handshake_req_next(), under hn_lock, so the accept side operates on a reference that no concurrent handshake_req_cancel() can revoke. FD_PREPARE() consumes that handed-off reference, either by transferring it to the new fd in fd_publish() or by dropping it in the cleanup destructor on error; the explicit get_file() that previously balanced FD_PREPARE() is therefore redundant and goes away. Update handshake_req_cancel_test2 and _test3 to simulate the FD_PREPARE() consumption with an fput() so the kunit file-count assertions stay balanced.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-125347

chromium-browser: Incorrect authorization in FileSystem

Incorrect authorization in FileSystem in Google Chrome prior to 157.0.8103.50 allowed a remote attacker leveraging social engineering to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)

CVSS 3.1 · 9.6 Critical EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-98432

ipv4: free inet_opt and ireq_opt after an RCU grace period

In the Linux kernel, the following vulnerability has been resolved: ipv4: free inet_opt and ireq_opt after an RCU grace period tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the child socket (newinet->inet_opt) without copying it. Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp_check_req(). tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt() and ip_options_build() then read opt->optlen twice. Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inet_csk_reqsk_queue_drop() calls timer_delete_sync() before the child can be freed. Since commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt with a plain kfree(), leading to a use-after-free in ip_options_build(). A similar issue exists with request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program). reqsk_timer_handler() clones the request socket with inet_reqsk_clone(), so that the old request socket and its clone share the same ireq_opt, then reqsk_migrate_reset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcp_v4_syn_recv_sock()) when the clone is freed, and tcp_v4_reqsk_destructor() also uses a plain kfree(). Readers already use RCU, and other paths replacing inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor() as well. IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock() duplicates the options. tcp_v6_reqsk_destructor() has the same migration issue with ipv6_opt, which is only set by CALIPSO. This will be addressed in a separate patch.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-126837

Attacker able to redirect a client's database traffic to a host they control via special characters in an SRV target, bypassing the SRV parent-domain guard

A validation flaw in the DNS SRV host discovery of the MongoDB Node.js driver may cause the driver to connect to a host outside the expected domain. For a mongodb+srv:// connection string, the driver checks each host name in the DNS SRV response against the domain of the connection string. The driver then builds the connection address from the original name, in which certain characters end the host name early. An unauthenticated party who can forge or change the DNS SRV response may redirect the connection to a host of their choice. TLS does not prevent this, because the driver verifies the server certificate against the redirected host name. This may result in unintended disclosure of application data and authentication credentials, and in altered query results. Applications that use mongodb:// connection strings are not affected.

CVSS 4.0 · 9.1 Critical EPSS < 1% KEV · Not listed
Vendors
—
Products
—
CVE-2026-119078

Apache Commons Codec: Blake3 doFinalize is stateless; the documented KDF example derives identical keys

Apache Commons Codec's Blake3 class documented the output of its doFinalize methods as depending on any previously finalized bytes, so that consecutive calls would return different output. In fact, doFinalize does not change the hash state: calling it again without supplying more input returns the same bytes. The key-derivation example in the class Javadoc, shipped since 1.16.0, derives two keys with two consecutive doFinalize calls. Code that follows it gets identical keys, so the separation between the derived keys is lost. The same applies to any application that calls doFinalize more than once on one instance and expects new output each time. This issue affects Apache Commons Codec from 1.16.0 before 1.23.0. Version 1.23.0 corrects the documentation, but the behavior of doFinalize is unchanged. Upgrading alone does not fix affected code. Users should check their applications for repeated doFinalize calls on the same Blake3 instance and derive multiple keys by requesting the combined length in one call and splitting the output, as the updated Javadoc shows.

CVSS 3.1 · 9.1 Critical EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-117551

Joomla Extension - jdownloads.com - RCE through file upload in jDownloads < 4.1.8

Joomla Extension - jdownloads.com - RCE through file upload in jDownloads < 4.1.8 - Insufficient validation of frontend thumbnail uploads allowed users with upload permission to place executable files on the server. This results in PHP code execution.

CVSS 4.0 · 10 Critical EPSS < 1% KEV · Not listed
Vendors
—
Products
—
CVE-2026-123753

Apache Axis2/Java: SSRF via WS-Addressing ReplyTo and FaultTo endpoints

Server-Side Request Forgery (SSRF) vulnerability in Apache Axis2/Java. An unauthenticated caller could supply a non-anonymous WS-Addressing wsa:ReplyTo or wsa:FaultTo address, and Axis2 would open a connection to that address to deliver the response or fault, allowing requests to internal hosts and delivery of response content to a host of the caller's choosing. From 2.0.2, decoupled responses are refused unless allowNonAnonymousResponseEndpoints is enabled, and enabled endpoints are restricted by scheme and screened at both the header-parsing and transport-selection layers. This issue affects Apache Axis2/Java: through 2.0.1. Users are recommended to upgrade to version 2.0.2, which fixes the issue.

CVSS 3.1 · 9.1 Critical EPSS < 1% KEV · Not listed
Vendors
CVE-2026-121688

CVE-2026-121688

FrodoBots EarthRover Mini+ firmware (version 6.2.4_6.2.5_0.614.0) contains an insecure STM32 firmware update mechanism. The STM32 motor‑controller firmware is fetched over unencrypted HTTP. Integrity is validated only via MD5, with the hash provided in the same unprotected response. No code‑signing mechanism is implemented, allowing firmware to be replaced with potentially malicious code.

CVSS 3.1 · 9.1 Critical EPSS < 1% KEV · Not listed
Vendors
CVE-2026-121687

CVE-2026-121687

FrodoBots EarthRover Mini+ firmware (version 6.2.4_6.2.5_0.614.0) contains several local interfaces that are exposed without authentication. 1. HTTP REST API (port 80): motor control, telemetry/GPS/IMEI, plaintext WiFi password (GET /api/v1/wifi/status), join-arbitrary-WiFi, diagnostic export. 2. ADB (Android Debug Bridge, port 5555) access to root shell 3. SSH (port 22)

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors
CVE-2026-121686

CVE-2026-121686

FrodoBots EarthRover Mini+ firmware (version 6.2.4_6.2.5_0.614.0) is vulnerable to unauthenticated, remote code execution via MQTT. A firmware method accepts arbitrary shell commands delivered via Amazon Web Services Internet of Things Message Queuing Telemetry Transport (AWS IoT MQTT) messages and executes them as root. Access is gated only by shared Internet of Things (IoT) credentials, with no per‑device authentication, enabling remote code execution as root across the fleet.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors