{ "query": { "page": "7", "q": "openssl" }, "count": 20, "total": 163, "page": 7, "limit": 20, "updated": { "cves": "2026-10-06T08:45:32.201Z", "kev": "2026-10-06T08:44:32.120Z", "epss": "2026-10-06T06:57:27.860Z", "breaches": "2026-10-06T06:45:27.314Z", "posts": "2026-10-06T08:45:32.201Z" }, "links": { "web": "https://spydr.io/threats?page=7&q=openssl", "next": "https://spydr.io/threats.json?page=8&q=openssl" }, "warnings": [], "results": [ { "id": "CVE-2026-14663", "url": "https://spydr.io/cve/CVE-2026-14663", "published": "2026-08-13T13:17:43.700Z", "modified": "2026-08-29T23:17:11.530Z", "score": 6.5, "severity": "medium", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N", "score_source": "CNA", "epss": 0.00096, "epss_percentile": 0.00659, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "postgresql" ], "products": [ "PostgreSQL" ], "cwes": [ "CWE-313", "CWE-345" ], "description": "Cleartext storage in PostgreSQL pgcrypto disabled ciphers allows a user to recover cleartext, via direct observation of the faulty ciphertext. The OpenSSL version and OpenSSL configuration determine the disabled ciphers. If the application accepts encrypted data as input, decryption will succeed even with the wrong key. This in turn loses the modest protection from the Modification Detection Code (MDC). Affected functions are pgp_sym_encrypt, pgp_sym_decrypt, pgp_pub_encrypt, pgp_pub_decrypt, pgp_sym_encrypt_bytea, pgp_sym_decrypt_bytea, pgp_pub_encrypt_bytea, and pgp_pub_decrypt_bytea. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected." }, { "id": "CVE-2026-34182", "url": "https://spydr.io/cve/CVE-2026-34182", "published": "2026-06-09T17:17:04.857Z", "modified": "2026-07-23T08:10:00.137Z", "score": 9.1, "severity": "critical", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N", "score_source": "CISA ADP", "epss": 0.01057, "epss_percentile": 0.63259, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "OpenSSL" ], "products": [ "OpenSSL" ], "cwes": [ "CWE-354" ], "description": "Issue Summary: Cryptographic Message Services (CMS) processing fails to perform sufficient input validation on the cipher and tag length fields of AuthEnvelopedData containers, leading to various potential compromises. Impact Summary: Attackers making use of these vulnerabilities may achieve key-equivalent functionality for a given CMS recipient and/or bypass integrity validation for a given message. In one use case, an attacker may send a CMS message containing AuthEnvelopedData with the cipher specified as a non-AEAD cipher. OpenSSL erroneously allows this selection, and attempts to decrypt and validate the message. An on-path attacker who captures one legitimate AES-GCM AuthEnvelopedData addressed to the victim can re-emit it with the recipientInfos set left byte-for-byte intact, so the victim's private key still unwraps the genuine CEK (the content-encryption key), but with the inner OID rewritten to AES-256-OFB (Output Feedback Mode, an unauthenticated keystream mode) and with an attacker-chosen IV and ciphertext. The victim initializes AES-256-OFB under the real CEK, never consults the MAC field, and CMS_decrypt() returns success. If the application under attack responds to the attacker with any indicator showing success or failure of the decryption effort, it is possible for the attacker to use this as an oracle to obtain key equivalent functionality for the CEK used for the chosen recipient of the message. In another use case, an attacker can reduce the tag length of the chosen AEAD cipher for a given AuthEnvelopedData container to be a single byte long, allowing an attacker to brute force CMS decryption, producing an integrity bypass for applications that trust CMS_decrypt() to reject modified content. The FIPS modules are not affected by this issue." }, { "id": "CVE-2026-75806", "url": "https://spydr.io/cve/CVE-2026-75806", "published": "2026-09-29T16:17:11.217Z", "modified": "2026-09-29T21:27:41.130Z", "score": 5.3, "severity": "medium", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L", "score_source": "CISA ADP", "epss": 0.00387, "epss_percentile": 0.30428, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "OpenSSL" ], "products": [ "OpenSSL" ], "cwes": [ "CWE-1284" ], "description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary." }, { "id": "CVE-2026-77131", "url": "https://spydr.io/cve/CVE-2026-77131", "published": "2026-08-25T09:17:33.527Z", "modified": "2026-08-26T17:13:53.420Z", "score": 5.3, "severity": "medium", "cvss_version": "4.0", "vector": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "score_source": "CNA", "epss": 0.00244, "epss_percentile": 0.14151, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "TYPO3" ], "products": [ "TYPO3 Extension \"SYSSY - TYPO3 Monitoring & Security Checks\"" ], "cwes": [ "CWE-319" ], "description": "When OpenSSL is unavailable on the server, the extension transmits TYPO3 system information in cleartext instead of encrypting it. Exploitation requires the attacker to already be in control of the SYSSY project's API key." }, { "id": "CVE-2026-9076", "url": "https://spydr.io/cve/CVE-2026-9076", "published": "2026-06-09T17:17:50.997Z", "modified": "2026-07-23T08:10:00.137Z", "score": 7.5, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "score_source": "CISA ADP", "epss": 0.00973, "epss_percentile": 0.60679, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "OpenSSL" ], "products": [ "OpenSSL" ], "cwes": [ "CWE-125" ], "description": "Issue summary: When CMS password-based decryption (RFC 3211 / PWRI key unwrap) processes attacker-supplied CMS data, an attacker-chosen stream-mode KEK cipher can trigger a heap out-of-bounds read in kek_unwrap_key(). Impact summary: A heap buffer over-read may trigger a crash which leads to Denial of Service for an application if the input buffer ends at a memory page boundary and the following page is unmapped. There is no information disclosure as the over-read bytes are not revealed to the attacker. The key unwrapping function performs a check-byte test as specified in the RFC that reads 7 bytes from a heap allocation that is based on the wrapped key length from the message. There is a minimum length check based on the block length of the wrapping cipher. However the cipher is selected from an OID carried in the attacker's PWRI keyEncryptionAlgorithm with no requirement that the cipher be a block cipher. When an attacker selects a stream-mode cipher the guard will be ineffective and the allocated buffer containing the unwrapped key can be too small to fit the check-bytes specified in the RFC and a buffer over-read can happen. Applications calling CMS_decrypt() or CMS_decrypt_set1_password() (equivalently openssl cms -decrypt -pwri_password ...) on untrusted CMS data are vulnerable to this issue. No password knowledge is required: the over-read happens during the unwrap attempt before any authentication succeeds. The over-read is limited to a few bytes and is not written to output, so there is no information disclosure. Triggering a crash requires the allocation to border unmapped memory, which is unlikely with the normal allocator. The FIPS modules are not affected by this issue." }, { "id": "CVE-2026-42769", "url": "https://spydr.io/cve/CVE-2026-42769", "published": "2026-06-09T17:17:08.377Z", "modified": "2026-07-23T08:10:00.137Z", "score": 5.3, "severity": "medium", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N", "score_source": "CISA ADP", "epss": 0.00239, "epss_percentile": 0.13553, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "OpenSSL" ], "products": [ "OpenSSL" ], "cwes": [ "CWE-295" ], "description": "Issue Summary: An error in the callback used to verify the certificate provided in a Root CA key update Certificate Management Protocol (CMP) message response rendered the certificate validation ineffectual, which could lead to escalation of credentials from the Registration Authority (RA) level to the root Certification Authority (root CA) level. Impact Summary: The Registration Autority could replace the root CA certificate for the CMP clients with an arbitrary root CA certificate. One of the parts of the Certificate Management Protocol (CMP), specified in RFC 9810, is Root Certification Authority (root CA) key Rollover, which is sent by the server in a message with type 'id-it-rootCaKeyUpdate'. As part of these messages, 'newWithOld' certificate, the new root CA certificate signed with the old root CA key, is provided, and verifying its signature is crucial for transferring the trust from the old CA key to the new one. The 'id-it-rootCaKeyUpdate' messages are expected to be processed with OSSL_CMP_get1_rootCaKeyUpdate(), that is expected to verify the 'newWithOld' certificate. A typo in the certificate chain building code led to adding an incorrect certificate ('newWithOld' instead of 'oldRoot') to the certificate chain, rendering the certificate verification process ineffectual (only the issuer name and the algorithm OIDs were verified by other parts of the verification code). An attacker who already has credentials that satisfy the CMP message protection checks can generate a new key pair and use a crafted self-signed certificate in its 'id-it-rootCaKeyUpdate' CMP messages which affected CMP clients would accept as a new trust anchor. Significant preconditions for the attack (having valid RA-level credentials) are the reason the issue was assigned Low severity. The FIPS modules are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary." }, { "id": "CVE-2026-45447", "url": "https://spydr.io/cve/CVE-2026-45447", "published": "2026-06-09T17:17:19.277Z", "modified": "2026-09-18T13:18:26.343Z", "score": 8.8, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "score_source": "CISA ADP", "epss": 0.04002, "epss_percentile": 0.90239, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "OpenSSL", "Red Hat" ], "products": [ "OpenSSL", "Red Hat Enterprise Linux 10", "Red Hat Enterprise Linux 6 Extended Lifecycle Support - EXTENSION", "Red Hat Enterprise Linux 7 Extended Lifecycle Support", "Red Hat Enterprise Linux 8", "Red Hat Enterprise Linux 8.6 Extended Update Support Long-Life Add-On", "Red Hat Enterprise Linux 8.8 Telecommunications Update Service", "Red Hat Enterprise Linux 8.8 Update Services for SAP Solutions", "Red Hat Enterprise Linux 9", "Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions", "Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions", "Red Hat Enterprise Linux 9.6 Extended Update Support", "Red Hat OpenShift Container Platform 4.12", "Red Hat Cost Management 4", "Red Hat multicluster engine for Kubernetes 2.8", "Red Hat Advanced Cluster Management for Kubernetes 2.13", "Red Hat Discovery 2", "Red Hat Insights proxy 1.5", "Red Hat Update Infrastructure 5", "Red Hat Multicluster Engine for Kubernetes" ], "cwes": [ "CWE-416", "CWE-825" ], "description": "Issue summary: A specially crafted PKCS#7 or S/MIME signed message could trigger a use-after-free during PKCS#7 signature verification. Impact summary: A use-after-free may result in process crashes, heap corruption, or potentially remote code execution. When processing a PKCS#7 or S/MIME signed message, if the SignedData digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may incorrectly free a caller-owned BIO during PKCS7_verify(). A subsequent use of the BIO by the calling application results in a use-after-free condition. In the common case this occurs when the application later calls BIO_free() on the BIO originally passed to PKCS7_verify(). Depending on allocator behavior and application-specific BIO usage patterns, this may result in a crash or other memory corruption. In some application contexts this may potentially be exploitable for remote code execution. Applications that process PKCS#7 or S/MIME signed messages using OpenSSL PKCS#7 APIs may be affected. Applications using the CMS APIs for this processing are not affected. The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary." }, { "id": "CVE-2026-90439", "url": "https://spydr.io/cve/CVE-2026-90439", "published": "2026-09-15T15:17:27.023Z", "modified": "2026-09-18T19:34:36.657Z", "score": 6.9, "severity": "medium", "cvss_version": "4.0", "vector": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "score_source": "f5.com", "epss": 0.00256, "epss_percentile": 0.15721, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "F5" ], "products": [ "F5 NGINX Plus", "F5 NGINX Open Source" ], "cwes": [ "CWE-122" ], "description": "NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_v3_module module. When using HTTP/3 with OpenSSL versions <= OpenSSL 3.5.0 under certain configurations, a limited heap buffer overflow could happen while processing a TLS handshake. This can happen in a non-deterministic manner that is beyond the attacker's control. This may cause a heap buffer overflow in the NGINX worker process leading to a restart and/or limited data corruption. Impact: This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or limited data corruption. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated." }, { "id": "CVE-2026-11310", "url": "https://spydr.io/cve/CVE-2026-11310", "published": "2026-06-25T20:17:09.777Z", "modified": "2026-06-26T18:54:51.247Z", "score": 8.7, "severity": "high", "cvss_version": "4.0", "vector": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "score_source": "wolfssl.com", "epss": 0.00234, "epss_percentile": 0.13016, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "wolfSSL" ], "products": [ "wolfSSL" ], "cwes": [ "CWE-295" ], "description": "X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts." }, { "id": "CVE-2026-42768", "url": "https://spydr.io/cve/CVE-2026-42768", "published": "2026-06-09T17:17:08.223Z", "modified": "2026-07-23T08:10:00.137Z", "score": 3.7, "severity": "low", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N", "score_source": "CISA ADP", "epss": 0.00295, "epss_percentile": 0.20136, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "OpenSSL" ], "products": [ "OpenSSL" ], "cwes": [ "CWE-514" ], "description": "Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to Bleichenbacher-style attack when an attacker is able to provide the CMS or S/MIME messages and observe the error code and/or decryption output. Impact summary: The Bleichenbacher-style attack allows an attacker to use the victim's vulnerable application as a way to decrypt or sign messages with the victim's private RSA key. The attack is possible in 2 variants. 1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without providing the recipient certificate. In this case OpenSSL iterates over every KeyTransRecipientInfo (KTRI) without stopping at the first success. An attacker who authors a message with two KTRI entries — the first one wrapping a real CEK under the victim's public key, the second with an arbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to get a valid PKCS#1 v1.5 padding if the error code of the application is available. That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an adaptive-chosen-ciphertext side channel from which the attacker decrypts any RSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under it. 2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with the recipient certificate, and the recipient is not found, a random key is substituted. An attacker who authors a message and is able to compare both error code and the result of the decryption, can mount a Bleichenbacher oracle. We are not aware of any applications that provide a remote attacker an opportunity to mount an attack described in these scenarios. We consider the existence of such application very unlikely, and for this reason this CVE has been evaluated as Low severity. To avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the invoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit rejection was explicitly disabled. The implicit rejection mechanism always returns a plaintext value, the symmetric key. This result is deterministic for the ciphertext and the private key. The length of the decryption result can happen to match the length of the key of the symmetric cipher that was used for the content encryption. When a certificate is not provided, the last RecipientInfo producing a key that looks valid will be used. It may cause getting garbage content on decryption. As a proper way to deal with this a recipient certificate has to be provided to identify the particular RecipientInfo for decryption. The FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as CMS and S/MIME processing happens outside the OpenSSL FIPS module boundary." }, { "id": "CVE-2026-15981", "url": "https://spydr.io/cve/CVE-2026-15981", "published": "2026-07-23T21:17:03.220Z", "modified": "2026-07-24T23:16:50.257Z", "score": 9.8, "severity": "critical", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "score_source": "wordfence.com", "epss": 0.01877, "epss_percentile": 0.78702, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "cyberlord92" ], "products": [ "cyberlord92 SAML Single Sign On – SSO Login" ], "cwes": [ "CWE-287" ], "description": "The SAML Single Sign On – SSO Login plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 5.4.4. This is due to the mo_saml_validate_signature() function performing a loose boolean check on the raw tri-state integer returned by PHP's openssl_verify(), causing an error return value of -1 to be evaluated as truthy and therefore treated as a successful signature verification. This makes it possible for unauthenticated attackers to log in as any existing WordPress user, including administrators, by submitting a crafted SAMLResponse containing an attacker-controlled NameID and a deliberately malformed signature value that triggers an OpenSSL processing error — bypassing verification entirely and resulting in wp_set_auth_cookie() being called for the targeted account." }, { "id": "CVE-2026-84782", "url": "https://spydr.io/cve/CVE-2026-84782", "published": "2026-09-29T16:17:12.500Z", "modified": "2026-09-29T21:27:41.130Z", "score": 8.2, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H", "score_source": "CISA ADP", "epss": 0.0039, "epss_percentile": 0.30838, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "OpenSSL" ], "products": [ "OpenSSL" ], "cwes": [ "CWE-125" ], "description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary." }, { "id": "CVE-2026-42770", "url": "https://spydr.io/cve/CVE-2026-42770", "published": "2026-06-09T17:17:08.523Z", "modified": "2026-07-23T08:10:00.137Z", "score": 3.7, "severity": "low", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N", "score_source": "CISA ADP", "epss": 0.00258, "epss_percentile": 0.15854, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "OpenSSL" ], "products": [ "OpenSSL" ], "cwes": [ "CWE-325" ], "description": "Issue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the peer key is not properly checked for the subgroup membership. Impact summary: A malicious peer which presents an X9.42 key carrying the victim's p and g parameters, a forged q = r (a small prime factor of the cofactor (p−1)/q_local), and a public value Y of order r can recover the victim's private key after a small number of key exchange attempts. When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the subgroup membership check Y^q ≡ 1 (mod p) is performed using the peer's own q parameter, not the local key's q. The peer's domain parameters are then matched against the domain parameters of the private key, but the value of q is not compared. A malicious peer who presents an X9.42 key carrying the victim's p, g, a forged q = r (a small prime factor of the cofactor), and a public value Y of order r passes all checks. The shared secret then takes only r distinct values, leaking priv mod r. Repeating for each small-prime factor of the cofactor and combining via CRT recovers the full private key (Lim–Lee / small-subgroup-confinement attack). The realistic attack surface is narrow: principally CMP deployments with long-lived RA/CA DHX keys and bespoke enterprise or government applications using X9.42 DHX static keys with interactive protocols and therefore this issue was assigned Low severity. The FIPS modules in 4.0, 3.6, 3.5, 3.4, 3.1.2 and 3.0 are affected by this issue." }, { "id": "CVE-2026-72897", "url": "https://spydr.io/cve/CVE-2026-72897", "published": "2026-09-29T16:17:09.903Z", "modified": "2026-09-29T21:27:41.130Z", "score": 7.5, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "score_source": "CISA ADP", "epss": 0.00266, "epss_percentile": 0.16795, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "OpenSSL" ], "products": [ "OpenSSL" ], "cwes": [ "CWE-787" ], "description": "Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX part way through a handshake may access memory beyond the end of an internal array if the replacement context knows about more provider signature algorithms than the context the connection was created from. Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context was aware of. That count sizes an internal array of per-slot certificate validity flags. An application may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh the recorded count. A provider signature algorithm's slot index is its position in the list of whichever context resolves it, so if the replacement context is aware of more of them than the original, an algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's signature algorithms then reads one four byte word past the end for each such algorithm and, where the word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which the server also has configured, have this effect. Codepoints the replacement context does not recognise are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS 1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which requires separate library contexts, a provider loaded between the two being created, or providers which differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms with legitimate clients, since the same stale count hides the corresponding certificates, so the misconfiguration is likely to be noticed. For that reason, and because the configuration is not the default, this issue has been assessed as Low severity. FIPS impact: no No FIPS modules are affected by this issue as the affected code is outside the OpenSSL FIPS module boundary." }, { "id": "CVE-2026-11999", "url": "https://spydr.io/cve/CVE-2026-11999", "published": "2026-06-25T18:16:37.613Z", "modified": "2026-06-26T16:50:28.077Z", "score": 8.2, "severity": "high", "cvss_version": "4.0", "vector": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "score_source": "wolfssl.com", "epss": 0.00234, "epss_percentile": 0.13016, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "wolfSSL" ], "products": [ "wolfSSL" ], "cwes": [ "CWE-295" ], "description": "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'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." }, { "id": "CVE-2026-84964", "url": "https://spydr.io/cve/CVE-2026-84964", "published": "2026-09-03T16:18:25.270Z", "modified": "2026-09-22T16:19:25.187Z", "score": 8.2, "severity": "high", "cvss_version": "4.0", "vector": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "score_source": "mongodb.com", "epss": 0.00257, "epss_percentile": 0.15754, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "MongoDB" ], "products": [ "MongoDB C Driver" ], "cwes": [ "CWE-415" ], "description": "A double free in the OpenSSL-based TLS certificate revocation checking path of the MongoDB C Driver can be reached by a TLS endpoint that the client already trusts. During the handshake, specially formed certificate data can cause the same heap object to be released twice. An unauthenticated party acting as the trusted endpoint may cause the connecting client application to terminate unexpectedly." }, { "id": "CVE-2026-91769", "url": "https://spydr.io/cve/CVE-2026-91769", "published": "2026-09-25T21:17:24.913Z", "modified": "2026-09-29T21:27:41.130Z", "score": 4.3, "severity": "medium", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N", "score_source": "php.net", "epss": 0.00135, "epss_percentile": 0.02516, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "PHP Group" ], "products": [ "PHP Group PHP" ], "cwes": [ "CWE-297" ], "description": "PHP's OpenSSL stream peer verification checks the certificate's subjectAltName entries first and, whenever no entry matches, falls back to the Common Name. RFC 6125 requires the CN to be ignored once the certificate presents any service identity, so a certificate carrying a non-matching DNS SAN was still accepted when its CN matched the requested peer_name. A certificate trusted by the client for one name can therefore be used to impersonate another." }, { "id": "CVE-2026-59847", "url": "https://spydr.io/cve/CVE-2026-59847", "published": "2026-07-21T14:16:34.657Z", "modified": "2026-09-04T19:23:04.510Z", "score": 7.5, "severity": "high", "cvss_version": "3.1", "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N", "score_source": "NVD", "epss": 0.00332, "epss_percentile": 0.24207, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "Red Hat" ], "products": [ "Red Hat Enterprise Linux 10", "Red Hat Enterprise Linux 8", "Red Hat Enterprise Linux 9", "Red Hat Hardened Images" ], "cwes": [ "CWE-253", "CWE-1310" ], "description": "A flaw was found in libssh. Incorrect AES-GCM finalization checks in builds using the OpenSSL backend can effectively remove integrity protection, allowing an in-path attacker to modify plaintext on the wire without detection." }, { "id": "CVE-2026-70454", "url": "https://spydr.io/cve/CVE-2026-70454", "published": "2026-08-13T15:19:59.047Z", "modified": "2026-09-08T20:28:37.587Z", "score": 7.6, "severity": "high", "cvss_version": "4.0", "vector": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "score_source": "vulncheck.com", "epss": 0.0019, "epss_percentile": 0.07787, "exploited": false, "kev": null, "ssvc_exploitation": "none", "vendors": [ "RsyncProject" ], "products": [ "RsyncProject rsync" ], "cwes": [ "CWE-295" ], "description": "rsync 3.2.0 through 3.2.3 (openssl mode) and rsync-ssl through 3.4.4 (stunnel mode) contain a TLS certificate validation vulnerability that allows on-path attackers to intercept encrypted sessions by presenting self-signed or otherwise invalid certificates. Attackers can exploit the failure to validate server TLS certificates against a trusted CA or verify certificate hostname matching to decrypt or tamper with rsync session content without detection by the client." }, { "id": "CVE-2026-6958", "url": "https://spydr.io/cve/CVE-2026-6958", "published": "2026-09-04T15:17:35.360Z", "modified": "2026-09-24T20:43:32.537Z", "score": 8.5, "severity": "high", "cvss_version": "4.0", "vector": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "score_source": "vulncheck.com", "epss": 0.00175, "epss_percentile": 0.06368, "exploited": false, "kev": null, "ssvc_exploitation": "poc", "vendors": [ "Invicti Security Corp." ], "products": [ "Invicti Security Corp. Acunetix" ], "cwes": [ "CWE-427" ], "description": "Acunetix 25.11.251107123 for Windows contains a local privilege escalation vulnerability in the Web Vulnerability Scanning Engine (wvsc.exe) that allows low-privileged local attackers to execute arbitrary code as SYSTEM by exploiting a missing hardcoded directory path for OpenSSL-related files. Attackers can create the missing directory, place a malicious file at the expected path, and cause the SYSTEM-level wvsc.exe process to load and execute it, resulting in full privilege escalation." } ], "attribution": [ { "source": "NVD", "url": "https://nvd.nist.gov", "notice": "This product uses data from the NVD API but is not endorsed or certified by the NVD." }, { "source": "CISA KEV", "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog", "notice": "Known exploited vulnerabilities from the CISA KEV catalog." }, { "source": "FIRST EPSS", "url": "https://www.first.org/epss", "notice": "Exploit prediction scores from FIRST EPSS." } ] }