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-55698

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can persist package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml. Before the patch, direct pnpm execution trusted an already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm and @pnpm/exe versions. A malicious repository could therefore commit package-manager lockfile package records and snapshots that bypassed fresh package-manager resolution, then cause pnpm to install and execute bytes selected by that committed lockfile state during automatic version switching. This vulnerability is fixed in 10.34.2 and 11.5.3.

Gravedad CVSS v3.1: ALTA

Última modificación:

30/06/2026

CVE-2026-55697

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can install configDependencies declared in pnpm-workspace.yaml before command dispatch. Before the patch, a repository could declare pacquet or @pnpm/pacquet as a config dependency and pnpm treated that repository-controlled dependency as an install-engine opt-in. During install, pnpm resolved a platform-specific @pacquet/-/pacquet binary from node_modules/.pnpm-config/ and spawned it as the developer or CI user. This vulnerability is fixed in 10.34.2 and 11.5.3.

Gravedad CVSS v3.1: ALTA

Última modificación:

30/06/2026

CVE-2026-50014

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm passes the lockfile-controlled git resolution.commit value to git fetch without a -- separator or commit-format validation. For git dependencies fetched through the shallow-fetch path, a malicious lockfile can replace the expected 40-character commit hash with a Git option such as --upload-pack=. For SSH and local transports, --upload-pack can execute the supplied command. HTTPS transports ignore --upload-pack, so the practical attack surface is primarily SSH or local git dependencies. This vulnerability is fixed in 10.34.0 and 11.4.0.

Gravedad CVSS v3.1: MEDIA

Última modificación:

29/06/2026

CVE-2026-50015

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm&#39;s patch application pipeline (@pnpm/patch-package) performs no path validation on file paths extracted from .patch files. An attacker who contributes a malicious patch file via a pull request can write attacker-controlled content to or delete arbitrary files on the filesystem during pnpm install, as the user running the install. The diff --git header paths containing ../../ sequences traverse out of the package directory, and the traversal is difficult to catch in code review because patch file diff headers are opaque to most reviewers. This vulnerability is fixed in 10.34.0 and 11.4.0.

Gravedad CVSS v3.1: ALTA

Última modificación:

29/06/2026

CVE-2026-50021

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm&#39;s tarball extraction worker skips integrity verification when the integrity field is absent from the lockfile resolution. If an attacker can both modify pnpm-lock.yaml to remove the integrity: field and cause the referenced registry URL to serve altered package content, pnpm install --frozen-lockfile can install the altered package without an integrity error. npm&#39;s npm ci enforces integrity by default; pnpm&#39;s behavior of silently skipping verification is a pnpm-specific fail-open gap. This vulnerability is fixed in 10.34.0 and 11.4.0.

Gravedad CVSS v3.1: MEDIA

Última modificación:

29/06/2026

CVE-2026-50573

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** pnpm is a package manager. Prior to 10.34.0 and 11.4.0, `pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml. When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain pnpm install then performs a resolution repair, accepts the registry&#39;s new integrity, updates the lockfile, installs the new content, and exits successfully. This means the lockfile integrity check does not act as a hard stop by default. This vulnerability is fixed in 10.34.0 and 11.4.0.

Gravedad CVSS v3.1: MEDIA

Última modificación:

29/06/2026

CVE-2026-50016

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm allows a transitive dependency alias from registry package metadata to contain path traversal segments. During install, pnpm later uses that alias as a filesystem path when linking dependency nodes. As a result, a registry package can cause `pnpm install --ignore-scripts` to replace paths in the current project with symlinks to attacker-controlled dependency package directories. This vulnerability is fixed in 10.34.0 and 11.4.0.

Gravedad CVSS v3.1: ALTA

Última modificación:

29/06/2026

CVE-2026-50017

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm can send user-level unscoped npm authentication credentials to a registry chosen by a repository-local .npmrc file. In the reproduced case, the user&#39;s npm config contains a default registry and an unscoped _authToken. The repository does not provide a token-bearing auth line. It only sets registry= to a different registry URL. During normal pnpm metadata/install workflows, pnpm binds the user-origin unscoped credential to the repository-selected registry and sends it as an Authorization header. This vulnerability is fixed in 10.34.0 and 11.4.0.

Gravedad CVSS v4.0: MEDIA

Última modificación:

30/06/2026

CVE-2026-48995

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** pnpm is a package manager. Prior to 10.33.4 and 11.0.7, a malicious codeload.github.com server can serve whatever tarball it wants and pnpm will install it regardless of the lockfile. The lockfile does not store the hash of the dependencies from https://codeload.github.com. This means that if this server was compromised or a person&#39;s machine configuration was compromised, pnpm would download and install these dependencies. This vulnerability is fixed in 10.33.4 and 11.0.7.

Gravedad CVSS v4.0: MEDIA

Última modificación:

29/06/2026

CVE-2026-49839

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** jq is a command-line JSON processor. Prior to 1.8.2,` jq --rawfile` can turn a handled oversized-string error into invalid-state reuse and a real heap out-of-bounds write in assertion-disabled builds. When jv_load_file(raw=1) reads an attacker-controlled file, it repeatedly appends file chunks to the same jv string accumulator. Once jv_string_append_buf() returns jv_invalid_with_msg("String too long"), the raw-file loop does not stop. If the file contains at least one more byte, the next loop iteration appends a new chunk to an object that is already invalid. With assertions enabled this aborts in jvp_string_ptr(). With assertions disabled, the invalid object is interpreted as a string object and ASan reports heap-buffer-overflow. This vulnerability is fixed in 1.8.2.

Gravedad CVSS v3.1: ALTA

Última modificación:

26/06/2026

CVE-2026-47770

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** jq is a command-line JSON processor. Prior to 1.8.2, comparing two sufficiently deeply nested arrays with the == operator exhausts the C stack on jq&#39;s ordinary command-line surface, resulting in denial of service via stack exhaustion (uncontrolled recursion). The crash occurs in jq&#39;s recursive structural comparison code, with the recursion repeating through jvp_array_equal() and jv_equal() in src/jv.c when comparing deeply nested arrays; a nearby sort comparator path through jv_cmp() in src/jv_aux.c overflows the stack at a larger nesting depth from the same missing recursion guard. Anyone running jq comparisons on attacker-controlled deeply nested JSON values, or embedding jq in a context where untrusted data can reach the == comparison path, is affected. This vulnerability is fixed in 1.8.2.

Gravedad CVSS v4.0: MEDIA

Última modificación:

26/06/2026

CVE-2026-11999

Fecha de publicación:

25/06/2026

Idioma:

Inglés

*** Pendiente de traducción *** X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_cert() returned success based only on the last verified link rather than on reaching a trust anchor: when the supplied chain is deeper than the verifier&#39;s maximum path depth (default 100), path building runs out of depth while still walking untrusted intermediates and the chain is accepted even though it never reaches a configured trust anchor, allowing acceptance of an attacker-controlled certificate. The default TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only applications doing manual or deferred verification through this API are.

Gravedad CVSS v4.0: ALTA

Última modificación:

26/06/2026

Suscribirse a Vulnerabilidades