CVE Watch409,563 en archivo total

Vulnerabilidades explotables hoy

409,563en la vista actual

Score único combinando CVSS, membresía KEV y EPSS. Cada CVE con su ficha propia — timeline desde publicación hasta explotación activa.

En catálogo KEV1,769

Nuevos KEV · 24H0

Exploit Today ≥ 701,700

Distribución · última ventana

Crítico
5,543
Alto
21,162
Medio
20,284
Bajo
2,080

Filtros

Ventana

Severidad

Filtros

Vulnerabilidades389,561–389,600 · 409,563

CVECVSSEPSSKEVRExplotTítuloVis.

——1——CVE-2025-629754.3 MED

3.1%

——1Cross-Site Request Forgery (CSRF) vulnerability in raychat Raychat raychat allows Cross Site Request Forgery.This issue affects Raychat: from n/a through <= 2.2.1.19d CVE-2026-847184.3 MED

3.1%

——1A flaw was found in the Ansible Automation Platform automation-controller. In the shipped production configuration, the Controller trusts the client-supplied X-Forwarded-For header as the request's client IP without verifying that it originated from a trusted proxy, and selects the leftmost (attacker-controlled) header value. As a result, an attacker can forge the source IP address recorded for their requests in the Controller's audit and access logs, degrading the integrity of forensic and SIEM attribution. The flaw does not grant additional access.2d CVE-2026-910173.7 BAJ

3.1%

——1The Robokassa payment gateway for Woocommerce WordPress plugin before 1.8.9 does not verify the authenticity of incoming payment notifications when its non-default deferred-payment feature is enabled, allowing unauthenticated attackers to forge a notification and mark arbitrary WooCommerce orders as paid or on-hold without payment or a valid signature.50d CVE-2026-180443.7 BAJ

3.1%

——1The Estatik Real Estate Plugin WordPress plugin before 4.3.4 does not validate the same recipient list that it later uses to address the message sent by its property request form, allowing unauthenticated users to send emails to arbitrary recipients with arbitrary subject, body and Reply-To on sites where the form is configured to route to a custom address.73d CVE-2021-0455—

3.0%

——1——CVE-2026-179325.5 MED

3.1%

——1Use after free in DataTransfer in Google Chrome on Windows prior to 151.0.7922.72 allowed a local attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low)15d CVE-2020-35555—

3.1%

——1——CVE-2024-47808—

3.1%

——1——CVE-2026-908905.5 MED

3.1%

——1ASRock Polychrome SYNC/RGB software utility developed by ASRock Inc. has an Untrusted Pointer Dereference vulnerability. Authenticated local attackers can send a specially crafted IOCTL request to cause the driver to dereference an unvalidated pointer, resulting in an operating system crash.50d CVE-2025-525397.3 ALT

3.1%

——1A buffer overflow with Xilinx Run Time Environment may allow a local attacker to read or corrupt data from the advanced extensible interface (AXI), potentially resulting in loss of confidentiality, integrity, and/or availability.30d CVE-2026-846665.4 MED

3.1%

——1Jenkins Job Configuration History Plugin 1367.vc8fa_b_15101dc and earlier allows overwriting the plugin's history recording configuration through Stapler data binding, allowing attackers to redirect history storage to an attacker-specified directory and modify history recording settings.64d CVE-2025-462805.5 MED

3.1%

——1An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Tahoe 26. An app may be able to cause unexpected system termination.107d CVE-2025-144624.3 MED

3.1%

——1The Lucky Draw Contests plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 4.2. This is due to missing or incorrect nonce validation in misc-settings.php. This makes it possible for unauthenticated attackers to update plugin settings via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.31d CVE-2025-711385.5 MED

3.1%

——1In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: Add missing NULL pointer check for pingpong interface It is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in a single place the check is missing. Also use convenient locals instead of phys_enc->* where available. Patchwork: https://patchwork.freedesktop.org/patch/693860/8d CVE-2026-914756.6 MED

3.1%

——1Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Clean Content SDK). The supported version that is affected is 8.5.8. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Outside In Technology executes to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Outside In Technology accessible data as well as unauthorized read access to a subset of Oracle Outside In Technology accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Outside In Technology. CVSS 3.1 Base Score 6.6 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L).4d CVE-2025-14465—

3.1%

——1——CVE-2025-49856—

3.1%

——1——CVE-2025-145695.3 MED

3.1%

——1A vulnerability was detected in ggml-org whisper.cpp up to 1.8.2. Affected is the function read_audio_data of the file /whisper.cpp/examples/common-whisper.cpp. The manipulation results in use after free. The attack requires a local approach. The exploit is now public and may be used. The project was informed of the problem early through an issue report but has not responded yet.31d CVE-2026-554636.5 MED

3.1%

——1The Goobi viewer is a web application that allows digitised material to be displayed in a web browser. From version 4.11.0 to before version 26.05, several Jakarta WebSocket endpoints in goobi-viewer-core (DownloadTaskEndpoint, CampaignEndpoint, AutocompleteEndpoint, UserEndpoint) accept connections without verifying that the associated HttpSession belongs to a logged-in user, and none validate the Origin header against an allowlist. An unauthenticated attacker can therefore connect to these endpoints; through CampaignEndpoint this allows polluting the in-process crowdsourcing page-lock map and broadcasting forged lock messages, disrupting reviewers' work. This issue has been patched in version 26.05.9d CVE-2026-1167316.1 MED

