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

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Ir al buscador

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-8926
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** When asking curl to use a `.netrc` file to find credentials and at the same<br /> time specifying a URL with a username(without a password), like<br /> `https://user@example.com/`, curl could wrongly get and use the password for<br /> *another* user set in the `.netrc` file for that host if such a one exists and<br /> there is no match for the specified user.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026

CVE-2026-8927
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** When reusing a libcurl handle for sequential transfers driven by<br /> environment-variable proxy configuration, libcurl fails to clear the proxy<br /> authentication state between requests. Specifically, if the initial transfer<br /> authenticates against `proxyA` using Digest auth, a subsequent transfer routed<br /> through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended<br /> solely for `proxyA`.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026

CVE-2026-8932
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** libcurl would reuse a previously created connection even when some mTLS config<br /> related option had been changed that should have prohibited reuse.<br /> <br /> libcurl keeps previously used connections in a connection pool for subsequent<br /> transfers to reuse if one of them matches the setup. However, some TLS<br /> settings related to client certificates were left out from the configuration<br /> match checks, making them match too easily. In particular options related to<br /> the private key.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026

CVE-2026-9079
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** libcurl had a flaw that when instructed to clear proxy authentication<br /> credentials which made it not do so, leaving the old credentials around to get<br /> used for subsequent transfers that should not know nor use them.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026

CVE-2026-9080
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION`<br /> callback triggers a use-after-free vulnerability, where libcurl attempts to<br /> store a flag using a dangling struct pointer immediately after that pointer&amp;#39;s<br /> memory has been freed.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026

CVE-2026-9545
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In this scenario, libcurl first uses a proper HTTP/3 server for the initial<br /> transfers, and when it makes a second transfer to the same site it has been<br /> replaced by the attacker&amp;#39;s impostor machine - without a valid certificate.<br /> <br /> When libcurl returns to the hostname the second time with a cached SSL session<br /> (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the<br /> `CURLSSLOPT_EARLYDATA` bit is set in `CURLOPT_SSL_OPTIONS`), libcurl might<br /> send off the second request&amp;#39;s bytes on that new connection *before* enforcing<br /> the certificate verification failure. Potentially leaking sensitive<br /> information.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026

CVE-2026-9546
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** A vulnerability in libcurl caused the HTTP `Referer:` header to persist even<br /> when explicitly cleared. While the documentation states that passing NULL to<br /> `CURLOPT_REFERER` suppresses the header, the option failed to clear the<br /> internal state. As a result the previous referrer string was erroneously<br /> reused and sent in subsequent requests, potentially leaking sensitive<br /> information to unintended servers.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026

CVE-2026-9547
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** When a libcurl-based application performs transfers via `SCP://` or `SFTP://`<br /> and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an<br /> untrusted server. This vulnerability occurs when a server presents a host key<br /> type that does not match the specific key type already recorded for that host<br /> in the `known_hosts` file. Instead of rejecting the mismatch, the callback<br /> mechanism fails to properly enforce the restriction, allowing the connection<br /> to succeed without warning and risking a potential man-in-the-middle attack.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026

CVE-2026-12064
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** When a user invokes curl using a schemeless URL combined with<br /> `--proto-default` sftp (or scp), a disconnect occurs between the tool layer<br /> and libcurl. The tool layer incorrectly infers the URL scheme, which<br /> erroneously bypasses the initialization of critical SSH security options like<br /> CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 and CURLOPT_SSH_KNOWNHOSTS. Conversely, the<br /> libcurl runtime successfully honors CURLOPT_DEFAULT_PROTOCOL and establishes<br /> the connection via SFTP/SCP as specified. Because the tool layer skipped the<br /> security configuration, these SSH host verification options are silently<br /> omitted, causing curl to connect to an unverified SSH remote host without<br /> throwing an error.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026

CVE-2026-4967
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In IMS, there is a possible out of bounds read due to a missing bounds check. This could lead to remote denial of service with no additional execution privileges needed.
Gravedad CVSS v3.1: ALTA
Última modificación:
03/07/2026

CVE-2026-8286
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** A vulnerability exists where a new transfer that uses STARTTLS to upgrade the<br /> connection might reuse an existing live connection even though the TLS<br /> configuration mismatches so it should not.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026

CVE-2026-8458
Fecha de publicación:
03/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** libcurl might in some circumstances reuse the wrong connection when asked to<br /> do Negotiate-authenticated ones, even when they are set to use different<br /> &amp;#39;services&amp;#39;.<br /> <br /> libcurl features a pool of recent connections so that subsequent requests can<br /> reuse an existing connection to avoid overhead.<br /> <br /> When reusing a connection a range of criteria must be met. Due to a logical<br /> error in the code, a request that was issued by an application could<br /> wrongfully reuse an existing connection to the same server that was<br /> authenticated using different services.
Gravedad: Pendiente de análisis
Última modificación:
03/07/2026
Suscribirse a Vulnerabilidades