CVE WatchNov 10, 2026

CVE-2026-107496

Issue summary: Encrypting a CMS message to an EC certificate whose group order is 1 may cause CMS_encrypt() or CMS_encrypt_ex() to loop inde

CVSS

—

No CVSS

EPSS

—

KEV

—

Exploit Today

0-100

Published: Nov 10, 2026 · Last modified: Nov 10, 2026 · CWE-835

EPSS · 30d

Not enough EPSS history yet.

Technical description

Issue summary: Encrypting a CMS message to an EC certificate whose group order is 1 may cause CMS_encrypt() or CMS_encrypt_ex() to loop indefinitely. Impact summary: An attacker able to supply the recipient certificate to an application performing CMS encryption can cause that application to loop indefinitely, consuming CPU and resulting in Denial of Service. CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') Description: CMS_encrypt() and CMS_encrypt_ex() encrypt a message to one or more recipient certificates and, for an EC recipient, generate an ephemeral key in the recipient's group. If the certificate declares a group order of 1, random scalar generation can only produce zero. The key generation routine then retries without limit while waiting for a nonzero private scalar, so the call never returns. The OpenSSL TLS and QUIC implementations do not use this path. An application is exposed only if it calls CMS_encrypt() or CMS_encrypt_ex() with a recipient certificate whose EC parameters are attacker-controlled. Certificates with normal EC group orders do not trigger the loop. OpenSSL 4.0 and later reject unknown explicit EC groups in default builds. These versions are affected only when configured with the enable-ec_explicit_curves option. The result is a hang that consumes a CPU core until the process is interrupted, a Denial of Service. The severity is Low because the attacker must supply the recipient certificate and the application must choose to encrypt to it; ordinary CMS encryption to trusted recipients is unaffected. The fix makes EC key generation fail when the group has no valid nonzero private scalar, instead of retrying indefinitely. FIPS impact: no The FIPS modules in 4.1, 4.0, 3.5 and 3.0 are not affected. The FIPS provider does not support arbitrary explicit EC domain parameters, so an order-1 group is rejected during key import before the vulnerable key generation path is reached.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-55709—

—

——0Loop with unreachable exit condition ('infinite loop') in the MigTD's GetQuote for the Intel(R) TDX Migration Trust Domain (MigTD) within Ring 0: Hypervisor may allow a denial of service. System software adversary with an unauthenticated user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.5h CVE-2026-97402—

—

——0In Eclipse Kura versions 3.1.0 to 5.6.2, the iBeacon and Eddystone advertisement decoders wrongly parse the AD-structure length field of an over-the-air BLE advertising payload. Any unauthenticated attacker within BLE radio range can broadcast a two-byte advertising payload that drives the Kura beacon-scanner thread into a tight infinite loop, pinning a CPU core and permanently halting beacon ingestion until the gateway is restarted. To trigger the attack, the iBeacon/Eddystone scanner component should be installed and active. By default the components are not installed or enabled.7h CVE-2026-1097947.5 HIG

29.9%

——9SAP NetWeaver Application Server ABAP, ABAP Platform, and SAP Web Dispatcher do not sufficiently handle resource consumption when processing certain requests. An unauthenticated attacker could send specially crafted requests to the affected component, causing excessive resource utilization and service disruption. This results in a high impact on availability. There is no impact on confidentiality and integrity.22h CVE-2026-905854.6 MED

4.8%

——1The Renesas RA SCI UART driver's receive-error ISR, uart_ra_sci_eri_isr() in drivers/serial/uart_renesas_ra_sci.c, acknowledged the error condition only when a Zephyr interrupt-driven callback had already been registered. With CONFIG_UART_INTERRUPT_DRIVEN=y and CONFIG_UART_ASYNC_API=n, if data->user_cb is NULL the ISR body is empty: the SCI error flags (SSR.ORER, SSR.FER, SSR.PER) are left set and the ICU event flag R_ICU->IELSR_b[eri_irq].IR is never cleared, so the interrupt re-pends immediately and the ISR is re-entered without end. The error interrupt is masked at boot by uart_ra_sci_init(), but FSP's R_SCI_UART_Open() unconditionally re-enables it, and uart_ra_sci_configure() - the back end of the public uart_configure() API, enabled by default via CONFIG_UART_USE_RUNTIME_CONFIGURE - performs a Close()/Open() pair without re-masking it. Any runtime uart_configure() therefore leaves the error interrupt live regardless of whether a callback has been set, as does calling uart_irq_err_enable() on its own. An instance used with the polling API, or the window between uart_configure() and uart_irq_callback_user_data_set(), thus runs with the error interrupt unmasked and no callback registered. The trigger is an ordinary receive line error - overrun, framing, parity, or a break condition - which is fully determined by the device attached to the serial link. A peer able to assert a break or transmit at a mismatched baud rate produces such an error at will, so a single frame is enough to enter the state. The impact is availability only: the CPU is captured in the re-entering ISR and never returns to thread context, hanging the entire system until an external reset or hardware watchdog fires. There is no memory corruption or information disclosure. Builds using the asynchronous UART API are unaffected, because the fall-through to FSP's sci_uart_eri_isr() clears both the error flags and the pending IRQ.1d CVE-2026-1250735.5 MED

5.7%

——2FFmpeg through 9.0.2 contains an infinite loop vulnerability in bit_allocation() in libavcodec/imc.c that allows attackers to hang decoding by supplying audio blocks with a negative bit budget. Attackers can craft IMC or IAC audio files that drive freebits negative, causing the reduction loop to never terminate and consuming 100% CPU.1d CVE-2026-1236077.5 HIG

28.1%

——8Hickory DNS hickory-proto 0.25.0-alpha.3 through 0.25.2 and hickory-net before 0.26.1 contain an unbounded loop vulnerability in DnssecDnsHandle NSEC3 closest-encloser proof validation when the SOA owner is not an ancestor of the QNAME. Upstream attackers can return NoData or NXDomain responses with a cross-zone SOA record to panic debug builds or exhaust memory in release builds.3d