CVE-2026-63462

This vulnerability exposes a systematic blind spot in how engineering teams treat error handling code. The OpenAPI validation middleware in Unleash takes user input, passes it through lodash.get to extract what was submitted, and serializes it back to the user in an error message via JSON.stringify. That call chain — unvalidated user input flowing directly into JSON.stringify — is a textbook stack exhaustion vector. Any developer who has seen a JSON.parse nested object crash knows exactly what happens here: deeply nested structures cause the serializer to recurse until the process blows the stack. What makes this noteworthy isn't the specific code mistake — it's the mental model that produced it. The developer who wrote the `genericErrorMessage` function was solving a legitimate UX problem: when validation fails, users (or rather, developers debugging their API calls) need to see what they submitted to understand what went wrong. That intent is reasonable. The gap is that they treated the error output channel as plumbing — code that formats a message for a trusted consumer — rather than as an output channel that will inevitably receive malicious input from the network. Error handling is where developers' mental models most consistently treat untrusted input as trusted, because the assumption is that errors only happen to 'legitimate' requests. The choice of lodash.get compounded the problem. It's a defensive utility — it won't throw on undefined properties, it'll just return undefined. That defensive instinct created false confidence: the developer had guarded against runtime errors from malformed data, which reduced the perceived need to validate that same data for security. The utilities we reach for to feel safe are often the ones that lull us into skipping the actual safety work. The blast radius here is severe because the vulnerability lives in shared validation middleware that wraps every unauthenticated OpenAPI endpoint. One developer's mistake in a utility function becomes a single point of failure with multiplicative impact across the entire service. The architecture assumed error handling was safe-to-share infrastructure — centralized for consistency — but that design choice meant one unsecured error path could target everything simultaneously. The CVSS 7.5 score obscures something important: this isn't a probabilistic DoS. The absence of an uncaughtException handler means the process dies, not just hiccups. And the replay capability — the ability to resend the same malicious request across process restarts or queue drains — turns an accidental crash into a sustained outage. That's architecturally worse than a typical crash bug: the vulnerability itself acts as a persistence mechanism. Exploitability is trivial (nested JSON around 10KB), blast radius is maximal (every OpenAPI endpoint), and recovery is impossible without patching. The combination of unauthenticated access, shared middleware, no recovery mechanism, and replay capability pushes this well beyond what CVSS captures. The fix in 7.5.2, 7.6.5, and 8.0.2 addresses the immediate code, but the underlying pattern — error paths as implicitly trusted output channels — will produce the next variant. Audit your error handlers as if they were your most exposed endpoint, because attacker-controlled data flows through them whether you intended them as attack surface or not.

Reviewed through automated stages and approved by a human before publication.