Check Point and F5 Fixes Need a Compromise Check, Not Just a Patch Ticket

A firewall can be updated and still leave an unanswered incident behind it. The immediate job is to close the vulnerable path. The harder job is to establish whether someone used that path before it closed. This week's Check Point and F5 advisories make that distinction operational, not theoretical.

CISA added four vulnerabilities to its Known Exploited Vulnerabilities catalog on September 22, citing evidence of active exploitation. Three of them concern Check Point and F5 products: CVE-2026-85102, CVE-2026-93616 and CVE-2026-94127. They affect different components and require different exposure checks. Their appearance in the same catalog update does not establish a common attacker, a shared campaign or an identical fix.

For operators, the useful unit of work is therefore not a vendor name on a spreadsheet. It is a specific installed product, software build, enabled configuration and reachable service. This report examines those three vulnerabilities and the published response guidance. It does not establish that any particular reader's system has been compromised, or estimate the number of victims.

Check Point's two vulnerabilities have different timelines. The company says it released the fix for the VPN certificate-handling flaw, CVE-2026-85102, on September 9. It subsequently observed exploitation attempts against Spark customers beginning September 12. The newly disclosed management vulnerability, CVE-2026-93616, is different: Check Point describes a handful of targeted exploitation observations on July 23, with a fix now available in its September 22 advisory.

Those dates matter because disclosure and exposure are not the same clock. A team assessing its own history should establish when the affected service was reachable, which build was running and when the relevant fix was installed. The vendor's observed dates are evidence about its investigation, not proof that every customer's exposure began on the same day or ended when the advisory appeared.

The management flaw allows unauthenticated script execution through a directory-traversal and file-upload weakness, according to Check Point's technical advisory. Its affected list includes Security Management, Multi-Domain Security Management, Log Server, Multi-Domain Log Server and SmartEvent. The same document says Smart-1 Cloud has already been fixed and lists Check Point Firewall Appliances and Spark Firewall as not affected by this particular management flaw.

That last qualification is essential. A product excluded from CVE-2026-93616 is not thereby cleared of CVE-2026-85102. Combining the two entries into a generic statement that a firewall is either safe or vulnerable would erase the distinction the vendor is asking customers to make. Track the findings separately, even when the same infrastructure team owns both systems.

SecurityWeek's September 23 reporting confirms the management fix paths: an R82.20 Security Hotfix, plus Jumbo Hotfix Accumulator releases for R82.10 starting at Take 45, R82 at Take 127, R81.20 at Take 170 and R81.10 at Take 192. It also reports the vendor's warning that standard LivePatch updates do not resolve this vulnerability. Administrators should confirm their exact supported upgrade path against the current advisory rather than infer safety from a recent update timestamp. The technical advisory also lists end-of-support versions as affected, so an older installation needs an explicit vendor-supported migration decision rather than an assumption that its age makes it irrelevant.

Check Point's technical guidance identifies a narrower temporary exposure control: restrict management access behind a security gateway and limit TCP port 19009 to trusted addresses. It also supplies checks for suspicious login activity and log patterns associated with potential exploitation attempts. Those checks are investigative leads. Their presence needs interpretation, and their absence should not be sold to leadership as a certificate that nothing happened.

Here is a hypothetical mistake worth avoiding. An operator sees a recent maintenance record and closes both vulnerability tickets because the appliance was patched that week. But the recorded work concerned a different component or a LivePatch that does not address the management issue. The corrective control is simple: attach the vulnerability identifier, target build and observed installed state to the change record. Evidence should connect the maintenance action to the specific problem.

The F5 issue has its own configuration gate. CERT-EU describes CVE-2026-94127 as a heap-based buffer overflow that can permit unauthenticated remote code execution when an APM access policy and an OAuth profile are configured on a virtual server. Its advisory lists affected BIG-IP APM versions in the 17.1, 17.5 and 21.1 branches. That is a reason to inspect enabled functionality, not to assume every system bearing an F5 badge is exposed.

