Search vulnerabilities

Results 248

Export CSV
CVE-2026-32148

Lockfile checksums not verified in Hex allows dependency integrity bypass

Insufficient Verification of Data Authenticity vulnerability in hexpm hex (Hex.RemoteConverger module) allows dependency integrity bypass via unverified lockfile checksums. Hex stores checksums for dependencies in the mix.lock file to ensure reproducible and integrity-checked builds. However, Hex.RemoteConverger.verify_resolved/2 never executes checksum verification because the lock data returned by Hex.Utils.lock/1 uses string-based dependency names, while the verification logic compares against atom-based names. This type mismatch causes the verification code path to be silently skipped. Checksums are still validated when packages are initially downloaded from the registry, but mismatches between the lockfile and resolved dependencies are not detected. An attacker who can influence cached packages (e.g., via local cache poisoning or a compromised registry) can provide modified dependency contents that will be accepted without detection. The mix.lock file is silently rewritten with the checksum values from the registry, erasing evidence of tampering. This issue affects hex: from 0.16.0 before 2.4.2.

CVSS 4.0 · 8.9 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-85632

Unauthenticated Payment Status Manipulation in Sipay Electronic Money's WordPress (WooCommerce)

Missing authentication for critical function and Improper validation of integrity check value vulnerability in Sipay Electronic Money and Payment Services Inc. WooCommerce Virtual POS Module allows Authentication Bypass and Application API Message Manipulation via Man-in-the-Middle. This issue affects WooCommerce Virtual POS Module: from 26.8.3 before 26.9.1.

CVSS 3.1 · 9.1 Critical EPSS < 1% KEV · Not listed
Vendors
—
Products
—
CVE-2026-118782

Forge: PKCS#12 MAC forgery and constant-key PBE via zero iteration count

Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge accepted a PKCS#12 MAC or PKCS#12 password-based encryption iteration count of zero or less. pki.pbe.generatePkcs12Key() then returned a constant key independent of the password and salt, allowing crafted PKCS#12 input processed by forge.pkcs12.pkcs12FromAsn1() to bypass password-based integrity checks. Predictable encryption keys and IVs also affected PKCS#12 PBE using pbeWithSHAAnd3-KeyTripleDES-CBC or pbewithSHAAnd40BitRC2-CBC, including shrouded key bags, encrypted SafeContents, and PKCS#8 ENCRYPTED PRIVATE KEY input processed independently by forge.pki.decryptPrivateKeyInfo(). PBES2/PBKDF2-encrypted content is unaffected. This issue is fixed in version 1.4.1.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-119186

Forge: AES-GCM authentication bypass via unvalidated tagLength option

Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge did not validate the AES-GCM tagLength option passed to start() during decryption through forge.cipher.createDecipher(). When an application derived tagLength from received data or used an unset or zero-like configuration value, a value that converted to zero together with an empty or missing authentication tag caused the calculated and supplied tags to compare as empty, so decipher.finish() accepted unauthenticated ciphertext. Applications that omit tagLength to use the 128-bit default or pass a fixed valid tag length are unaffected. This issue is fixed in version 1.4.1.

CVSS 3.1 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-120423

undici vulnerable to Subresource Integrity bypass via whitespace in integrity metadata

undici is an HTTP client for Node.js. In versions 7.15.0 through 7.30.1 and 8.0.0 through 8.12.3, fetch verifies Subresource Integrity metadata by splitting the integrity string on a single space, but the SRI grammar separates metadata by ASCII whitespace, which also includes the horizontal tab. An integrity value whose digest is preceded by a tab or other ASCII whitespace is parsed as a single unrecognized token and skipped, and when no recognized algorithm remains undici treats the integrity list as empty and accepts the response, so a server returning a body different from the pinned digest passes the check. An application that pins a response with a valid but whitespace-surrounded SRI value receives attacker-controlled bytes with no integrity error, and the attacker needs only to control the response body, not the integrity metadata. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later. As a workaround, supply SRI integrity metadata without surrounding whitespace, using a single space to separate multiple digests.

CVSS 3.1 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-107846

bitcoinjs-lib: Undetected merkle node duplication in block root computation validates a forged transaction list

