You applied the Check Point hotfix on June 8, the day it shipped. CISA's catalog gave you until June 11, so you beat the deadline and closed the ticket. There is a gap in that timeline worth sitting with: the flaw you patched, CVE-2026-50751, had let attackers log into Check Point VPNs without a valid password since May 7. By the time a fix existed, the bug had been live for roughly a month, and a Qilin ransomware affiliate had already used one of those gateways to get inside a victim network.
Patching the gateway closed the way in. It did nothing about anyone who came through while the way in was open. For a small business, that distinction separates a routine patch night from the quiet first hour of a ransomware incident you have not noticed yet.
Who this hits, and who can close the tab
The vulnerability is an authentication bypass, rated CVSS 9.3, in Check Point's Remote Access VPN and Mobile Access when the gateway is configured for the deprecated IKEv1 key exchange. A remote attacker with no credentials can stand up a VPN session as though they held a valid user password. It affects the Security Gateway line broadly, and - this is the part small businesses cannot skip - it affects the Spark firewalls Check Point sells to small and mid-size companies and through managed service providers.
The affected builds run from the older R80.x trains, several already end-of-support, through R81.10, R81.20, and the current R82 releases, so an aging gateway nobody has touched in two years is squarely in scope. Check Point shipped the fix alongside a second advisory, SK185035, for a related man-in-the-middle weakness, CVE-2026-50752, in the same deprecated protocol; if you are touching the gateway to patch one, handle both in the same change window.
If you do not run a Check Point gateway, this one is not yours; go read something more useful to you. If you run one but never enabled IKEv1 remote access, your exposure is low and the rest of this is a hygiene check. If you run a Check Point Remote Access or Mobile Access VPN, or a Spark appliance, that faced the internet with IKEv1 on at any point since early May, read every section. You are the target population, and the question has moved past whether to patch. The question now is whether someone got in before you did.
The myth: the same-day patch closed the exposure
The comforting version goes like this. Check Point disclosed the bug and shipped a hotfix on the same day. CISA added it to the Known Exploited Vulnerabilities catalog on June 8 with a June 11 due date. You patched inside the window. Exposure closed, on to the next thing.
The dates do not support that conclusion. Check Point states the flaw was exploited in the wild starting May 7, with activity climbing through early June. Apply that to your own gateway. If it was reachable from the internet with IKEv1 enabled during those weeks, the patch arrived after about a month of live exploitation, not ahead of it. A fix for a pre-authentication bypass stops the next unauthenticated login. It does nothing to end a VPN session that already happened, invalidate a credential an attacker already captured, or remove a foothold already planted on an internal host. The honest posture for an exposed gateway is to assume access may have occurred and to go look for it, rather than mark the work done at the patch.
What a Qilin affiliate does after the front door
Qilin operates as ransomware-as-a-service: a core group maintains the malware and the leak site, and affiliates do the breaking in. In the case tied to this CVE, the affiliate did not stop at the VPN. After gaining network access, they used Rclone, a legitimate open-source file-sync tool, to copy data out before any encryption ran. That is the modern ransomware shape: get in quietly, move laterally, collect credentials, stage the most valuable data, exfiltrate it, and only then encrypt. The extortion runs in two directions at once - pay to decrypt your files, pay again to stop the stolen data from being published.
The edge gateway is also the worst possible place for this to start, because it is usually the one box on the network with no endpoint detection agent watching it and logs that live only on the appliance itself. An attacker who lands there has a foothold your monitoring was never pointed at, and the record of how they got in sits on a device they now partly control. That is why the dwell time matters more than the bypass: the bypass is one log line, and the damage is everything that quietly followed it on hosts further inside.
For a small business the timing is the cruel part. The VPN bypass is hour zero. The encryption that finally makes the attack visible can land days later, after the data has already left the building. Check Point has described the exploitation as limited so far to a few dozen organizations worldwide, which reads as reassuring until you remember that the Spark line on the affected list is built for companies with no security team on staff to notice the days in between.
Check whether you were exposed
Two questions decide your real risk: was IKEv1 remote access ever enabled, and was the gateway reachable from the internet during the exposure window. Start on the gateway itself, then move to the logs. If a managed service provider runs the firewall for you, ask them both questions in writing today and ask when they applied SK185033; an appliance that belongs to "whoever set it up" is the one that sits unpatched the longest, and the answer determines whether you owe yourself a hunt or a sigh of relief.
Confirm the build and whether IKEv1 is in use
# Run on the Check Point gateway in expert mode.
# 1) Confirm the build, then compare it against advisory SK185033.
fw ver
clish -c "show version all"
# 2) Check whether IKEv1 is enabled for remote access. Object names vary by
# version, so confirm in SmartConsole > Gateway > VPN > IKE (Phase 1).
grep -iE 'IKEv1|ikev1_for_remote_access' "$FWDIR/conf/objects_5_0.C" | head
# 3) List active VPN tunnels and review the remote-access peers.
vpn tu tlistMatch connections against the published indicators
Check Point published indicators of compromise with the advisory - nine source IP addresses and two file hashes to begin with, and more added between June 9 and 11, tied to hosting providers that include Vultr and Shock Hosting. Pull your remote-access VPN logs for May 7 through your patch date and check the source addresses against that list.
# Save the IPs from advisory SK185033 / the CISA KEV entry to iocs.txt, then
# match them against exported Remote Access VPN logs for the exposure window.
# In SmartConsole, export the logs (May 7 -> your patch date) to ra_vpn.log.
grep -F -f iocs.txt ra_vpn.log
# Surface any successful remote-access authentication, IOC or not, to triage.
grep -iE 'remote access.*(auth|login).*(success|accept)' ra_vpn.logWork the gateway as an incident, not a patch
If the gateway was internet-facing with IKEv1 on, run the following in order. Patching is step one of five here, not the entire list.
1. Patch, then retire IKEv1
Apply the SK185033 hotfix per Check Point's advisory, then move remote access to IKEv2. IKEv1 was deprecated years ago for reasons that this CVE makes concrete; leaving it enabled keeps a class of these bugs reachable.
2. Rotate every credential the VPN could reach
Start with the VPN user accounts, then any Active Directory or service account reachable from the remote-access network segment, plus anything cached on a host an attacker could have touched. Treat them as captured until proven otherwise.
3. Hunt the dwell window for exfiltration
The confirmed case moved data with Rclone, so look for it on internal hosts, along with large outbound transfers to consumer cloud storage, across the window from May 7 to today.
# Hunt internal Windows hosts for Rclone exfiltration during the dwell window.
# Sysmon Event ID 1 (process create): match the binary name or its sync flags.
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} |
Where-Object { $_.Message -match 'rclone' -or $_.Message -match '--config|copy .+:|sync .+:' } |
Select-Object TimeCreated,
@{n='Cmd';e={ ($_.Message -split "`n" | Select-String 'CommandLine').Line }}
# No Sysmon on the host? Pivot to the firewall or proxy egress logs: a spike of
# outbound volume to consumer cloud-storage endpoints since May 7 is the signal.4. Confirm backups are offline and tested
Verify you have an immutable or offline copy and test an actual restore. Double extortion means good backups limit the encryption damage but do nothing for the leak, which is the second reason steps two and three matter as much as the patch.
Treat the patched gateway as a crime scene, not a solved ticket
If you ran an exposed IKEv1 gateway during May and early June, the hotfix is where the work starts, not where it ends. Pull the remote-access logs for the dwell window, rotate the credentials the VPN could reach, and hunt for Rclone and unusual egress before you conclude that nothing happened. Most of the few dozen organizations caught in this will turn out fine; the point of looking is to know which group you are in rather than to find out when the files lock. If your team does not have the hours or the runbook to work an exposed gateway as an incident over the next few days, that is exactly the gap we help close - ahead of an attack when we can, and during one when we have to.
Need an incident response plan before the next attack?
We help small and mid-size organizations build and test incident response playbooks, and we work breaches when they happen, including edge-appliance compromises like this one. Book a session with our team to pressure-test your readiness.