CVE-2026-11478: Inefficient Regex Complexity in kokke tiny-regex-c

Technical summary

The vulnerability exists in the matchstar function within re.c of kokke's tiny-regex-c component, which handles pattern matching logic. The flaw introduces inefficient regex complexity (ReDoS-like behavior) that does not involve input validation bypass or logic errors, but rather algorithmic weakness under specific pattern conditions. The CVSS 3.1 score of 3.3 reflects the low attack surface (local-only, low privilege requirement) and limited impact scope (availability only, no confidentiality or integrity breach). The vulnerability is categorized under CWE-1333 (Inefficient Regular Expression Complexity) and CWE-400 (Uncontrolled Resource Consumption), both of which relate to algorithmic complexity abuse rather than memory safety or injection flaws.

Business impact

For teams integrating tiny-regex-c into local tools, build systems, or embedded applications, this vulnerability poses a localized availability risk. If an application accepts regex patterns from untrusted local sources—such as configuration files uploaded by users with limited privilege, or dynamically constructed patterns from log parsing utilities—an attacker can cause the regex engine to consume excessive CPU, triggering service degradation or timeout-based crashes. The impact is typically contained to the affected process rather than system-wide, making it a low-priority fix unless the library is used in performance-critical services that must remain responsive under adversarial input.

Affected systems

The kokke tiny-regex-c library is a lightweight, standalone regex implementation used in embedded systems, IoT devices, and resource-constrained environments where full POSIX regex libraries are impractical. The vulnerability affects all versions up to commit f2632c6d9ed25272987471cdb8b70395c2460bdb. Because the project uses rolling releases rather than versioned builds, affected and patched releases cannot be specified precisely; consumers must verify their exact commit hash against the project repository to determine exposure. Any application or firmware bundle that includes tiny-regex-c compiled from an affected commit is potentially vulnerable if it processes regex input from users or lower-privilege accounts.

Exploitability

The exploit has been publicly disclosed, lowering the barrier to practical attack. However, exploitation remains constrained by three factors: it requires local system access (not remote), it demands at least user-level privilege (not full elevation), and it necessitates the ability to supply a malicious regex pattern to the vulnerable function. In typical deployment scenarios, this combination is uncommon unless the application explicitly exposes regex input to unprivileged users or untrusted local files. Organizations running tiny-regex-c in isolated, trusted-input-only contexts face minimal practical risk; those accepting patterns from multi-tenant or partially-trusted local sources should prioritize patching.

Remediation

Teams using tiny-regex-c should monitor the project's repository for an updated commit that addresses the matchstar inefficiency. Given the rolling-release model, there is no named version number to target; instead, pull the latest main branch commit and validate it resolves the issue. Alternatively, implement input validation to reject or throttle regex patterns of excessive length or complexity before passing them to the library, or migrate to a sandboxed regex processor that can be killed if it exceeds a CPU time budget. Document the specific commit hash of any deployed version to enable rapid assessment if this or future vulnerabilities emerge.

Patch guidance

Verify the latest commit on the kokke tiny-regex-c repository main branch for any fix addressing the matchstar function. Because the project has not yet responded to the early notification and no official patch commit is recorded, contact the maintainers or monitor the repository for updates. When a fix becomes available, test it in a staging environment to confirm the regex complexity inefficiency is resolved and that legitimate regex patterns continue to function correctly. Pin your dependency to a specific (later) commit hash rather than relying on floating version references, to prevent accidental regression if the repository ever reverts a patch.

Detection guidance

Monitor local process CPU and memory usage for applications using tiny-regex-c, particularly during periods when regex patterns are supplied by users or external sources. Look for sudden CPU spikes or sustained high CPU usage coinciding with regex compilation or matching operations. If you have application logs, search for patterns indicating regex processing delays or timeouts. At the code level, use static analysis tools to identify where tiny-regex-c's regex functions are called with unsanitized user input. Code review and threat modeling should highlight any code path where an unprivileged user or local process can influence the regex pattern passed to matchstar.

Why prioritize this

This vulnerability should be prioritized based on your exposure to local, unprivileged users. If tiny-regex-c is embedded in a single-user tool, appliance firmware, or a service that only processes trusted, administrator-defined regex patterns, the risk is acceptably low and patching can be deferred to routine maintenance windows. If the library is used in any application that accepts regex patterns from unprivileged users, multi-tenant environments, or untrusted configuration sources, elevate the priority to medium and schedule a patch within your next planned release cycle. The low CVSS score (3.3) should not be overridden by false urgency, but neither should it mask real business risk in high-exposure deployments.

Risk score, explained

The CVSS 3.1 score of 3.3 (LOW) reflects a narrow attack surface and limited damage. The local-only attack vector (AV:L) and requirement for low privilege (PR:L) eliminate remote exploitation and require at least user-level access. The complexity is low (AC:L), meaning once an attacker has local access, crafting a malicious regex is straightforward. No confidentiality or integrity impact is possible (C:N, I:N); only availability is affected (A:L). The vulnerability is not in the KEV catalog, indicating no evidence of widespread exploitation in the wild. Organizations should treat a 3.3 score as a genuine but containable risk rather than an immediate crisis—the threat is real only if your deployment model allows local users or processes to control regex input.

Frequently asked questions