bitcoinjs-lib is a JavaScript Bitcoin library for Node.js and browsers. From 2.3.0 until 5.2.1, 6.1.8, and 7.0.2, fastMerkleRoot pads odd Merkle-tree levels by hashing the final node with itself but does not report adjacent duplicate hashes. The affected block-root verifier was introduced as Block.checkMerkleRoot() alongside Block.calculateMerkleRoot(), while later versions expose validation through checkTxRoots() and __checkMerkleRoot; these validation paths can accept a recomputed root without checking for mutation. A peer can append duplicate transactions so a different transaction list retains the original Merkle root, block header, proof of work, and block identifier. Consumers that rely on block-root validation, including explorers, exchange indexers, or SPV clients, can process a duplicated transaction twice or blacklist the shared block hash and reject the honest block. This issue is fixed in versions 5.2.1, 6.1.8, and 7.0.2.

CVSS 4.0 · 9.3 Critical EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-111423

krb5: Improper authorization via flawed PAC checksum verification

In MIT krb5 release 1.21 and later, server applications will erroneously treat the PAC within a ticket as verified when the server checksum is invalid.

CVSS 3.1 · 4.2 Medium EPSS n/a KEV · Not listed
Vendors
—
Products
—
CVE-2026-71199

krb5: Alteration of authentication indicators in CAMMAC container

In MIT krb5 release 1.14 and later (since authentication indicator support was added), an authenticated attacker can bypass authentication indicator requirements using an unkeyed checksum in the CAMMAC authdata container.

CVSS 3.1 · 8.1 High EPSS n/a KEV · Not listed
Vendors
—
Products
—
CVE-2026-123317

Session Forgery via Tampered Encrypted Cookies in JetBrains Ktor

In JetBrains Ktor before 3.6.1 session forgery was possible via tampered encrypted session cookies

CVSS 3.1 · 8.1 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-45850

ipvs: skip ipv6 extension headers for csum checks

In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2024-3727

Containers/image: digest type does not guarantee valid type

A flaw was found in the github.com/containers/image library. This flaw allows attackers to trigger unexpected authenticated registry accesses on behalf of a victim user, causing resource exhaustion, local path traversal, and other attacks.

CVSS 3.1 · 8.3 High EPSS 1.3% KEV · Not listed
Vendors
CVE-2026-118776

Forge: Incomplete PKCS#7 padding validation in AES/DES CBC and ECB decryption

Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used decipher.finish(), CBC and ECB modes, PKCS#7 padding to process the relevant input or security decision. node-forge validated only the final byte of PKCS#7 padding during CBC and ECB decryption and accepted zero, oversized, or mismatched padding bytes. Malformed ciphertext could consequently be accepted and up to four plaintext blocks could be silently removed, causing an integrity failure in applications that treated successful decryption as proof of valid padding. This issue is fixed in version 1.4.1.

CVSS 3.1 · 3.7 Low EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-62374

SD JWT JS: Tampered disclosures silently dropped instead of rejected

SD JWT JS is a JavaScript implementation of the Selective Disclosure JWT (SD-JWT) specification. In version 0.19.0 and earlier, `@sd-jwt/decode`, also used by `@sd-jwt/core`, silently drops a tampered Disclosure whose digest no longer matches the Issuer-signed `_sd` array and returns a reduced claim set, reporting success while the Issuer signature remains valid. Both a tampered Disclosure that remains valid JSON and a Disclosure containing invalid UTF-8 bytes reach this silent-drop behavior. In the latter case, the `TextDecoder / Buffer` decoding path substitutes U+FFFD replacement characters, recovering syntactically valid disclosure data instead of rejecting the malformed input. This violates RFC 9901 section 7.1 step 5, which requires rejection of unreferenced Disclosures, and section 7.1 step 3 / section 4.2.1, which require rejection of invalid Disclosures. A malicious holder can exploit this omission primitive, including through `SDJwtInstance.verify()` when key binding is required. An on-path attacker can also tamper with a Disclosure when the relying party does not enforce key binding; enforced key binding rejects on-path tampering because it invalidates the KB-JWT `sd_hash` binding. If the relying party defaults to allowing access when a constraining age, role, or restriction claim is absent, the silent claim reduction can change an authorization decision without an error. This issue is fixed in `@sd-jwt/core` version 0.20.0; no patched version of the standalone `@sd-jwt/decode` package is identified.

CVSS 4.0 · 7.1 High EPSS < 1% KEV · Not listed
CVE-2026-50021