3.1%

——1Furnace through 0.6.8.3 contains an out-of-bounds write vulnerability in DivEngine::loadFTM() that allows attackers to corrupt heap memory via an unchecked subsong index in the GROOVES block. Attackers can craft a FamiTracker module with a subsong count of 2 or more to write a groove pattern past the subsong vector, crashing Furnace when opened.2d CVE-2018-21082—

——1——CVE-2026-799663.3 BAJ

3.1%

——1Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Insertion of Sensitive Information into Log File vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to information exposure.59d CVE-2026-185416.4 MED

3.1%

——1IBM Planning Analytics 2.0, and 2.1 is vulnerable to stored cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.23d CVE-2025-58801—

3.1%

——1——CVE-2023-40074—

3.1%

——1——CVE-2026-784075.4 MED

3.1%

——1IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 are vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.29d CVE-2025-71129—

3.1%

——1——CVE-2026-801693.3 BAJ

3.1%

——1——CVE-2026-531457.8 ALT

3.1%

——1In the Linux kernel, the following vulnerability has been resolved: drm/gem: Try to fix change_handle ioctl, attempt 4 [airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") tried to fix a race condition between the gem_close and gem_change_handle ioctls, but got a few things wrong: - There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong. - dc366607c41c ("drm: Replace old pointer to new idr") tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix. We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now. Very clearly that's not the case. Here's my attempt to sort this out: - Rename the local variable to new_handle, the old aliasing with args->handle is just too dangerously confusing. - Merge the gem obj lookup with the two-stage idr_replace so that we avoid getting ourselves confused there. - This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gem_close on the new_handle could steal that. Fix that with the same two-stage approach create_tail uses. This is a bit overkill as documented in the comment, but I also don't trust my ability to understand this all correctly, so go with the established pattern we have from other ioctls instead for maximum paranoia. - Adjust error paths. I've tried to make the error and success paths common, because they are identical except for which handle is removed and on which we call idr_replace to (re)install the object again. But that made things messier to read, so I've left it at the more verbose version, which unfortunately hides the symmetry in the entire code flow a bit. - While at it, also replace the 7 space indent with 1 tab. And finally, because I flat out don't trust my abilities here at all anymore: - Disable the ioctl until we have the igt situation and everything else sorted out on-list and with full consensus. v2: Sashiko noticed that I didn't handle the error path for idr_replace correctly, it must be checked with IS_ERR_OR_NULL like in gem_handle_delete. So yeah, definitely should just the existing paths 1:1 because this is endless amounts of tricky. Also add the Fixes: line for the original ioctl, I forgot that too.19d CVE-2026-797273.3 BAJ

3.1%

——1Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Exposure of Sensitive System Information Due to Uncleared Debug Information vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to information exposure.59d CVE-2026-801753.3 BAJ

3.1%

——1Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Insertion of Sensitive Information into Externally-Accessible File or Directory vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to information exposure.54d CVE-2026-532237.1 ALT

3.1%

——1In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.19d CVE-2026-983697.8 ALT

3.1%

——1In the Linux kernel, the following vulnerability has been resolved: xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject() syzbot reported a suspicious RCU usage warning in ip6_pkt_drop(): WARNING: suspicious RCU usage in ip6_pkt_drop include/net/addrconf.h:389 suspicious rcu_dereference_check() usage! Call Trace: __in6_dev_get_safely include/net/addrconf.h:389 [inline] ip6_pkt_drop+0x596/0x610 net/ipv6/route.c:4620 ip6_pkt_discard+0x1c/0x30 net/ipv6/route.c:4651 xfrm_trans_reinject+0x324/0x630 net/xfrm/xfrm_input.c:806 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 When commit 4f4920669d21 ("xfrm: Reinject transport-mode packets through workqueue") converted xfrm_trans_reinject from a tasklet to a workqueue, the reinjection loop ceased running in softirq context. Workqueue workers run in process context where local_bh_disable() does not enter an RCU read-side critical section under CONFIG_PREEMPT_RCU. Because finish callbacks (such as ip6_rcv_finish) expect to run under an RCU read lock (performing route lookups, l3mdev lookups, and accessing RCU-protected data structures), invoking them in workqueue context without rcu_read_lock() triggers RCU lockdep warnings. Furthermore, packets queued to the workqueue via xfrm_trans_queue_net() may carry non-refcounted (noref) dst entries (e.g. from ip_route_input_noref). Additionally, on netdevice unregistration, dst_dev_put() replaces dst->dev with blackhole_netdev, so dst entries do not keep skb->dev alive while queued in the workqueue. Fix these issues by: 1. Calling skb_dst_force(skb) in xfrm_trans_queue_net() while still in the caller's RCU section to ensure dst is reference-counted before queuing. 2. Holding a reference on skb->dev via dev_hold()/dev_put() across workqueue deferral so skb->dev remains valid during finish() callback processing. 3. Acquiring rcu_read_lock() around the finish callback invocation loop in xfrm_trans_reinject().19d CVE-2026-23740—

3.1%

——1——