# CVE-2026-35058 - fix server ASSERT() on receiving a suitably malformed packet with a valid tls-crypt-v2 key tls-crypt-v2: Avoid interpreting opcode as part of WKc The buffer we pass to tls_crypt_v2_extract_client_key contains the entire received control channel packet. We should skip the opcode before trying to read WKC. This logic error is a second bug behind the XlabAI finding, next too the too-strict ASSERT in tls_crypt_unwrap. Also remove a too strict ASSERT in tls_crypt_unwrap. We already check a few lines later for a too short packet and return a proper error ("packet too short"). XlabAI found a way of triggering this ASSERT that requires a tls-crypt-v2 client key that has a specific property (a specific byte need to have a specific value, about 1/256 probability). If an attacker can get hold of such a tls-crypt-v2 client key or observe a handshake using such a key, the attacker can trigger the ASSERT, crashing the server. Setups that do not use tls-crypt-v2 are not affected. Independently, Cisco Talos reported a way to trigger this ASSERT with any tls-crypt-v2 key but this requires the attacker to be also in possession of the private key part of the tls-crypt-v2 client key or to inject packet into a live session of a client session. OpenVPN version 2.6.0 through 2.6.19 and 2.7_alpha1 through 2.7.1 are affected. This is fixed in version 2.6.20 and 2.7.2. CVE Record: [CVE-2026-35058](https://www.cve.org/CVERecord?id=CVE-2026-35058) Github: [OpenVPN/openvpn-private-issues#111](https://github.com/OpenVPN/openvpn-private-issues/issues/111) Release notes: [openvpn-2.7.2](https://community.openvpn.net/ReleaseHistory#openvpn-272-released-22-april-2026) [openvpn-2.6.20](https://community.openvpn.net/ReleaseHistory#openvpn-2620-released-22-april-2026) Reported-By: XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com) Reported-By: Guannan Wang (wgnbuaa@gmail.com Reported-By: Zhanpeng Liu (pkugenuine@gmail.com) Reported-By: Guancheng Li (lgcpku@gmail.com) Reported-By: Emma Reuter of Cisco ASIG (TALOS-2026-2381)