pnpm: Integrity Check Bypass via Missing Lockfile Integrity Field

pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm'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's npm ci enforces integrity by default; pnpm'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.

CVSS 3.1 · 6.8 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-85243

Apache Camel: Camel-Crypto-PGP Integrity Verification Downgrade via Attacker-Controlled Message Structure

Improper Validation of Integrity Check Value vulnerability in Apache Camel Crypto PGP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. unmarshal() verified the modification detection code only when the message was an OpenPGP symmetrically encrypted integrity protected data packet. The older symmetrically encrypted data packet carries no such code, and OpenPGP's CFB mode is malleable without one, so a message using that packet skipped the check altogether. The packet type is chosen by whoever produced the message, which left the sender - or anyone able to rewrite the message in transit - deciding whether the integrity check applied at all. The existing integrity option governs marshalling only and had no decrypt-side counterpart, so a deployment could not require integrity protection on the messages it accepted. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerificationOption still defaults to optional, so a message carrying no signature is accepted; the two options together are what give a decrypted message authenticity and not only confidentiality. For deployments that cannot upgrade immediately, reject messages that do not use the integrity protected packet before they reach the data format. Routes that must interoperate with a sender still emitting the legacy packet should set requireIntegrityProtection=false after upgrading, and treat the decrypted content as unauthenticated.

CVSS 3.1 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-65625

Attacker-controlled AES-GCM authentication tag length allows tag forgery in jose

The pure-Erlang AES-GCM fallback in jose_jwa_aes derives the number of verified authentication tag bits from the attacker-supplied tag itself. In the {aes_gcm, Bits} clause of block_decrypt/4, the incoming tag is guarded only by is_binary/1, with no check on its length. Verification in gcm_block_decrypt/6 then computes TBits = bit_size(T) and compares only those bits of the real 128-bit tag. An attacker who controls a JWE token can truncate the authentication tag to as little as 8 bits, so only 8 bits are ever checked. This reduces forgery resistance from 2^-128 to 2^-8, and a forged ciphertext is reliably accepted as authentic within 256 attempts without knowledge of the key (an authentication tag forgery and integrity bypass). Supplying a tag longer than 128 bits instead causes a badmatch that crashes the decrypting process. The fallback is reached through the public JWE decryption path whenever AES-GCM is not provided by a native crypto NIF, for example on FIPS or stripped or older OTP builds. This issue affects jose: from 1.2.0 before 1.11.13.

CVSS 4.0 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-116608

DAMO Academy VideoLLaMA2 Model Loading __init__.py load_pretrained_model integrity check

A security vulnerability has been detected in DAMO Academy VideoLLaMA2 up to 1.1. Affected by this issue is the function load_pretrained_model of the file videollama2/model/__init__.py of the component Model Loading. The manipulation of the argument _name_or_path leads to improper validation of integrity check value. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. The project was informed of the problem early through an issue report but has not responded yet.

CVSS 4.0 · 5.3 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-89320

HmacShaCryptor.Hash never hashes its input — returns constant HMAC_K("") for all inputs, voiding CBC-HMAC JWE integrity

`HmacShaCryptor.Hash` never hashed its input. For any input it returned `HMAC_K("")` — the MAC of the empty message under the key. Every AES-CBC-HMAC JWE produced or verified by gose therefore carried an authentication tag that is constant per key and independent of the message, removing ciphertext integrity entirely.

CVSS 4.0 · 8.8 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-115906

zip: AES Entry HMAC Authentication Bypass on Premature EOF

zip is a zip library for Rust that supports reading and writing simple ZIP files. From 0.6.0 until 9.0.0, the AES entry reader in src/aes.rs verifies its HMAC only when the attacker-controlled data counter reaches zero. If the underlying bounded reader reaches the real end of the archive while data_remaining is still positive, or if an encrypted entry has no payload, the reader can return a clean end of stream without reading and comparing the authentication tag. Applications using by_index_decrypt, by_name_decrypt, by_path_decrypt, or password-enabled by_index_with_options can therefore accept modified plaintext without an authentication error. This issue is fixed in version 9.0.0.

CVSS 3.1 · 6.5 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-72398

sctp: add INIT verification after cookie unpacking

In the Linux kernel, the following vulnerability has been resolved: sctp: add INIT verification after cookie unpacking In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk. When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe. However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data. Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded. Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk. Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors
Products