The Canadian Centre for Cyber Security likewise identifies the combination of access policy and OAuth profile, and directs affected operators to vendor-supported fixed hotfix releases. Its response guidance includes reviewing access logs, administrative accounts and access policies, restricting management access to trusted networks, and validating remediation. It also points customers to F5 Support for an iRule mitigation when needed.

The two government advisories are useful public technical sources, but they do not replace the vendor's current installation instructions. F5's advisory page did not expose its technical body during this review. We therefore do not reproduce an installation procedure or claim to have independently validated the hotfix binaries. Obtain the matching release and any temporary mitigation through the vendor's supported process.

Independent reporting adds an important boundary. SecurityWeek, citing F5, says the affected role is an OAuth Authorization Server, not deployments using APM only as an OAuth client or resource server. It also reports F5's statement that this is a data-plane issue rather than control-plane exposure, and that appliance mode does not remove the vulnerability. That is why locking down an administrative interface should not be confused with removing the affected traffic-processing path.

In plain terms, inspect what the system actually does with incoming requests. A management restriction controls who can reach management services. It does not necessarily disable an application-facing function configured on a virtual server. This distinction is not an argument against management isolation, which the Canadian guidance recommends. It is an argument against treating one good security measure as evidence that an unrelated vulnerability has been neutralized.

CERT-EU's compromise assessment emphasizes correlation: repeated OAuth failures, suspicious audit commands and a subsequent TMM abort deserve investigation together. It explicitly cautions that a TMM core file alone is not an indicator of compromise. That is a meaningful restraint. A crash should not automatically become a declared breach, and a single reassuring log search should not automatically close the investigation.

The response therefore needs two parallel records. One should establish the current technical state: affected configuration, selected remediation and validation after the change. The other should establish what is known about the earlier exposure: retained logs, suspicious activity, unresolved questions and the person accountable for investigation. Combining them into one green status hides the difference between fixing a weakness and understanding its consequences.

Preserve evidence before disruptive changes where feasible, as CERT-EU recommends. The operational plan should coordinate that preservation with urgent containment and patching rather than use forensics as an excuse to leave a vulnerable service exposed. If a service cannot immediately be updated, record the temporary mitigation, who approved it, what it actually blocks and when the permanent fix will be completed. A workaround without an owner can quietly become the permanent architecture.

An organization also needs to understand the scope of its inventory. For Check Point, the published list reaches beyond the most obvious management server into logging and event-management roles. For F5, the published condition depends on virtual-server configuration. An inventory that records only chassis names or vendor logos cannot answer either question. Ask the responsible administrators for the relevant installed and enabled state, including systems someone assumes are merely supporting infrastructure.

That inventory exercise should remain disciplined. These advisories do not establish that every connected system needs rebuilding, that every credential has been stolen or that a specific threat actor is present. Escalate based on evidence and the incident-response team's assessment. The opposite overreach is equally unhelpful: declaring the investigation finished because a known indicator did not appear in the logs that happened to be available.

The evidence has limits worth keeping visible. Check Point's descriptions of observed attacks are company findings. The F5 exploitation reports are attributed to the vendor by the public advisories and independent coverage. CISA's catalog inclusion establishes that the agency found the entries met its exploitation criteria; it does not provide a complete victim census. None of the sources reviewed supports a claimed financial-loss total or a reliable prevalence estimate across all deployments.

For leaders who need a concise status, ask for an answer that preserves those distinctions. Which specific services were affected? Which are now fixed or temporarily mitigated? What period is being investigated? What evidence remains unavailable? What is the next decision, and who owns it? That produces a more useful operating picture than an aggregate patch percentage that conceals one exposed, consequential system.

The immediate direction is clear: use the relevant vendor guidance to close the specific vulnerable paths, then complete the compromise assessment with the people qualified to interpret the evidence. The lesson is not that security appliances are uniquely hopeless. It is that they deserve the same verified inventory, change control and incident discipline as everything they protect. A successful patch is an important result. It is not a retroactive account of what happened before it.

LaunchPad positionMatch each vulnerability to the actual build and enabled service, validate remediation, and keep earlier-compromise assessment separate from patch completion.