CISA adds four exploited vulnerabilities: what IT leaders should check

The US Cybersecurity and Infrastructure Security Agency (CISA) announced on 22 September 2026 that it had added four vulnerabilities to its Known Exploited Vulnerabilities catalogue. This CISA KEV update matters to Australian businesses using potentially affected Check Point, Arista VeloCloud Orchestrator or F5 systems, including equipment operated by a service provider.

CISA reports evidence of exploitation. That makes these entries worth prompt investigation, but the announcement alone does not establish whether your particular systems are vulnerable. The practical task is to check the complete entries, consult vendor guidance and turn confirmed exposure into an owned remediation plan.

What the CISA KEV update identifies

CISA’s announcement identifies these four vulnerabilities:

| CVE | Product label in the announcement | Vulnerability category | | --- | --- | --- | | CVE-2026-85102 | Check Point multiple products | Improper certificate validation | | CVE-2026-93616 | Check Point multiple products | Path traversal | | CVE-2026-93952 | Arista VeloCloud Orchestrator | Improper input validation | | CVE-2026-94127 | F5 BIG-IP APM | Heap-based buffer overflow |

Treat these as investigation starting points, not a complete affected-product list. Broad labels such as “multiple products” do not tell you which appliance, software release or configuration is affected. A vulnerability category also does not establish the exact attack prerequisites or consequences.

Avoid inferring that every installation is vulnerable, that every issue is remotely exploitable without authentication, or that one update addresses all four entries.

Read the complete entries and vendor advisories

For each CVE in the CISA KEV update, open the CISA KEV catalogue, search the exact identifier and read the entire record. Follow its reference links to the original vendor advisory rather than relying on search snippets or a third-party summary.

Build a short evidence record containing:

• The CVE, catalogue addition date and required action.
• Any listed due date, notes and linked guidance.
• The vendor advisory URL, revision date and time checked.
• Affected products, versions, components and configuration conditions.
• Fixed releases, supported upgrade paths and temporary mitigations.
• Any instructions to investigate compromise or discontinue unsupported products.

Check whether remediation involves a hotfix, a full upgrade, a configuration change or several steps. Record restart requirements and dependencies before scheduling work.

If the catalogue and advisory appear inconsistent, escalate to vendor support and retain both references. Do not turn an unresolved interpretation into a “not affected” result. This article does not supply affected version ranges or fixed builds; those must come from the current authoritative guidance.

Match affected products against your actual inventory

A purchasing record is not enough. Compare the advisories with live asset information, including exact installed builds and enabled features where relevant. Search by both CVE and product name because inventory labels may differ from the announcement.

Include physical appliances, virtual appliances, management systems, standby nodes, disaster recovery environments and provider-managed infrastructure. An inactive failover device can become tomorrow’s production system.

For every possible match, record:

| Check | Evidence to collect | | --- | --- | | Product identity | Product, component, release and exact build | | Applicability | Vendor conditions matched against the configuration | | Exposure | Reachable interfaces, access controls and network paths | | Ownership | Technical owner, service provider and business approver | | Business impact | Dependent services and acceptable interruption | | Recovery | Configuration backup, restoration steps and rollback constraints |

Classify results as affected, not affected with evidence, or unconfirmed. Missing version information belongs in the third category, not the second.

Where a provider operates the system, ask for written confirmation of applicability, planned action and completion evidence. “Managed by someone else” is an ownership detail, not a remediation status.

Prioritise risk without importing US federal deadlines

The CISA KEV update refers to Binding Operational Directive 26-04, which CISA says establishes requirements for US Federal Civilian Executive Branch agencies. Those requirements are not automatically obligations for Australian businesses.

A catalogue deadline can inform urgency, but it is not a local legal deadline simply because CISA publishes it. Assess applicable contracts, regulatory duties, insurance conditions and internal policies separately.

For confirmed affected assets, prioritise using practical questions:

• Can an attacker reach the vulnerable component? Check internet exposure and relevant internal access paths.
• What conditions are required? Use the vendor’s description of authentication, enabled features and other prerequisites.
• What could be affected? Consider privileged access, sensitive information and dependent services.
• Is there evidence of suspicious activity? Suspected compromise needs incident handling alongside remediation.
• Can an effective fix or mitigation be applied now? Check support status and operational constraints.

Known exploitation is a strong reason to move an applicable vulnerability ahead of routine maintenance. It does not mean every affected system has identical risk. Set a documented target and accountable owner for each asset, and escalate unconfirmed exposure promptly.

For broader planning, see our AI cyber threats checklist. Technology changes, but verified assets, access controls and response ownership remain essential.

Remediate with a controlled change plan

For each affected system, create a change record linking the CISA entry, vendor advisory and asset evidence. Identify the approved target build or mitigation, implementation steps, business approver and validation procedure.

Before starting, confirm that configuration backups are usable and that the proposed upgrade path is supported. Check capacity and failover arrangements where applicable. Do not assume a standby system makes an upgrade interruption-free.

If immediate patching is not practical, assess vendor-supported mitigations and exposure reduction. Restricting a reachable interface may reduce risk, but it is not equivalent to installing a fix unless authoritative guidance establishes that result.

Give every temporary measure an owner, review date and permanent remediation plan. If no safe workaround exists, escalate the decision about isolation or service interruption rather than silently accepting exposure.

The CISA KEV update should trigger a tracked workflow, not an email that disappears into a shared inbox.

Check for compromise and verify closure

Installing an update does not prove that earlier exploitation did not occur. Review vendor investigation guidance and available logs, particularly where a vulnerable service was exposed or suspicious activity has already been identified.

Preserve relevant evidence before disruptive changes where practicable. Follow your incident response process if investigation indicates possible compromise; avoid improvising cleanup that could destroy useful records.

After remediation, verify the installed build or configuration directly. Check relevant cluster members and standby systems, confirm that dependent services work, and repeat applicable vulnerability checks. A successful change ticket alone is not proof of closure.

Keep the advisory revision, before-and-after evidence, test results and any residual risk in the record. Recheck advisories for revised instructions. For another perspective on evaluating security announcements, read Microsoft Project Perception: what SMBs should check.

Turn the alert into a documented decision

The useful outcome of this CISA KEV update is a verified answer for each relevant asset: unaffected with evidence, remediated and checked, or awaiting action under an explicitly approved risk decision.

Tech Engine can help review your cyber security, reconcile asset inventories and coordinate remediation with your IT team and providers. Call 1300 088 324, email sales@techengine.au or visit aiaas.au to discuss your review.