CVE-2026-67214
nanoid (Nano ID) before 3.3.16 and 5.1.16 contains an infinite loop in the customAlphabet and nanoid functions of its non-secure module (nan
CVSS
5.9
Medio
EPSS
0.3%
p26
KEV
—
Exploit Today
8
0-100
Publicado: 29 jul 2026 · Última mod.: 26 ago 2026 · CWE-835
0.3%EPSS · 30 días0.3%
2026-08-172026-09-14
nanoid (Nano ID) before 3.3.16 and 5.1.16 contains an infinite loop in the customAlphabet and nanoid functions of its non-secure module (nanoid/non-secure). When these functions are given a negative size, the loop counter is decremented from a negative value and never reaches its termination condition, spinning indefinitely and hanging the calling thread. An application that passes an unvalidated, attacker-controlled negative size to these functions is exposed to a denial-of-service condition.
- github.comhttps://github.com/ai/nanoid/commit/6ccc67bbaba71d3d77a21d9b636f4171a268ce49
- github.comhttps://github.com/ai/nanoid/releases/tag/3.3.16
- github.comhttps://github.com/ai/nanoid/releases/tag/5.1.16
- www.vulncheck.comhttps://www.vulncheck.com/advisories/nanoid-before-infinite-loop-via-negative-size-in-non-secure-module
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-804895.9 MED—
——0Converting crafted EUC_JISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang.
Some EUC_JISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the EUC_JISX0213 character set is affected, which is not commonly used. The related defect in SHIFT_JISX0213 converter is tracked separately as CVE-2026-77117.7hCVE-2026-771175.9 MED—
——0Converting crafted SHIFT_JISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang.
Some SHIFT_JISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the SHIFT_JISX0213 character set is affected, which is not commonly used. The related defect in the EUC_JISX0213 converter is tracked separately as CVE-2026-80489.7hCVE-2026-159234.6 MED—
——0The Zephyr SDIO subsystem function sdio_io_rw_extended_helper() in subsys/sd/sdio.c finishes transfers with a byte-I/O loop that uses size = MIN(remaining, func->cis.max_blk_size) as the per-iteration step. The value func->cis.max_blk_size is decoded directly from the SDIO card's CIS FUNCE tuple in sdio_decode_cis() and is not validated. When a card reports a maximum block size of zero, size is always 0, remaining never decreases, and the loop spins forever.
The loop is reached from the public SDIO client API used by drivers, including sdio_read_fifo(), sdio_write_fifo(), and the incrementing register read/write helpers, each of which enters the loop while holding the per-card mutex func->card->lock. A card advertising max_blk_size == 0 therefore hangs the calling thread permanently on its first non-block-aligned transfer and never releases the mutex, denying service to the SDIO peripheral (and any subsystem such as Wi-Fi that depends on it) until the device is reset.
The malicious value must come from the SDIO card itself, so the defect is exploitable where a removable SDIO/combo card slot lets an attacker insert a crafted or malfunctioning card (a physical attack vector); on boards with a soldered SDIO peripheral it is not attacker-influenceable. There is no memory-safety, confidentiality, or integrity impact — only a permanent availability loss. The fix returns -EIO when func->cis.max_blk_size is zero, before the loop is entered.23hCVE-2023-373662.8 BAJ0.5%
——0An issue was discovered in Samsung Exynos Mobile Processor, Automotive Processor, and Modem Exynos 9810, Exynos 9610, Exynos 9820, Exynos 980, Exynos 850, Exynos 1080, Exynos 2100, Exynos 2200, Exynos 1280, Exynos 1380, Exynos 1330, Exynos 9110, Exynos W920, Exynos Modem 5123, Exynos Modem 5300, an Exynos Auto T5123. In the Shannon SM Task, improper handling of a loop with an unreachable exit condition cannot guarantee the termination of a required service via a malformed SM message.2dCVE-2026-781327.5 ALT23.5%
——7strongSwan 5.1.3 through 6.0.7 has an infinite loop in the x509 plugin's attribute certificate parser for ietfAttrSyntax.1dCVE-2026-781295.9 MED34.8%
——10strongSwan 4.6.2 through 6.0.7 has an infinite loop in PKCS#5 decryption.1d