Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las últimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las últimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS o Boletines podemos estar informados diariamente de las últimas vulnerabilidades incorporadas al repositorio.

CVE-2026-38641

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** An issue in the DSO::mmap_and_copy function of relibc commit 61f42d allows attackers to cause a Denial of Service (DoS) via loading a crafted shared library.
Gravedad CVSS v3.1: ALTA
Última modificación:
29/06/2026

CVE-2026-39031

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** Lansweeper lsrunase 2.0 and lsencrypt 2.0 use RC4 encryption with a hardcoded 142-byte static key array to encrypt credentials. An 8-character prefix is stored in cleartext alongside the ciphertext. This allows an attacker with local access to recover any encrypted password to plaintext using a single SHA-1 hash and RC4 decryption operation, with no brute force required.
Gravedad CVSS v3.1: MEDIA
Última modificación:
29/06/2026

CVE-2026-46604

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** The TIFF decoder can panic when decoding an invalid image with an out-of-bounds strip offset.
Gravedad CVSS v3.1: ALTA
Última modificación:
01/07/2026

CVE-2024-23581

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** The HCL Traveler for Microsoft Outlook libraries are being flagged as potentially malicious software or an unrecognized application.
Gravedad CVSS v3.1: MEDIA
Última modificación:
29/06/2026

CVE-2026-55188

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** RustFS is a distributed object storage system built in Rust. From 1.0.0-alpha.1 until 1.0.0-beta.9, RustFS contains an authorization bypass in the bucket replication admin API. The ListRemoteTargetHandler handler for listing remote replication targets only checks whether request credentials exist, but does not verify that the caller has replication or administrator permissions. As a result, an authenticated user with no effective bucket or admin permissions can list remote replication target configuration for a bucket. Because the returned BucketTarget objects include remote target credentials, this can disclose replication access keys and secret keys. This vulnerability is fixed in 1.0.0-beta.9.
Gravedad CVSS v3.1: ALTA
Última modificación:
27/06/2026

CVE-2026-55838

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** RustFS is a distributed object storage system built in Rust. In 1.0.0-beta.7 and earlier, the real-time metrics endpoint at /rustfs/admin/v3/metrics is accessible to any valid IAM user regardless of their assigned policy. Every other admin handler in the codebase calls validate_admin_request to enforce admin-action IAM checks; the MetricsHandler skips this call entirely. A restricted IAM user whose policy grants only access to their own bucket can read server-wide operational metrics including disk I/O statistics, network throughput, scanner cycle timing, and cluster RPC state.
Gravedad CVSS v3.1: MEDIA
Última modificación:
27/06/2026

CVE-2026-55189

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** RustFS is a distributed object storage system built in Rust. From 1.0.0-alpha.1 until 1.0.0-beta.9, when the FTP frontend is enabled, the FTP read and probe handlers dispatch directly to the storage backend without ever calling the IAM authorization function that the FTP write/list handlers (and the entire HTTP S3 path) use. As a result, any user who can authenticate to the FTP listener — including a user whose IAM policy contains an explicit Deny on s3:GetObject — can read (RETR) and stat (SIZE/MDTM) any object in any bucket, and probe any bucket (CWD), completely regardless of their IAM policy. This vulnerability is fixed in 1.0.0-beta.9.
Gravedad CVSS v3.1: ALTA
Última modificación:
29/06/2026

CVE-2026-53317

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: Place upper limit on station AID<br /> <br /> Any station configured with an AID over 20 causes a firmware crash.<br /> This situation occurred in our testing using an AP interface on 7922<br /> hardware, with a modified hostapd, sourced from Mediatek&amp;#39;s OpenWRT<br /> feeds.<br /> <br /> In stock hostapd, station AIDs begin counting at 1, and this<br /> configuration is prevented with an upper limit on associated stations.<br /> However, the modified hostapd began allocation at 65, which caused the<br /> firmware to crash. This fix does not allow these AIDs to work, but will<br /> prevent the firmware crash.<br /> <br /> This crash was only seen on IFTYPE_AP interfaces, and the fix does not<br /> appear to have an effect on IFTYPE_STATION behavior.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53318

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr()<br /> <br /> Move the NULL check for &amp;#39;sta&amp;#39; before dereferencing it to prevent a<br /> possible crash.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53319

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()<br /> <br /> wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from<br /> wbt_alloc() and wbt_init(). However, both are expected failure paths:<br /> <br /> - wbt_alloc() can return NULL under memory pressure (-ENOMEM)<br /> - wbt_init() can fail with -EBUSY if wbt is already registered<br /> <br /> syzbot triggers this by injecting memory allocation failures during MTD<br /> partition creation via ioctl(BLKPG), causing a spurious warning.<br /> <br /> wbt_init_enable_default() is a best-effort initialization called from<br /> blk_register_queue() with a void return type. Failure simply means the<br /> disk operates without writeback throttling, which is harmless.<br /> <br /> Replace WARN_ON_ONCE with plain if-checks, consistent with how<br /> wbt_set_lat() in the same file already handles these failures. Add a<br /> pr_warn() for the wbt_init() failure to retain diagnostic information<br /> without triggering a full stack trace.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53320

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()<br /> <br /> nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks<br /> by comparing it with the current block number bd_blocknr. If they differ,<br /> the block is considered dead and skipped.<br /> <br /> However, bd_oblocknr should never be 0 since block 0 typically stores the<br /> primary superblock and is never a valid GC target block. A corrupted ioctl<br /> request with bd_oblocknr set to 0 causes the comparison to incorrectly<br /> match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing<br /> the dead block check and calling nilfs_bmap_mark() on a non-existent<br /> block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering<br /> the WARN_ON(ret == -ENOENT).<br /> <br /> Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the<br /> beginning of each iteration.<br /> <br /> [ryusuke: slightly modified the commit message and comments for accuracy]
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53321

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/napi: cap busy_poll_to 10 msec<br /> <br /> Currently there&amp;#39;s no cap on the maximum amount of time that napi is<br /> allowed to poll if no events are found, which can lead to kernel<br /> complaints on a task being stuck as there&amp;#39;s no conditional rescheduling<br /> done within that loop.<br /> <br /> Just cap it to 10 msec in total, that&amp;#39;s already way above any kind of<br /> sane value that will reap any benefits, yet low enough that it&amp;#39;s<br /> nowhere near being able to trigger preemption complaints.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026