CVE-2025-69418Medium· 4.0▾ SunlitIssue summary: When using the low-level OCB API directly with AES-NI or<br>other hardware-accelerated code paths, inputs whose length is not a multiple<br>of 16 bytes can leave the final partial block unencrypted and unauthenticated.<br>…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 22 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake. The CVSS score shown above comes from the CISA ADP record, not NVD.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via CVEORG
Last analysed / modified upstream
0.1%
Issue summary: When using the low-level OCB API directly with AES-NI or<br>other hardware-accelerated code paths, inputs whose length is not a multiple<br>of 16 bytes can leave the final partial block unencrypted and unauthenticated.<br><br>Impact summary: The trailing 1-15 bytes of a message may be exposed in<br>cleartext on encryption and are not covered by the authentication tag,<br>allowing an attacker to read or tamper with those bytes without detection.<br><br>The low-level OCB encrypt and decrypt routines in the hardware-accelerated<br>stream path process full 16-byte blocks but do not advance the input/output<br>pointers. The subsequent tail-handling code then operates on the original<br>base pointers, effectively reprocessing the beginning of the buffer while<br>leaving the actual trailing bytes unprocessed. The authentication checksum<br>also excludes the true tail bytes.<br><br>However, typical OpenSSL consumers using EVP are not affected because the<br>higher-level EVP and provider OCB implementations split inputs so that full<br>blocks and trailing partial blocks are processed in separate calls, avoiding<br>the problematic code path. Additionally, TLS does not use OCB ciphersuites.<br>The vulnerability only affects applications that call the low-level<br>CRYPTO_ocb128_encrypt() or CRYPTO_ocb128_decrypt() functions directly with<br>non-block-aligned lengths in a single call on hardware-accelerated builds.<br>For these reasons the issue was assessed as Low severity.<br><br>The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected<br>by this issue, as OCB mode is not a FIPS-approved algorithm.<br><br>OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.<br><br>OpenSSL 1.0.2 is not affected by this issue.
OpenSSL >= 3.6.0 < 3.6.1OpenSSL >= 3.5.0 < 3.5.5OpenSSL >= 3.4.0 < 3.4.4OpenSSL >= 3.3.0 < 3.3.6OpenSSL >= 3.0.0 < 3.0.19OpenSSL >= 1.1.1 < 1.1.1zeRefer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2025-68160Medium· 4.7Heap out-of-bounds write in BIO_f_linebuffer on short writes
CVE-2025-69419High· 7.4Out of bounds write in PKCS12_get_friendlyname() UTF-8 conversion
CVE-2025-69421High· 7.5NULL Pointer Dereference in PKCS12_item_decrypt_d2i_ex function
CVE-2025-69420High· 7.5Missing ASN1_TYPE validation in TS_RESP_verify_response() function
CVE-2026-22796Medium· 5.3ASN1_TYPE Type Confusion in the PKCS7_digest_from_attributes() function
CVE-2026-22795Medium· 5.5Missing ASN1_TYPE validation in PKCS#12 parsing