Why VPN Certificate Parsing Is Pre-Authentication Attack Surface

Every VPN gateway that authenticates peers with certificates has a piece of code that runs on attacker-controlled input before it knows who the attacker is. That code is the certificate parser, and the two Check Point vulnerabilities disclosed in September 2026 (CVE-2026-85102 and CVE-2026-85103, both CVSS 9.8) are a clean example of what happens when it fails. This article explains where certificate parsing sits in an IPsecIPsec🌐A suite of protocols that authenticates and encrypts IP traffic at the network layer, used for site-to-site tunnels between gateways and for many remote-access VPNs. IKE handles the negotiation; ESP carries the protected packets. handshake, why it cannot be moved behind authentication, and what the two classic failure modes look like.

Where certificates enter the handshake

An IPsec tunnel starts with IKE, the Internet Key Exchange protocol. The two endpoints negotiate cryptographic parameters, perform a Diffie-Hellman exchange to agree on keys, and then authenticate each other. Authentication is the step that matters here. It can use a pre-shared key, or it can use X.509 certificates, and certificate authentication is the norm for anything larger than a handful of static tunnels because it scales and it supports revocation.

With certificate authentication, the initiating peer sends its certificate (and often a chain) inside the IKE exchange. The gateway receives that certificate as a sequence of bytes. It has to decode those bytes into a structure it can reason about, extract the public key, check the signature over the handshake, walk the chain to a trusted root, check validity dates and revocation status, and match the identity against the policy that says which peers are allowed. Only after all of that is the peer considered authenticated.

Notice the order. Decoding and validation happen first. Trust is the output of that process, not an input to it. There is no way to say "only parse certificates from authenticated peers" because parsing the certificate is how you authenticate the peer.

Why that makes it pre-authentication attack surface

Pre-authentication attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching. is any code path an unauthenticated network client can drive. It is the most valuable class of bug for an attacker because it removes the need for credentials, phishingPhishing🛡️A social engineering attack using fake emails or websites to steal login credentials or personal info., or an insider. On a VPN gateway the certificate parser is squarely in that class: anyone who can send UDP to port 500 or 4500 can deliver a certificate, and the gateway will process it.

The consequences are worse than for most pre-auth code because of where the gateway sits. It is on the perimeter by design, reachable from the entire internet, and it holds the keys to everything behind it. A remote-access VPN concentrator is also, by definition, expected to accept connections from arbitrary source addresses, which removes the one cheap mitigation (source filtering) that works for site-to-site tunnels. The guide on how to lock down IKE and IPsec ports to known VPN peers covers that mitigation and its limits.

Failure mode one: the decoder trusts the length fields

X.509 certificates are encoded with ASN.1ASN.1🛡️Abstract Syntax Notation One, a standard for describing structured data as tag-length-value elements. X.509 certificates are ASN.1 encoded, so every TLS and IPsec endpoint contains an ASN.1 decoder that runs on untrusted input, a frequent source of memory-safety bugs. using DER rules. ASN.1 is a tag-length-value format. Every element announces its type, then how many bytes it occupies, then the bytes. A decoder reads the tag, reads the length, and then does something with that many bytes: allocates a buffer, copies into an existing one, or advances a pointer.

The attacker controls the length field. If the decoder allocates based on a declared length but copies based on the actual data, or vice versa, you get a heap overflowHeap Overflow🛡️A memory-corruption bug where a program writes more data into a heap allocation than it was sized to hold, spilling into adjacent memory. When the overwritten neighbor is the allocator's own bookkeeping, an attacker can steer it toward code execution.. If it trusts a nested length that exceeds the enclosing element, you get an out-of-bounds read. If it multiplies a count by an element size without checking for wraparound, you get an integer overflow that produces a tiny allocation followed by a large copy. ASN.1 decoders have produced these bugs in essentially every major TLS and IPsec implementation over the last two decades, because the format has enormous flexibility and the parsers are usually hand-written C for performance.

CVE-2026-85103 is this failure mode. Check Point's advisory describes it as a heap overflow in the VPN certificate ASN.1 decoding flow, reachable by a remote attacker without authentication, and affecting the management server as well as the gateway. A heap overflow in a long-running daemon on an appliance is a well-trodden path to code execution; the site's explainer on how a heap overflow in a network daemon becomes code execution goes through the mechanics.

Failure mode two: the validator makes the wrong decision

The second failure is not about memory. The decoder works correctly and produces a well-formed certificate structure, but the logic that decides whether to trust it is wrong. Common variants:

• The chain is checked for a valid signature but not for a trusted root, so any self-signed certificate passes.
• The identity in the certificate is not compared against the configured peer list, so a valid certificate from an unrelated CA is accepted.
• A field that should be mandatory is treated as optional when absent, and its absence causes a check to be skipped.
• The code accepts a certificate for one purpose (say, a client certificate) in a context that should require another (a gateway certificate).

CVE-2026-85102 is in this family. The advisory calls it improper validation of certificate data during VPN negotiation, and the consequence is described as authentication bypassAuthentication Bypass📖A security vulnerability that allows an attacker to circumvent the login verification process and gain unauthorized access to a system without providing valid credentials. leading to remote code execution. That combination, a logic bug that ends in code execution rather than just an unauthorised tunnel, suggests the bypass reaches something deeper than a policy check, but Check Point has not published details and nobody should guess.

What defenders can do about a class of bug they cannot see

You cannot audit a vendor's ASN.1 parser. What you can do is reduce how many strangers get to talk to it.

• For site-to-site tunnels, restrict IKE and IPsec traffic to known peer addresses. Check Point's own workaround for these CVEs is exactly this: disable the implied VPN rules and allow UDP/500 and UDP/4500 only from specific peers.
• For remote-access VPN, accept that source filtering is not available and compensate elsewhere: patch fast, monitor the VPN daemon for crashes, and keep the gateway's own credentials and certificates on a rotation schedule so that a compromise has a bounded lifetime.
• Treat the management server as perimeter-adjacent. CVE-2026-85103 reaches it. A management server that can be contacted by gateways can, through the gateway, be contacted by the attacker who owns the gateway.
• Prefer vendors that ship hot patches for this class of bug, and understand what those patches do and do not cover. The article on why live patchingLive Patching🛡️Applying a security fix to running software on an appliance or server without a full upgrade or reboot, often delivered automatically by the vendor. It shortens the exposure window but typically covers only supported releases and does not replace the full fixed release. perimeter appliances covers less than it seems explains the trade-offs.

The deeper lesson is that authentication code is not protected by authentication. Every byte a VPN gateway reads before it says "trusted" is a byte an attacker chose, and the certificate is the largest, most complex blob in that exchange. When a vendor tells you the bug is in certificate handling, assume the worst about who can reach it and act accordingly.