Vulnerabilidades explotables hoy
406,286en 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,560
- Alto21,573
- Medio20,071
- Bajo2,088
Filtros
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2025-27813—1.0%
——0——CVE-2022-20051—1.0%
——0——CVE-2021-39770—1.0%
——0——CVE-2024-23695—1.0%
——0——CVE-2026-165172.9 BAJ1.0%
——0A signed integer overflow vulnerability was found in libarchive's ZIP writer. In the archive_write_zip_header function in archive_write_set_format_zip.c, when ZIP encryption is enabled and the entry file size is close to INT64_MAX, the addition of the encryption overhead to the entry size overflows int64_t, resulting in undefined behavior. This could lead to incorrect Zip64 extension decisions or potential memory corruption.41dCVE-2026-42306—1.0%
——0——CVE-2025-21101—1.0%
——0——CVE-2026-532507.8 ALT1.0%
——0In the Linux kernel, the following vulnerability has been resolved:
xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata()
The TX metadata area resides in the UMEM buffer which is memory-mapped
and concurrently writable by userspace. In xsk_skb_metadata(),
csum_start and csum_offset are read from shared memory for bounds
validation, then read again for skb assignment. A malicious userspace
application can race to overwrite these values between the two reads,
bypassing the bounds check and causing out-of-bounds memory access
during checksum computation in the transmit path.
Fix this by reading csum_start and csum_offset into local variables
once, then using the local copies for both validation and assignment.
Note that other metadata fields (flags, launch_time) and the cached
csum fields may be mutually inconsistent due to concurrent userspace
writes, but this is benign: the only security-critical invariant is
that each field's validated value is the same one used, which local
caching guarantees.13dCVE-2026-317617.8 ALT1.0%
——0In the Linux kernel, the following vulnerability has been resolved:
iio: gyro: mpu3050: Move iio_device_register() to correct location
iio_device_register() should be at the end of the probe function to
prevent race conditions.
Place iio_device_register() at the end of the probe function and place
iio_device_unregister() accordingly.18dCVE-2026-489254.3 MED1.0%
——0A cross-site request forgery (CSRF) vulnerability in Jenkins GitHub Integration Plugin 0.7.3 and earlier allows attackers to attackers to trigger a build for a pull request.18dCVE-2026-121905.3 MED1.0%
——0A vulnerability has been found in Genspark AI Workspace App 2.8.4 on Android. This vulnerability affects unknown code of the component ai.mainfunc.genspark. The manipulation leads to improper authorization in handler for custom url scheme. The attack can only be performed from a local environment. The vendor was contacted early about this disclosure but did not respond in any way.100dCVE-2026-103012—1.0%
——0Claude Code selected an API key stored by Claude Code, for example from an earlier `/login` or written directly to its configuration, ahead of the user's valid Claude Enterprise or Team sign-in when fetching the organization's server-managed settings, even though the session itself authenticated with the Enterprise or Team account. When the settings endpoint rejected that stored key, the session started without the organization's server-managed policy (such as permission deny rules, model restrictions and managed-only locks) or, if a previously cached copy existed on the machine, kept applying that stale copy without receiving later policy changes — while continuing to operate as the organization's account. Triggering this required local access to a device with such a stored API key; the no-policy case additionally required that no managed settings had previously been cached. Endpoint-managed (MDM or file-based) settings were not affected. Claude for Enterprise organizations were affected from version 2.0.68; Claude for Work (Team) organizations from version 2.1.38, when server-managed settings became available to them.
Users on standard Claude Code auto-update have received this fix already. Users performing manual updates are advised to update to version 2.1.260 or later.
Thank you to Tamas Voros / NVIDIA AI Red Team for reporting this issue.32dCVE-2026-0315—1.0%
——0A local privilege escalation vulnerability in the Palo Alto Networks GlobalProtect™ app enables a local user to escalate their privileges to root on macOS. This enables a non-administrative user to execute arbitrary commands with administrative privileges.
The GlobalProtect app on Linux, Windows, iOS, Android and Chrome OS is not affected by this vulnerability.17dCVE-2026-226767.8 ALT1.0%
——0Barracuda RMM versions prior to 2025.2.2 contain a privilege escalation vulnerability that allows local attackers to gain SYSTEM-level privileges by exploiting overly permissive filesystem ACLs on the C:\Windows\Automation directory. Attackers can modify existing automation content or place attacker-controlled files in this directory, which are then executed under the NT AUTHORITY\SYSTEM account during routine automation cycles, typically succeeding within the next execution cycle.6dCVE-2021-39753—1.0%
——0——CVE-2026-1154004.4 MED1.0%
——0crawlseo before version 0.2.5 contains a cleartext storage vulnerability that allows attackers with database read access to obtain Google OAuth access and refresh tokens stored unencrypted in the User.googleTokens column. Attackers can read the plaintext long-lived refresh tokens from a compromised or exposed Postgres database to gain indefinite, unauthenticated access to all registered users' Google Search Console data.4dCVE-2024-0022—1.0%
——0——CVE-2026-315047.8 ALT1.0%
——0In the Linux kernel, the following vulnerability has been resolved:
net: fix fanout UAF in packet_release() via NETDEV_UP race
`packet_release()` has a race window where `NETDEV_UP` can re-register a
socket into a fanout group's `arr[]` array. The re-registration is not
cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout
array.
`packet_release()` does NOT zero `po->num` in its `bind_lock` section.
After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex`
still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`
that already found the socket in `sklist` can re-register the hook.
For fanout sockets, this re-registration calls `__fanout_link(sk, po)`
which adds the socket back into `f->arr[]` and increments `f->num_members`,
but does NOT increment `f->sk_ref`.
The fix sets `po->num` to zero in `packet_release` while `bind_lock` is
held to prevent NETDEV_UP from linking, preventing the race window.
This bug was found following an additional audit with Claude Code based
on CVE-2025-38617.13dCVE-2025-48513—1.0%
——0——CVE-2024-33034—1.0%
——0——CVE-2025-658556.6 MED1.0%
——0The OTA firmware update mechanism in Netun Solutions HelpFlash IoT (firmware v18_178_221102_ASCII_PRO_1R5_50) uses hard-coded WiFi credentials identical across all devices and does not authenticate update servers or validate firmware signatures. An attacker with brief physical access can activate OTA mode (8-second button press), create a malicious WiFi AP using the known credentials, and serve malicious firmware via unauthenticated HTTP to achieve arbitrary code execution on this safety-critical emergency signaling device.20dCVE-2026-683847.8 ALT1.0%
——0In the Linux kernel, the following vulnerability has been resolved:
drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves
xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO
after it transitions NULL/SYSTEM -> TT, and detaches them after it
transitions TT -> SYSTEM. Both operations were done synchronously on
the CPU immediately after building the move's copy/clear fence,
without waiting for that fence to signal. This creates two races with
VF migration:
- Attach happens too late relative to the copy job it is meant to
protect. If the copy job is submitted before the CCS BBs are
attached, a VF migration event that pauses execution mid-copy can
observe partially copied CCS metadata without the attach state
needed to correctly save/restore it.
- Detach happens too early relative to the copy job that moves data
out of TT. The CCS BBs are torn down right after the copy fence is
obtained, while the actual blit may still be in flight. A VF
migration event that pauses execution mid-copy can then race the
save/restore path against the still-running blit, and the CCS BBs
it would need to make sense of the paused state have already been
removed.
Fix both races:
- Move the attach call to before the copy/clear job is submitted, so
the CCS BBs are already registered by the time the copy runs. On
attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy()
now takes the destination resource explicitly, since bo->ttm.resource
is not updated to the new resource until after the move commits.
- Detach only after explicitly waiting for the copy fence to signal,
instead of tearing down the CCS BBs immediately after obtaining it.
While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and
propagate errors: the per-context loop previously never broke out on
error, silently discarding earlier failures. Unwind by clearing each
attached context directly via xe_migrate_ccs_rw_copy_clear() instead of
reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be
attached before it will clean up either one.
(cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e)13dCVE-2026-02675.5 MED1.0%
——0An information exposure vulnerability in the Palo Alto Networks GlobalProtect app on macOS enables a local user to learn the configured passcodes for disabling, disconnecting, or uninstalling the GlobalProtect app. After the passcode is known, the user can perform these actions even if the GlobalProtect app configuration would not normally permit them to do so.102dCVE-2025-54633—1.0%
——0——CVE-2026-555975.5 MED1.0%
——0ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.2-26, an incorrect handling of arguments can cause a heap buffer over-write in the JP2 encoder. This issue has been fixed in version7.1.2-26.122dCVE-2025-0028—1.0%
——0——CVE-2026-28711—1.0%
——0——CVE-2025-48548—1.0%
——0——CVE-2026-102757—1.0%
——0An unprivileged, memory-protected ThreadX module can have the kernel read and write memory at addresses of its choosing, in privileged mode, and can use that to clear the MPU enable bit and remove its own isolation boundary.
The Module Manager decided whether a privileged service could dereference an object address a module named by asking only whether that address fell outside the module. The manager's object pool is outside every module, so the test was satisfied by an address shifted into the interior of one of the module's own privileged allocations, which denotes no object at all. The bytes such an address presents as a control block are bytes the module put there through ordinary create and set services, so the control block ID at the front of them could be made to read as any type the module chose, and the `_txe_` layer's ID test then agreed. The reported chain uses that to reach a privileged `memset` across an attacker-chosen range.30dCVE-2021-39758—1.0%
——0——CVE-2026-1128—1.0%
——0——CVE-2025-32325—1.0%
——0——CVE-2026-23263—1.0%
——0——CVE-2021-25473—1.0%
——0——CVE-2023-31225—1.0%
——0——CVE-2021-25491—1.0%
——0——CVE-2021-39789—1.0%
——0——CVE-2024-58044—1.0%
——0——CVE-2025-36100—1.0%
——0——CVE-2026-234667.8 ALT1.0%
——0In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Open-code GGTT MMIO access protection
GGTT MMIO access is currently protected by hotplug (drm_dev_enter),
which works correctly when the driver loads successfully and is later
unbound or unloaded. However, if driver load fails, this protection is
insufficient because drm_dev_unplug() is never called.
Additionally, devm release functions cannot guarantee that all BOs with
GGTT mappings are destroyed before the GGTT MMIO region is removed, as
some BOs may be freed asynchronously by worker threads.
To address this, introduce an open-coded flag, protected by the GGTT
lock, that guards GGTT MMIO access. The flag is cleared during the
dev_fini_ggtt devm release function to ensure MMIO access is disabled
once teardown begins.
(cherry picked from commit 4f3a998a173b4325c2efd90bdadc6ccd3ad9a431)13d