Possible CVE-2026-85102 exploitation – unauthorized VPN sessions and LDAP/LDAPS scanning

[sander143188]

Hi CheckMates,

I would like to compare notes with the community regarding the recently disclosed VPN vulnerabilities, specifically CVE-2026-85102 / sk1000117.

On September 14 we observed very similar suspicious activity on two separate Check Point gateways in two completely independent customer environments.

Before the gateways were updated, the logs show:

• Successful Remote Access VPN login events
• Authentication method shown as Certificate
• Certificate CNs such as vpnuser / vpn-user
• A 172.16.10.x Remote Access VPN IP being assigned
• Immediately afterwards, large numbers of VPN Decrypt connections towards internal networks
• Systematic scanning of internal IP ranges, mainly on TCP/389 (LDAP) and TCP/636 (LDAPS)
• In both environments the scanning pattern was highly automated
• At one point, very similar scanning activity occurred on both unrelated gateways almost simultaneously

We do not recognize these VPN sessions or certificates as legitimate user activity.

After installing the fix referenced in sk1000117, we have not observed any further successful sessions of this type.

We opened a TAC case and had a remote session with Check Point Support. TAC confirmed that the gateway is protected once the fix is installed. However, my concern is specifically about post-compromise remediation for activity that occurred before the fix was installed.

I therefore have a few questions for the community and, if possible, Check Point:

1. Has anyone else seen successful certificate-based Remote Access VPN sessions followed by LDAP/LDAPS scanning in relation to these vulnerabilities?
2. Is this logging pattern consistent with exploitation of CVE-2026-85102, or could there be another explanation?
3. If unauthorized VPN access occurred before patching, is installing the fix considered sufficient remediation, or should the gateway be rebuilt/re-imaged?
4. Are there specific Gaia / VPN / system logs or IOCs that should be checked to determine whether code execution or persistence occurred on the gateway itself?
5. Should local gateway credentials, certificates or other secrets be rotated in this scenario?

I have preserved the gateway logs and can provide sanitized/anonymized log samples and timestamps if useful.

I am deliberately not posting customer names, public IP addresses or internal addressing at this stage.

Thanks in advance for any insight.

[PhoneBoy]

My personal take is that the observed logs seem consistent with someone exploiting CVE-2026-85102 and then attempting to pivot further into the environment.
As this vulnerability was discovered internally, we don't have IoCs to share.

[Lesley]

3. and 5. -> may allow an unauthenticated remote attacker to execute arbitrary code on the Security Gateway.

So if you want to be sure, yes reinstall. I think you cannot be 100% sure if they run a code yes or no.

But in the end, recently there are many CVE's for a lot of vendors, it is not manageable to every time clean install the system and change all the passwords, certificates etc. Of course if the CVE states access was possible to the exposed system

I would ask TAC to advise what to do if they indeed abused this CVE. Just assume they have been able to run all the code they wanted, what would TAC advise be? 

If you want to make sure the changes are quite a lot think like:

Change all PSK for all tunnels.

Renew all certificates

Change passwords, SNMP ssh access , GRUB, expert etc.

Rotate ICA, renew VPN cert, platform portal,SSL decryp cert etc.

Check out AD servers, the logs, reset service accounts. Maybe check out the service accounts that the check point uses