The signature is the only proof of possession in the exchange
Certificate authentication exists because a password can be guessed and a username can be typed by anyone. The certificate raises the bar: the gateway is supposed to admit you only if you can prove you hold the private key that matches a certificate it trusts. The proof is a signature. In IKEv1 Main Mode with RSA-signature auth (RFC 2409), the client sends three things in message five: an identity payload naming who it claims to be, a certificate payload carrying its public certificate, and a SIGNATURE payload carrying a signature, made with the certificate's private key, over the phase-1 hash.
A certificate is public. Anyone who has ever seen one can copy it. The identity payload is just a string. The only thing in that message an impersonator cannot produce is the signature, because producing it requires the private key. verifyMessagePhase1 is where Check Point's iked checks that signature and walks the certificate's trust chain back to the gateway's internal CA. It is the entire load-bearing step of certificate authentication. Everything else in message five is a claim. The signature is the proof.
CVE-2026-50751 removes the proof and keeps the claim. On a vulnerable gateway, the identity payload, a subject distinguished name of the form CN=<username>,OU=users,O=<org>, becomes the whole of the attacker's identity. A username, typed into a certificate. The watchTowr artifact that demonstrates the bug needs exactly one piece of victim-specific information to forge that identity: a valid Remote Access username. The organization component, O=, is the gateway's own internal-CA organization, and the artifact derives it automatically by reading the gateway's public TLS certificate off port 443. There is no secret in the forged identity. There was never meant to be. The secret was supposed to be the private key, and the signature was supposed to be the demand for it.
What the attacker sends
The exchange is ordinary IKEv1 Main Mode until message one carries an extra payload. The artifact offers a single proposal, AES-256 / SHA1 / DH group 2 / RSA-signature, and appends Check Point's VPNExtFeatures Vendor ID with the trigger bit set:
# The CVE-2026-50751 trigger: the Check Point "VPNExtFeatures" Vendor ID
# (16-byte magic) + a 4-byte value with bit 0x4 set.
VPNEXTFEATURES_MAGIC = bytes.fromhex("3cf187b2474029ea46ac7fd0eaf289f5")
VPNEXTFEATURES_VID = VPNEXTFEATURES_MAGIC + struct.pack(">I", 0x00000004)
A Vendor ID payload is how two IKE peers announce what extensions they support. It is unauthenticated by construction: it travels in the clear, in the first message, before a key has been negotiated or an identity asserted. The vulnerable iked reads the four-byte VPNExtFeatures value into its per-session state and, per watchTowr's reversing, lets bit 0x4 flow into verify_peer_auth, where it short-circuits the call to verifyMessagePhase1.
Messages three and four are the Diffie-Hellman exchange, unmodified. Message five is where the forgery lands, encrypted under the freshly negotiated session key:
def send_msg5(self, keys, forged):
"""msg5 (encrypted): ID (forged subject DN) + CERT (self-signed) + an invalid signature."""
idii = struct.pack(">BBH", ID_DER_ASN1_DN, 0, 0) + forged.subject_dn_der
cert = struct.pack(">B", CERT_ENCODING_X509_SIG) + forged.cert_der
invalid_sig = os.urandom(256) # no private key -> junk signature
...
forged.cert_der is a self-signed certificate built around a throwaway 2048-bit RSA key the artifact generates and then never uses, because the certificate's own signature is never checked either. invalid_sig is 256 bytes from the system random source. On a gateway running an unpatched iked, none of it is examined. Bit 0x4 told verify_peer_auth to skip verifyMessagePhase1, so neither the signature nor the trust chain is checked. The gateway resolves the subject DN to a provisioned Remote Access user, completes phase 1, and saves the ISAKMP security association under the victim's name. Then it sends an encrypted message six.
The artifact proves the bypass succeeded by decrypting message six with the negotiated key and reading the gateway's internal IP address out of it. You can only decrypt that message if you hold the genuine phase-1 session key, which you do, because the gateway just finished a key exchange with you and authenticated you as someone else. A patched iked rejects the invalid signature in verifyMessagePhase1 before any user lookup happens, and the exchange dies in an informational message.
The bypass works over IKE on UDP 500 and 4500, and over Check Point's Visitor Mode, which tunnels the same IKE exchange over raw TCP on port 443. Blocking UDP 500 does not close it. The bug is not a port. The bug is a bit.
The bit was internal only by convention
VPNExtFeatures is Check Point's own channel. It is how a Check Point VPN client and a Check Point gateway negotiate the extended behaviors that live outside the IKE standard. The bits in that four-byte value are session state the two halves of Check Point's own stack exchange about each other. In the mental model under which the code was written, nobody outside that stack would ever set them, because nobody outside that stack would know the sixteen-byte magic or which bit meant what.
That assumption is the vulnerability, and it has a name in our catalog: internal-only-by-convention. A field the framework treats as its own private signal, read with security-relevant authority on every inbound request, where "private" is enforced by documentation and obscurity rather than by the network. The canonical instance is Next.js's x-middleware-subrequest header in CVE-2025-29927: a breadcrumb the framework wrote to itself to break middleware recursion, which the network was also permitted to write, turning the documented auth gate off with six colons in a single request. The header was internal only by convention. Bit 0x4 of VPNExtFeatures is internal only by convention. The closest kin is Android's PackageInstaller flag scrub, where a caller-controlled 32-bit integer carries install-flag bits the system reads as authoritative, held internal by a deny list that scrubbed eight system-only bits and missed the ninth. Check Point's defect is one step worse than a missed scrub: there is no deny list. Reading a feature-negotiation bit from an unauthenticated peer, and using it to govern whether the gateway authenticates that same peer, is not an oversight in the trigger path. It is the design of the trigger path.
There is a second name for what happens when the bit is read this way. The certificate check is a control an operator deliberately turns on to get more assurance than a password offers. CVE-2026-50751 makes the enforcement of that control a toggle the unauthenticated peer flips. That is trust-inversion: the mechanism deployed to raise the bar becomes the mechanism the attacker configures. The operator who selected certificate authentication chose it for the proof-of-possession guarantee. The bug hands the decision of whether to demand that proof to the one party who cannot supply it.
The hotfix restores what the bug removed
Check Point's fix is hotfix sk185033, and the one-line description of what it does is the tell. It does not add a missing certificate check. It restores the signature check. The verb is exact. verifyMessagePhase1 was always in the binary. It always knew how to check a signature and walk a chain. The vulnerable code path let the client vote it out of the exchange, and the patch stops counting the client's vote. The audit-readable scope of the change is small; the behavior it removes is the gateway accepting the stranger's instruction to not look.
CISA added CVE-2026-50751 to its Known Exploited Vulnerabilities catalog on 2026-06-08 with a remediation deadline of 2026-06-11, three days. The KEV catalog does not list bugs that might someday be exploited; it lists bugs already in use, indicted by an authority higher than any vendor advisory. The bypass applies to the Certificate, Certificate-with-enrollment, and Mixed user-authentication methods, the exact configurations an administrator selects to get something stronger than a username and password. Plain legacy password auth is not bypassable by this. The gateways that turned on certificate authentication for the assurance are the gateways this hits.
So the charge, stated plainly: Check Point shipped an IKE daemon that reads a feature-negotiation bit from an unauthenticated network peer and uses that bit to decide whether to perform the certificate-signature verification that is the entire reason certificate authentication exists, and it shipped this in the Remote Access VPN path that fronts the internal network for exactly the organizations careful enough to deploy certificates.
The detection that pings the port misses the bug
It is worth knowing what most of the public artifacts for this CVE actually test, because it is not this bug. Several of the repositories that a scanner registers as "PoC available" send a standard Main Mode SA proposal to UDP 500 and label any host that answers as VULNERABLE. An IKE responder answering a handshake is not the vulnerability; it is the precondition for running a VPN at all. Two more repositories reimplement the exchange using X25519 and HKDF, primitives IKEv1 does not use, never send the VPNExtFeatures Vendor ID, and in one case call a method that does not exist before argument parsing even runs. Those scripts cannot trigger CVE-2026-50751 because the thing that triggers CVE-2026-50751 is one bit in one Vendor ID, and they do not set it.
The single artifact that exercises the actual bug is watchTowr's, by McCaulay (@_mccaulay), and it is the only one that forges the identity and sets the bit. The gap between "IKEv1 is reachable" and "the gateway will skip its own signature check on request" is the whole of this CVE, and a port probe cannot see across it. Detection that fires on UDP 500 answering will mark a patched gateway vulnerable and a Visitor-Mode-only gateway safe. The bit, not the port, is the question.
Check Point's gateway still knows how to verify a certificate. It let the unauthenticated peer decide whether it would.