CVE-2021-4236

Este es un fallo de lógica en un hook de autenticación de WebSocket: cuando se configura un AuthenticateMethod, las conexiones WebSocket no lo invocan realmente, de modo que el puntero UserData devuelto permanece en nil. El código que asume que ese puntero no es nil sufre una desreferencia de puntero nil y, más grave aún, la verificación de autenticación que el desarrollador pretendía simplemente no se ejecuta: un bypass de autenticación. Crucialmente, la descripción lo acota estrechamente: solo se ven afectados los WebSockets que usan un hook AuthenticateMethod, y los manejadores que no son WebSocket no son vulnerables en absoluto.

Esa delimitación es toda la historia para la priorización. El 9.8 crítico asume el peor caso —bypass remoto no autenticado de una compuerta de autenticación prevista—, pero solo se materializa en aplicaciones que tanto usan los WebSockets de esta biblioteca como configuraron un AuthenticateMethod que creían que las protegía. Donde aplica, la consecuencia es real: el control de autenticación está silenciosamente ausente, así que un atacante alcanza funcionalidad que el desarrollador creía protegida, o hace caer el servicio mediante la desreferencia nil. Donde no aplica, el CVE es simplemente inerte.

Nuestro enfoque es el inventario de rutas de código en lugar de la aplicación de parches generalizada, y un triaje honesto de la aplicabilidad. El registro nombra un proyecto "web" de título genérico, así que el primer trabajo es identificar si alguno de nuestros servicios realmente depende de la biblioteca afectada y usa específicamente WebSockets con un hook AuthenticateMethod. Esa condición estrecha es la verdadera superficie de ataque; los servicios que la cumplen se tratan como si no tuvieran ninguna autenticación de WebSocket hasta que se actualicen, mientras que todo lo demás es un no-problema que podemos descartar con confianza en lugar de dejar que una etiqueta de 9.8 lo infle.