CVE-2021-4236

This is a logic flaw in a WebSocket authentication hook: when an AuthenticateMethod is configured, WebSocket connections don't actually invoke it, so the returned UserData pointer stays nil. Code that assumes that pointer is non-nil hits a nil-pointer dereference, and more seriously, the authentication check the developer intended simply doesn't run — an authentication bypass. Crucially, the description scopes it tightly: only WebSockets that use an AuthenticateMethod hook are affected, and non-WebSocket handlers are not vulnerable at all.

That scoping is the whole story for prioritization. The critical 9.8 assumes the worst case — unauthenticated remote bypass of an intended auth gate — but it only materializes in applications that both use this library's WebSockets and configured an AuthenticateMethod they believed was protecting them. Where it applies, the consequence is real: the auth control is silently absent, so an attacker reaches functionality the developer thought was gated, or crashes the service via the nil dereference. Where it doesn't apply, the CVE is simply inert.

Our approach is code-path inventory rather than blanket patching, and honest triage of applicability. The record names a generically titled "web" project, so the first job is identifying whether any of our services actually depend on the affected library and specifically use WebSockets with an AuthenticateMethod hook. That narrow condition is the true attack surface; services meeting it get treated as having no WebSocket auth at all until updated, while everything else is a non-issue we can dismiss with confidence rather than let a 9.8 label inflate.