CVE-2026-50751: Check Point VPN authentication bypass, already actively exploited
CVE-2026-50751 allows bypassing Check Point VPN authentication without a valid password. It is on the KEV catalog. What to do today.
CVE-2026-50751: Check Point VPN authentication bypass, already actively exploited
In short
A critical vulnerability (CVSS 9.3) affecting Check Point VPN products has been published and is already listed in CISA's catalog of actively exploited vulnerabilities (KEV) [1][2]. The flaw allows a remote attacker, without needing credentials, to establish a remote access VPN connection by bypassing user authentication [1]. If your organization uses Check Point Security Gateway with Remote Access or Mobile Access features, the recommendation is to prioritize reviewing the vendor's available patches today and audit active VPN sessions.
What it is and why it matters
According to the technical record published on NVD, this is a logic flaw in certificate validation within the IKEv1 key exchange, a protocol already considered deprecated that remains in use in many remote access environments [1]. This flaw allows an unauthenticated attacker to bypass the username and password check, establishing a valid remote access VPN connection without legitimate credentials [1].
In practice, this means an external actor could gain a way into the corporate network through the very infrastructure meant to protect remote access: the VPN gateway. This is a particularly delicate scenario because these devices are typically placed on the perimeter, with direct visibility from the internet, and act as a gateway to internal systems.
The vulnerability was published on June 8, 2026 with "critical" severity according to NVD [1], and CISA has added it to its KEV catalog, confirming active exploitation verified by that agency [2]. At this time, we do not have further publicly verified details about the volume or origin of that exploitation.
Who is affected
The affected vendor is Check Point [1]. The official description identifies Remote Access and Mobile Access features over the IKEv1 key exchange as the components involved [1]. We do not have a verified list of specific affected versions or models, so if your organization operates Check Point gateways with remote access VPN enabled, it is advisable to treat this advisory as potentially relevant and confirm the exact status directly with the vendor's own documentation and security advisories.
From our threat intelligence radar, we classify this vulnerability under the "Authentication / unauthorized access" category, with critical severity, precisely because it is an authentication bypass in a perimeter remote access component: the type of flaw that combines internet exposure, no need for credentials, and potential direct access to the internal network.
How to know if you are vulnerable
First, check whether your organization has Check Point gateways deployed with Remote Access or Mobile Access capabilities accessible from the internet: these are the ones identified as involved in the official description [1]. Also check whether the key exchange configured on those VPN connections is still using IKEv1, since that is the protocol mentioned in the flaw [1].
Beyond the internal review, it is advisable to map which assets in your organization are actually exposed externally: VPN gateways, remote access portals, and any Check Point service visible from the internet are the first candidates to review. Knowing that exposed surface precisely is, in general, the first step when facing any advisory of this kind, and even more so when it affects remote access infrastructure on the perimeter.
How to protect yourself
- Check Check Point's official advisories and patches for your specific products and versions as soon as possible, and apply them following your vendor's or technology partner's procedure.
- Audit active and recent VPN connections on your gateways, looking for sessions that do not correspond to recognized users or devices.
- If technically feasible and it does not break critical services, consider disabling or migrating away from IKEv1 toward more recent key exchange protocols, since it is the component identified in the flaw's description [1].
- Strengthen monitoring of remote access gateways over the coming weeks, given that the vulnerability is in the KEV catalog and there is evidence of active exploitation [2].
- Document which Check Point systems your organization has and their actual internet exposure; this is the basis for prioritizing any remediation.
Frequently asked questions
Does this mean we have already been attacked?
Not necessarily. The fact that the CVE is in the KEV catalog confirms that CISA has evidence of active exploitation in general [2], not that every organization with Check Point products has been attacked.
Do I need to patch as a mandatory regulatory requirement?
Inclusion in the KEV catalog carries mandatory remediation deadlines for U.S. federal civilian agencies (under directive BOD 22-01). For other organizations it is not a regulatory obligation, although it is a strong signal that patching should be prioritized as soon as possible.
What should I do if I don't know whether we have Remote Access or Mobile Access enabled?
This is a good starting point for your IT team or security provider: review the configuration of Check Point gateways and confirm which remote access features are enabled and exposed to the internet.
Sources
- [1] NVD — Official record for CVE-2026-50751: nvd.nist.gov/vuln/detail/CVE-2026-50751
- [2] CISA — Known Exploited Vulnerabilities (KEV) catalog: cisa.gov/known-exploited-vulnerabilities-catalog