Vulnerabilidades explotables hoy
406,313en 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,766
Nuevos KEV · 24H0
Exploit Today ≥ 701,698
Distribución · última ventana
- Crítico5,562
- Alto21,577
- Medio20,086
- Bajo2,090
Filtros
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2025-342907.8 ALT1.1%
——0Versa SASE Client for Windows versions released between 7.8.7 and 7.9.4 contain a local privilege escalation vulnerability in the audit log export functionality. The client communicates user-controlled file paths to a privileged service, which performs file system operations without impersonating the requesting user. Due to improper privilege handling and a time-of-check time-of-use race condition combined with symbolic link and mount point manipulation, a local authenticated attacker can coerce the service into deleting arbitrary directories with SYSTEM privileges. This can be exploited to delete protected system folders such as C:\\Config.msi and subsequently achieve execution as NT AUTHORITY\\SYSTEM via MSI rollback techniques.26dCVE-2026-1115556.0 MED1.1%
——0A flaw was found in luksmeta. Improper boundary validation of metadata slots allows an attacker capable of supplying or modifying a disk header to redirect wipe or load operations outside the intended metadata area. An attacker could exploit this vulnerability by providing a crafted header with valid checksums to overwrite or zero out encrypted payload data, resulting in persistent data loss and corrupted storage. Exploitation typically requires privileged access to modify raw block devices or the ability to induce an administrator to process an untrusted disk image.14dCVE-2026-0015—1.1%
——0——CVE-2025-50255—1.1%
——0——CVE-2026-493234.3 MED1.1%
——0Weak authentication between the Wireless Control Module (WCM) and the Engine Control Module (ECM) of the Indian Motorcycle Scout Bobber + Tech 2025 model year allows an adjacent-network attacker with read access to the in-vehicle network to recover the per-vehicle ECM immobilizer secret by passively observing a single seed/key exchange. The WCM derives its response using a reversible, non-cryptographic operation rather than a cryptographic challenge-response, so the persistent immobilizer secret can be reconstructed from one captured exchange. With this secret the attacker can authenticate to the ECM independently of the WCM and start the engine, defeating the immobilizer. Specific protocol details have been withheld pending vendor remediation.104dCVE-2024-49845—1.1%
——0——CVE-2021-0978—1.1%
——0——CVE-2026-440384.4 MED1.1%
——0A global out-of-bounds read in the Huffman decoder of the bundled IJG JPEG libraries (dcmjpeg/libijg8, libijg12 and libijg16) of OFFIS DCMTK 3.7.0 allows an attacker to read memory beyond the extend_test[] and extend_offset[] tables, causing incorrectly decoded pixel data or a crash, via a DICOM file with a crafted JPEG stream whose Huffman table defines a difference category above 15. Huffman symbol values are not range-checked unless DCMTK is built with DCMTK_ENABLE_STRICT_HUFFMAN_TABLE_CHECK, which is disabled by default. dcmdjpeg and any application that decompresses JPEG DICOM images with DCMTK are affected. The issue is fixed in commit d6ae1bc8d5b9ae9c7300013c8c85cc2ea0fd8cf5.24dCVE-2026-352427.5 ALT1.1%
——0Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). The supported version that is affected is 7.2.6. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H).6dCVE-2026-944187.5 ALT1.1%
——0Under WOLFSSL_SMALL_CERT_VERIFY, ProcessPeerCertParse() runs the certificate signature check separately from the parse to keep peak memory down, then merges the two results, but it merged the signature result back only when the parse returned 0, so any parse error hid it. ParseCertRelative() reaches its validity-date, name-constraint and critical-extension checks only after ConfirmSignature() has passed, so splitting the signature check out inverts the precedence that makes "override date errors" a sound policy, and ASN_SIG_CONFIRM_E is never surfaced anywhere. The attacker needs no key material from the real PKI and no CA compromise: a self-made certificate carrying the expected subject name, the trusted CA's subject as its issuer, arbitrary bytes where the signature goes, a validity window in the past and the attacker's own key pair is sufficient. Affected builds define WOLFSSL_SMALL_CERT_VERIFY, which is off by default, is not set implicitly by any platform or preset header, and is not reachable from any CMake option; the autotools routes are --enable-lowresource, --enable-leantls, --enable-tinytls13=cert and --enable-tinytls13=mutualauth, and examples/configs/user_settings_embedded.h reaches it through WC_CFG_SMALL_CERT_VERIFY, which ships as 0, while neither --enable-all nor --enable-distro enables it at all. The application must additionally install a verify callback through wolfSSL_CTX_set_verify() or wolfSSL_set_verify() with WOLFSSL_VERIFY_PEER that returns 1 for ASN_BEFORE_DATE_E or ASN_AFTER_DATE_E; wolfSSL ships this exact shape as myVerify() in wolfssl/test.h under VERIFY_OVERRIDE_DATE_ERR, which examples/client -D selects. An application with no callback, or whose callback returns preverify for date errors, still fails the handshake, and wolfSSL_CertManagerVerifyBuffer() and wc_CheckCertSignature() report ASN_SIG_CONFIRM_E correctly in the same binary. TLS 1.2 and TLS 1.3 are affected in both directions, and DTLS reaches the same function; where the forged certificate is a chain certificate the callback's consent causes it to be cached in the WOLFSSL_CTX certificate manager, so an exposed deployment must restart the context or the process rather than merely reconnect.30dCVE-2025-64394—1.1%
——0A vulnerability allowing a low-privileged local user to write arbitrary files with SYSTEM privileges during the installation of Veeam Backup for Microsoft 365, which can lead to privilege escalation or denial of service.5dCVE-2026-43087—1.1%
——0——CVE-2026-148667.7 ALT1.1%
——0IBM i Access Client Solutions 1.1.2.0 through 1.1.9.13 is vulnerable to injection of rogue certificate authority due to publicly writeable truststore.9dCVE-2022-20366—1.1%
——0——CVE-2026-240766.7 MED1.1%
——0Memory Corruption when processing registry values with incorrect types using a direct query method.9dCVE-2026-323237.3 ALT1.1%
——0Mullvad VPN is a VPN client app for desktop and mobile. When using macOS with versions 2026.1 and below, Mullvad VPN may allow local privilege escalation during installation or upgrade. The installer package executes binaries from /Applications/Mullvad VPN.app without verifying if the bundle is attacker-controlled or that the path is the legitimate Mullvad application. A user in the admin group can pre-place a crafted application bundle at that location and may be able to achieve code execution as root. Since the issue only affected the installer, there is no immediate need for users to update if they are already running an older version. This issue has been fixed in version 2026.2-beta1.101dCVE-2026-1046607.8 ALT1.1%
——0Missing authorization on COM objects in Progressive Robot hMailServer 6.0.0 through 6.3.5 (Windows only) lets a local interactive user with no hMailServer credential read and write arbitrary files as the service account and queue mail as any sender. The service registers its COM classes with no DCOM access or launch permission and calls CoInitializeSecurity with no security descriptor, so any user logged on at the console or over Remote Desktop can activate the classes in the running service; a hMailServer.Message, its Attachments and Attachment, and a hMailServer.FetchAccount created this way carry a credential that never authenticated. Attachments.Add(path) and Attachment.SaveAs(path) performed no authorization check, and Message.Save/Copy and FetchAccount.AccountID/Save performed none either up to 6.3.3 and from 6.3.4 treated a holder with no credential as the server's own event-script host. Because the service does not impersonate the COM caller, Attachments.Add reads any file the service account can read and returns it, Attachment.SaveAs writes attacker-chosen bytes to any path it can write (on a LocalSystem installation, code execution as SYSTEM), Message.Save queues outbound mail from any address past the SMTP checks, and FetchAccount attaches a mail-fetch job to any mailbox. The objects an Application handed out behave the same once a later Authenticate on that Application fails.24dCVE-2025-9810—1.1%
——0——CVE-2021-25512—1.1%
——0——CVE-2024-36499—1.1%
——0——CVE-2022-36845—1.1%
——0——CVE-2026-21157—1.1%
——0Improper input validation in Bixby prior to version 4.0.85.6 allows privileged local attackers to launch arbitrary activity.3dCVE-2025-21467—1.1%
——0——CVE-2026-114409—1.1%
——0Docker Desktop before version 4.97.0 could write third-party API keys and OAuth access tokens in cleartext to local application logs and diagnostics bundles due to insufficient IPC payload redaction. An attacker with read access to these files could obtain the credentials. These OAuth tokens are not Docker account tokens. Docker Desktop 4.94.0 and 4.95.0 addressed the known logging paths, but logs containing credentials can remain after upgrading. Docker Desktop 4.97.0 fixes the issue and includes cleanup of existing host logs and crash dumps.6dCVE-2026-436904.7 MED1.1%
——0A race condition was addressed with improved locking. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. A local user may be able to read kernel memory.46dCVE-2026-104116—1.1%
——0A missing authorization check in the illumos zones statistics daemon (zonestatd) allows a local user in any zone to disrupt zonestat in other zones and to determine which zones are running. The zonestatd door server procedure, zsd_server() in usr/src/cmd/zonestat/zonestatd/zonestatd.c, handles the ZSD_CMD_NEW_ZONE command, which is intended to be sent by zoneadmd, without checking the caller's credentials. Because the zonestatd door is accessible to all users in every zone, an unprivileged user can send this command with an arbitrary zone ID, causing zonestatd to re-create its door file in that zone, so that new zonestat requests in that zone can fail while the file is replaced. The time taken to handle the command also reveals whether a given zone ID belongs to a running zone. The flaw has existed since 2010 (illumos-gate commit efd4c9b6), and affects any illumos distribution prior to illumos-gate commit 865b58d2.23dCVE-2025-713095.5 MED1.1%
——0In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: fix deadlock in ni_read_folio_cmpr
Syzbot reported a task hung in ni_readpage_cmpr (now ni_read_folio_cmpr).
This is caused by a lock inversion deadlock involving the inode mutex
(ni_lock) and page locks.
Scenario:
1. Task A enters ntfs_read_folio() for page X. It acquires ni_lock.
2. Task A calls ni_read_folio_cmpr(), which attempts to lock all pages in
the compressed frame (including page Y).
3. Concurrently, Task B (e.g., via readahead) has locked page Y and
calls ntfs_read_folio().
4. Task B waits for ni_lock (held by A).
5. Task A waits for page Y lock (held by B).
-> DEADLOCK.
The fix is to restructure locking: do not take ni_lock in ntfs_read_folio().
Instead, acquire ni_lock inside ni_read_folio_cmpr() ONLY AFTER all required
page locks for the frame have been successfully acquired. This restores the
correct lock ordering (Page Lock -> ni_lock) consistent with VFS.
[almaz.alexandrovich@paragon-software.com: ni_readpage_cmpr was renamed to ni_read_folio_cmpr]19dCVE-2026-2103—1.1%
——0——CVE-2026-353764.5 MED1.1%
——0A Time-of-Check to Time-of-Use (TOCTOU) vulnerability exists in the chcon utility of uutils coreutils during recursive operations. The implementation resolves recursive targets using a fresh path lookup (via fts_accpath) rather than binding the traversal and label application to the specific directory state encountered during traversal. Because these operations are not anchored to file descriptors, a local attacker with write access to a directory tree can exploit timing-sensitive rename or symbolic link races to redirect a privileged recursive relabeling operation to unintended files or directories. This vulnerability breaks the hardening expectations for SELinux administration workflows and can lead to the unauthorized modification of security labels on sensitive system objects.6dCVE-2026-789362.9 BAJ1.1%
——0Observable discrepancy in CustomTabs in Google Chrome on on Android prior to 152.0.7977.65 allowed a local attacker to obtain cross-origin data via a co-installed app. (Chromium security severity: Medium)62dCVE-2026-683827.8 ALT1.1%
——0In the Linux kernel, the following vulnerability has been resolved:
drm/xe/guc: Hold device ref until queue teardown completes
GuC exec queue destruction can run asynchronously. If the final device
put happens from a destroy worker, drmm cleanup can end up draining
the same workqueue and deadlock.
Hold a drm_device reference for the queue lifetime and drop it after
queue teardown completes. This keeps drmm cleanup from running while
async destroy work is still pending.
Move GuC destroy work to a module-lifetime Xe workqueue and flush it
on PCI remove so hot-unbind/rebind still waits for pending destroy work.
With queue-held device refs, guc_submit_sw_fini() cannot run with live
GuC IDs. Replace the fini wait with an assertion and remove the unused
fini_wq.
v2:
- Rebase
v3:
- Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt)
- Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt)
- Drop separate deferred drm_dev_put worker.
- Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini().
v4:
- Replace the guc_submit_sw_fini() wait with an assertion and remove
the now-unused fini_wq. (sashiko)
v5:
- Move destroy work to a module-lifetime Xe workqueue instead of
system_dfl_wq. (Matt)
- Flush the module-lifetime destroy workqueue during PCI remove to
preserve the old device-remove wait semantics.
v6:
- Keep SVM pagemap destroy work on the per-device destroy_wq to avoid
letting it outlive the xe_device/drm_device. (Sashiko)
- Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work
can be queued from the reclaim path.
v7:
- Drop the per-device xe->destroy_wq and use the module-level destroy WQ
for SVM pagemap destroy as well. (Matt)
- Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*()
helpers because the WQ is no longer exec-queue specific. (Matt)
v8:
- Rebase.
v9:
- Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM
destroy_wq because it can be queued from reclaim and embeds
the dev_pagemap used by devres teardown. (Sashiko)
- Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM
from it.
- Update the module-WQ kdoc to document the GuC/SVM split.
v10:
- Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the
workqueue allocation warning.
v11:
- Drop the SVM pagemap destroy comment as it was revision-specific.
(Thomas)
v12:
- Rebase.
(cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)13dCVE-2025-48066—1.1%
——0——CVE-2025-48653—1.1%
——0——CVE-2026-1187743.7 BAJ1.1%
——0Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used certificate.verify(child), _verifySignature(), lib/x509.js to process the relevant input or security decision. node-forge selected RSA padding and RSASSA-PSS parameters from the issuer certificate rather than the child certificate being verified. A child labeled as RSASSA-PSS could therefore be accepted with a PKCS#1 v1.5 signature when the issuer used PKCS#1 v1.5. The signature still had to be produced with the trusted issuer's private key, so this did not permit certificate identity forgery, but it could bypass policies that require a declared signature scheme. This issue is fixed in version 1.4.1.2dCVE-2026-569418.4 ALT1.1%
——0In multiple functions of fpc_tee_hal.c, there is a possible use-after-free due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.41dCVE-2026-1057663.1 BAJ1.1%
——0Use of the backend-facing $scheme variable in the trailing-slash directory redirect in nginx.conf of Chainguard Academy (edu) from commit 0b75ff98057f69b044a3e7194e428066ac5ad0d4 before commit 93dc0e50739c225f5aee2e803800a47fc0feb906 allows an on-path network attacker to read or modify documentation content served to a victim via an HTTPS request for a slashless directory path, because TLS terminates at the load balancer in front of Nginx and the resulting 301 response redirects the client to a plaintext http:// URL. Browsers that ship the HSTS preload list are not affected, because the .dev top-level domain is preloaded; clients that do not enforce HSTS, such as command-line HTTP clients and scripts that follow redirects, are affected.27dCVE-2026-104117—1.1%
——0A missing authorization check in the illumos IP management daemon (ipmgmtd) allows a local user to change the persistent IP multipathing (IPMP) configuration. The ipmgmtd door dispatch table in usr/src/cmd/cmd-inet/lib/ipmgmtd/ipmgmt_door.c does not require the solaris.network.interface.config authorization for the IPMGMT_CMD_IPMP_UPDATE command, although its handler, ipmgmt_ipmp_update_handler(), writes to the persistent ipadm configuration when the IPMGMT_PERSIST flag is set. An unprivileged local user can therefore add interfaces to, or remove them from, existing IPMP groups in the stored configuration. The running configuration is not changed; the modification takes effect when the stored configuration is next applied, such as at boot, and may disrupt network connectivity. The flaw has existed since 2021 (illumos-gate commit a73be61a), and affects any illumos distribution prior to illumos-gate commit e8d3efa1.23dCVE-2022-21787—1.1%
——0——CVE-2026-1114984.7 MED1.1%
——0OpenManage Enterprise, versions prior to 4.8.0, contains an Improper Resource Locking vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Protection mechanism bypass.2dCVE-2026-927455.0 MED1.1%
——0A flaw was found in cockpit-machines. This vulnerability allows a local attacker with the ability to inspect process metadata to disclose a sensitive Red Hat Subscription Management (RHSM) offline token. The token is exposed when it is passed as a command-line argument to a helper script during the token validation process. Successful exploitation could lead to the compromise of confidentiality, as the exposed token can be used to request access tokens.41d