Is CVE-2026-85102 (Check Point Multiple Products Improper Certificate Validation) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 18, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2026-85102 to its Known Exploited Vulnerabilities catalogue on 22 September 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Check Point Security Gateway and Check Point Spark Firewall using Site to Site VPN or Remote Access VPN contain an improper certificate validation vulnerability which could allow an unauthenticated remote attacker to execute arbitrary code on the Gateway.

What “exploited in the wild” means for this CVE

For a KEV-listed vulnerability, the practical question is not just whether the flaw exists, but whether defenders should treat it as an active incident-response priority. “Exploited in the wild” means there is reliable evidence of real-world abuse, so exposure is no longer theoretical and internet-facing systems should be assumed to need urgent attention.

Because this issue sits in an edge-device and remote-access product class, confirm whether any Check Point Security Gateway or Check Point Spark Firewall instances are exposed through Site to Site VPN or Remote Access VPN, then verify whether they are in the product path named by the advisory and CISA KEV catalogue. The most useful first-pass evidence is asset inventory, management exposure, VPN configuration, and whether the device is reachable from untrusted networks.

When a vulnerability is already in KEV, prioritisation should follow the CISA Known Exploited Vulnerabilities Catalog, not a generic severity score. For validation and record matching, pair that with the CVE Program and, where you need broader product and record context, the NIST National Vulnerability Database.

For internet-facing appliance issues, this is the same operational pattern covered in Edge Device Security Guide: exposed management surfaces and remote-access paths are the highest-risk places to start, because they are both reachable and business-critical. If the gateway is part of a VPN termination path, treat it as a trust boundary, not just another server.

How to respond when patching or full remediation is not immediate

Do not wait for a broad maintenance window if the affected gateway is internet-facing or externally reachable through VPN. The right response is to reduce exposure first, then apply the vendor fix or mitigation as soon as the advisory supports it. If temporary containment is necessary, focus on narrowing reachability, restricting administrative paths, and increasing monitoring on the device and adjacent authentication flows.

For certificate-validation flaws on remote-access infrastructure, operationally important follow-up is to check whether the device accepted unexpected or unauthorised connections before the fix was applied. That means reviewing VPN logs, session records, authentication events, and configuration changes for evidence of compromise or unusual certificate-handling behaviour. Zero-Day and Exploited Vulnerabilities Guide is a useful navigation point for the kind of emergency triage and post-patch hunting this situation demands.

If your environment uses strong certificate or key governance around remote access, the certificate lifecycle perspective in Machine Identity, PKI and Certificate Lifecycle Guide is relevant because the control objective is not only patching, but trust validation and certificate handling across the access path. For external authority on the surrounding trust model, CA/Browser Forum is a useful reference for certificate issuance and revocation principles, even though this CVE is about device-side validation rather than browser trust alone.

Where prioritisation needs to be evidence-based, use FIRST EPSS as a secondary input, but do not let it outrank KEV when exploitation is already confirmed. KEV establishes operational urgency; EPSS can help sequence the rest of the queue.

What to check for compromise and what to clean up afterward

Because the vulnerability can allow unauthenticated remote code execution, the post-exposure question is whether the gateway was only vulnerable or also used as a foothold. Look for new administrator accounts, unexpected VPN sessions, unusual outbound traffic, modified configuration, persistence mechanisms, and signs that the gateway touched internal resources it should not normally access. If the device mediated remote access, assume the blast radius may include credentials, sessions, and internal trust relationships.

That is why the best follow-up is not just patch verification, but compromise assessment. If the gateway handled sensitive authentication or session material, rotate anything that could have been observed or replayed during the exposure window, especially VPN credentials, administrative credentials, and any dependent certificates or shared secrets that would let an attacker re-enter through the same path. If you find evidence of lateral movement, treat the appliance as a pivot point rather than an isolated bug.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires prioritized vuln handling and exposure tracking.
Recommendation — Prioritize and remediate KEV-listed gateway vulnerabilities immediately.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE demands prompt remediation and verification on affected gateways.
	RA-5 — Vulnerability Monitoring and Scanning	Confirm exposure and identify affected appliances before and after remediation.
	IR-4 — Incident Handling	Active exploitation requires compromise checks and incident response actions.
Recommendation — Remediate the flaw quickly and verify the fix on exposed systems. Scan for affected gateways and track remediation status continuously. Investigate for compromise and contain any impacted gateway promptly.
NIST CSF 2.0	DE.CM-01 — Monitoring for Anomalies and Events	VPN and gateway telemetry is needed to spot exploit activity and compromise.
Recommendation — Monitor gateway logs and sessions for anomalous exploitation indicators.

Practitioner Guidance

What to prioritise: Start with asset confirmation and exposure reduction, because internet-facing VPN gateways move to the front of the queue the moment KEV confirms active exploitation. If you cannot patch immediately, restrict access paths and increase log review before you do anything else.

What to verify: Verify the exact product footprint, whether Site to Site VPN or Remote Access VPN is enabled, and whether the gateway showed anomalous sessions, config changes, or post-compromise activity during the exposure window. A clean patch is not enough if the device was already used as an entry point.

What practitioners underestimate: Teams often focus on the CVE as a software defect and miss the trust boundary it sits behind. For a VPN gateway, the main question is whether the flaw exposed internal access paths, not just whether the box itself remained stable.

Practitioner takeaway: Once a VPN gateway CVE is in KEV, treat it as a live access-path event, not a routine patch item, and combine remediation with a targeted compromise check.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org