Exploited vulnerabilities · Briefing
CISA adds GPUStack, FreeSwitch, OpenSSH and Aspera Faspex vulnerabilities to KEV
CISA cites active exploitation behind four catalogue additions. Defenders should identify exposed installations and investigate possible compromise alongside remediation.
Kinwilder research desk · · AI-assisted analysis
What is established
In an alert published on 9 November 2026, CISA announced four additions to its Known Exploited Vulnerabilities (KEV) Catalog, citing evidence of active exploitation. That makes these entries an immediate inventory and remediation priority for defenders. The entries are:
- CVE-2026-102895 — GPUStack: improper authentication.
- CVE-2026-116779 — SignalWire FreeSwitch: code injection.
- CVE-2026-123158 — OpenBSD OpenSSH: unexpected status code or return value.
- CVE-2026-123218 — IBM Aspera Faspex: incorrect authorization.
These identifiers and descriptions come from the CISA alert.
Who is behind it
Attribution is not established in the supplied alert.
Analysis: A shared catalogue announcement does not establish a shared campaign. Defenders should keep actor identity, malware, ransomware affiliation, state association and operator geography as separate questions. None should be filled in from a weakness label.
Our analysis
Analysis: The immediate problem is prioritisation under incomplete technical information. Evidence of exploitation raises urgency, but a product name alone cannot establish whether a particular installation is vulnerable. Asset ownership, installed release, reachable interfaces and configuration must connect the alert to an actual exposure.
The descriptions suggest different questions about trust boundaries. Authentication asks whether a requester has established an identity. Authorization asks whether that identity may perform the particular operation. Code injection concerns whether supplied data can acquire the authority of executable instructions. The OpenSSH description is too broad to infer a specific bypass or execution path.
From an attacker's perspective, the opportunity is to make a system accept a request or interpretation that should require greater authority. From a defender's perspective, the same boundary must reject insufficiently trusted input while preserving legitimate work. These are conceptual explanations, not reconstructed attack paths for the listed CVEs.
The basic principle is to verify authority where an operation takes effect. A successful login should not implicitly authorize every subsequent action, and an unexpected result should not silently become permission to proceed.
Possible AI applications are also analysis: attackers could use models to organise public product information and identify promising targets. Defenders could use them to reconcile inventory names, summarise advisories and draft assessment questions. Human operators should verify those outputs against authoritative records before making changes; these possibilities do not establish AI involvement here.
Defensive actions
CISA encourages organisations to prioritise KEV remediation in its alert. The following are Kinwilder's defensive recommendations:
-
Establish applicability. Assign an owner to each matching product. Record the installed release, deployment role, external reachability and available vendor guidance. Resolve ambiguous inventory matches before treating a system as either vulnerable or cleared.
-
Reduce exposure and select remediation. Obtain the corresponding vendor advisory to identify affected releases, fixes and supported mitigations. Where operationally appropriate, restrict unnecessary access while that assessment proceeds. Document dependencies before disabling a service, and verify that intended restrictions actually apply at the reachable interface.
-
Investigate alongside remediation. Preserve available authentication, application, administrative and host logs. Review unexpected identities, permission changes, unusual service activity and unexplained configuration changes. These are general investigative leads, not published indicators for these CVEs. A completed update should not, by itself, close the compromise investigation.
-
Verify the boundary. In an authorised staging environment, choose a sensitive operation and compare an account permitted to perform it with one that lacks permission. Confirm both the decision and its audit record. Where supported, check that errors leave the operation denied. This is a defensive verification exercise, not a reproduction of these vulnerabilities.
Key concepts
- KEV: CISA's catalogue identifying vulnerabilities supported by evidence of exploitation.
- Authentication: Establishing who or what is making a request.
- Authorization: Deciding whether that requester may perform a specific action.
- Trust boundary: A point where information or requests cross between different levels of authority and require checks.
Limits
This is single-source reporting. The alert supplies no affected versions, fixed releases, named victims, countries or exploitation timeline. Its publication date does not establish when attacks began. Kinwilder did not reproduce the vulnerabilities. Technical pathways and defensive exercises above are explicitly labelled analysis or recommendations.
Kinwilder briefing: AI-written analysis of public reporting, checked in a separate AI review against the linked sources. No human expert review or independent reproduction is implied.