CVE-2026-121707: 
JavaScript vulnerability analysis and mitigation

CVE-2026-121707 is a Regular Expression Denial of Service (ReDoS) vulnerability in the Schema.TemplateLiteral component of the effect npm package. When a template literal schema contains two or more Schema.String spans, the compiled regular expression includes multiple ambiguous wildcards ([\s\S]*?), causing the backtracking engine to exhibit cubic time complexity on non-matching inputs. A 5,000-character malicious string can block the Node.js event loop for approximately 15 seconds. Affected versions are effect <= 3.22.0; the issue is patched in effect@3.22.1. This vulnerability is rated Moderate severity (GitHub Advisory).

The root cause is catastrophic backtracking in a compiled regular expression (CWE-1333 / ReDoS). Schema.TemplateLiteral maps each Schema.String span to the lazy wildcard [\s\S]*?; when two or more such spans appear in a single template (e.g., Schema.TemplateLiteral(Schema.String, ":", Schema.String, ":", Schema.String, "X")), the resulting regex contains multiple adjacent ambiguous quantifiers. A crafted non-matching input — such as a long string of : characters — forces the regex engine to explore an exponentially (cubically) growing number of backtrack paths. The fix replaces the regex-based approach with a linear left-to-right scan for templates whose spans are all Schema.String, eliminating the backtracking entirely (GitHub Advisory).

Successful exploitation causes a Denial of Service by blocking the Node.js event loop, rendering the application unresponsive for the duration of the regex evaluation. Any code path that decodes untrusted input through a multi-Schema.String-span TemplateLiteral schema is affected, including Schema.decodeUnknown, Schema.decodeUnknownSync, Schema.is, and higher-level abstractions such as HttpApi request payloads and @effect/rpc payloads. There is no direct confidentiality or integrity impact, but availability can be severely degraded with a single malicious request (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported at this time. The vulnerability is straightforward to trigger: an unauthenticated attacker who can submit arbitrary input to an endpoint that uses a vulnerable Schema.TemplateLiteral schema can cause a denial of service with a single crafted request. No EPSS score or CISA KEV catalog entry is currently available for this CVE (GitHub Advisory).

1. Reconnaissance: Identify applications using the effect npm package at version ≤ 3.22.0 that expose HTTP endpoints (e.g., via HttpApi or @effect/rpc) which decode request bodies or parameters using a Schema.TemplateLiteral with two or more Schema.String spans.
2. Craft malicious payload: Construct a long non-matching string — for example, 5,000 or more : characters — that satisfies the literal separators in the template but fails the overall match, maximizing backtracking.
3. Send the request: Submit the crafted payload as the request body or relevant parameter to the vulnerable endpoint (e.g., via a standard HTTP POST request).
4. Trigger event loop block: The regex engine attempts all backtrack combinations across the ambiguous wildcards, blocking the Node.js event loop for ~15 seconds per request, effectively making the service unavailable.
5. Sustain DoS: Repeat requests at a rate that keeps the event loop continuously blocked, preventing legitimate traffic from being processed (GitHub Advisory).

• Network: Repeated HTTP requests to schema-validated endpoints containing unusually long strings composed primarily of delimiter characters (e.g., :, -, /) with no meaningful content structure.
• Logs: Application logs showing requests that take an abnormally long time to process (>10 seconds) on endpoints that perform schema validation; Node.js event loop lag metrics spiking to 10–20+ seconds.
• Process: Node.js process CPU usage pegged at 100% for extended periods without corresponding legitimate load; event loop utilization tools (e.g., clinic, 0x) showing regex evaluation as the bottleneck (GitHub Advisory).

Upgrade to effect@3.22.1 or later, which replaces the vulnerable regex-based matching with a linear scan for all-Schema.String template literals. If an immediate upgrade is not possible, apply an input length guard on the input side before the schema runs — for example: Schema.compose(Schema.String.pipe(Schema.maxLength(256)), MyTemplateLiteral). Note that applying Schema.maxLength directly to the template literal output does not mitigate the issue, as the filter executes after the regex. Rejecting oversized request bodies at the HTTP layer (e.g., via a body size limit middleware) is also an effective defense-in-depth measure (GitHub Advisory).