GraphQL Scalars EUVD-2026-109185

The target GraphQL server must use graphql-scalars between 1.24.1 and 2.0.0 and expose GraphQLPhoneNumber on a field argument, an input-object field, or a variable that accepts untrusted/anonymous input; serialize is additionally affected when unvalidated stored values are returned through a PhoneNumber field. No authentication, user interaction, or non-default configuration is otherwise required, because parseLiteral runs during document validation and parseValue during variable coercion before any resolver authentication or authorization - a single ~30-character request suffices. The one real limiting factor is schema exposure: if no PhoneNumber scalar is applied to attacker-controllable input, the flaw is not reachable. Versions 1.24.0 and earlier use the linear pattern /^\+[1-9]\d{6,14}$/ and are not affected. Vendor-stated mitigations until upgrading: replace the scalar with the fixed linear pattern, run Node with --enable-experimental-regexp-engine-on-excessive-backtracks (not accepted via NODE_OPTIONS), or pin graphql-scalars <=1.24.0 (which changes accepted values); the complete fix is upgrading to 2.0.1.

This is a genuine, actionable availability risk but not a drop-everything emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) is consistent with the mechanism described: a network-reachable, low-complexity, unauthenticated request causes a high-availability impact with no confidentiality or integrity effect - a classic ReDoS (CWE-1333) denial of service. The critical corroborating detail from the GHSA advisory is that graphql-js runs parseLiteral during document validation and parseValue during variable coercion BEFORE any resolver-level authentication or authorization, which independently supports the PR:N choice (no auth needed) and raises real-world concern because no credentials gate the attack. The vuln.today decision label is 'this_week', not act_now/emergency, which aligns with a serious-but-not-actively-mass-exploited issue. There is no CISA KEV listing and no EPSS score was provided in the input, so widespread active exploitation is NOT established - exploitation status is based on the public advisory and its PoC only. A detailed, measured proof-of-concept (timing tables, payload '1'.repeat(30)+'x') is published in the GHSA advisory, lowering the barrier to weaponization. The main factor that moderates risk below the raw 7.5 is a precondition the CVSS vector does not capture: the server must actually expose the GraphQLPhoneNumber scalar on untrusted input. MISSING DATA: no EPSS, no KEV, and no SSVC automatable/technical-impact breakdown were supplied, so prioritization rests on CVSS plus the vendor advisory rather than exploitation-probability telemetry.

An anonymous client sends a single small HTTP GraphQL request (query or variables) containing a PhoneNumber value of roughly 30 characters - a run of digits followed by one character that forces the match to fail, e.g. '1' repeated 30 times plus 'x'. Because graphql-js validates the literal and coerces the variable before authentication, the exponential-backtracking regex runs on the main thread and blocks the Node.js event loop for seconds (around 40 characters would busy a process for hours), stalling all concurrent requests. A working, measured PoC is published in the GHSA advisory; attack complexity is low and no user interaction or authentication is required.