CVE-2026-49457

The most dangerous aspect of CVE-2026-49457 is not the MITM vulnerability itself, but the false sense of security created by a `verify` option that was functionally inert. Developers who set `verify => true` believing they were enforcing server certificate validation had zero actual protection—and received no indication that their security control was doing nothing. The erlang_quic library exposed a `verify` option that appeared to control server certificate validation, but the option was never actually applied to the TLS handshake. The default was insecure (`verify => off`), changed to `verify => on` in version 1.4.4. Critically, there were no workarounds: certificate inspection after connecting was unavailable, custom verify callbacks weren't supported, and the API offered no escape hatches for security-conscious developers to self-help. The vulnerability was silent—no warning, no failure, no indication that verification wasn't occurring. For defenders, the priority is immediate: upgrade to erlang_quic 1.4.4 or later. Beyond patching, assess whether any deployed code explicitly set `verify => false` or relied on the default—those configurations now need explicit review. Since the library offered no way to validate certificates post-connect, there's no way to retroactively confirm whether past connections were secure. This means any erlang_quic deployments prior to 1.4.4 should be treated as potentially compromised, with incident response appropriate for active MITM exposure. The key insight is that the absence of failure signals doesn't indicate security—it indicates the security control was never working.

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