Two systems can both advertise authentication and still allow an attacker through without verifying a valid credential. This week's additions to the US government's Known Exploited Vulnerabilities catalog provide examples at opposite ends of the infrastructure stack: OpenSSH, which administrators use to access servers, and GPUStack, which coordinates AI model-serving infrastructure.
On 9 November 2026, CISA announced four new KEV entries, including CVE-2026-123158 in OpenSSH and CVE-2026-102895 in GPUStack. The other entries concern FreeSWITCH and IBM Aspera Faspex. The agency says all four were added based on evidence of exploitation.
OpenSSH's fix was already available on 5 November. GPUStack had also released a corrected version before the KEV announcement. The new information is not simply that patches exist. It is that attackers have used the vulnerabilities, making a review of earlier exposure as important as checking the current version.
SSHole: why some Alpine Linux servers are exposed
OpenSSH is often treated as a single software component in a vulnerability inventory. CVE-2026-123158 demonstrates why that can be misleading.
The OpenSSH 10.6p2 release notes identify the affected environment as Linux using musl libc with PAM disabled. The security issue arises from the interaction between password verification in sshd and the system's password-hashing implementation. OpenSSH's maintainers describe their change as a workaround for an underlying problem outside the SSH daemon itself.
Alpine Linux uses musl rather than glibc. Its standard OpenSSH package is an important affected configuration, as the original Wakefield research documents.
Normally, a password verifier transforms an attempted password and compares the result against stored authentication data. An account can also have a marker indicating that no password is valid. On affected systems, an error result from the hashing function could be mistaken for a match with such a marker. Under the conditions described in the advisory, an account that should not accept password authentication could instead be admitted.
This is a failure in the interface between two components. The password was not cracked and the stored credential did not have to be recovered. The server made an incorrect authentication decision.
The bug does not affect every OpenSSH installation. A server using a different C library or PAM-based authentication may be outside the affected configuration. The Ubuntu security tracker, for example, lists the examined mainstream Ubuntu releases as not affected. An OpenSSH version number on its own cannot establish exposure.
The upstream corrected release is Portable OpenSSH 10.6p2. Distribution-maintained packages may contain a backported workaround while keeping an older upstream version. Cloudflare Radar's SSHole advisory records the publication of corrected Alpine packages as well. Operators need their own distribution's security status, not a comparison against an upstream release number alone.
A small container can still present a real SSH boundary
Alpine is widely used for compact container images, but an Alpine-based image does not automatically run an SSH server. Many application containers expose only their application protocol. In that case, the mere presence of musl in the image does not make this vulnerability remotely reachable.
The relevant distinction is whether the workload actually runs an affected sshd, allows the applicable authentication path and exposes the service to a potential attacker. A lightweight VPS based on Alpine may have very different exposure from an application image that does not contain sshd at all.
There is a second boundary after authentication: the privileges of the account and the isolation of the environment. An account inside a container does not automatically have the same authority as root on the host. However, access to mounted credentials, sensitive volumes or administrative sockets could make a container compromise more serious.
Malaysia's MyCERT advisory of 11 November summarizes observed exploitation and post-compromise activity reported by GreyNoise. The agency describes confirmed activity associated with persistence and command-and-control components. Those observations support investigating affected systems rather than assuming a passwordless account was always inaccessible.
GPUStack: when a reverse proxy changes the meaning of localhost
GPUStack's CVE-2026-102895 is unrelated to password hashing. The project advisory in the GitHub Advisory Database describes versions before 2.2.0 as vulnerable and identifies 2.2.0 as the corrected release.
The issue lies in a shortcut that treated requests considered local to the server as belonging to an administrator under the default configuration. A reverse proxy running on the same machine can make externally initiated requests appear local to the application. The advisory also describes insufficient validation of forwarded client-address information.
The fundamental distinction is between the network endpoint that delivered a request and the person or service that initiated it. An HTTP server may see a connection from a local proxy even though the original user is on another network. Local transport is not proof of a privileged identity.
According to the advisory, an attacker reaching the affected interface could acquire administrative access without credentials. That access can extend to model and worker management, configuration changes, persistent API credentials and secrets available to the control plane. The project also reports exploitation against version 2.1.1 involving malicious custom inference backends and code execution on worker machines.
That last point deserves attention from GPU hosting providers. A worker node may be unreachable from the internet and still accept tasks from a compromised control plane. Restricting direct access to the GPU machines is valuable, but it does not contain an administrative compromise if the controller is authorized to start workloads on them.
GPUStack 2.2.0 removes the implicit local-administrator path and strengthens client-address handling. The project's advisory also identifies temporary controls for installations that cannot be updated immediately, including mandatory local authentication and restricting API exposure. These are vendor-documented mitigations, not evidence that a previously exposed deployment remains uncompromised.
What the two vulnerabilities have in common
SSHole turns an error into a successful credential comparison. GPUStack turns a network-location assumption into administrative authority. The mechanisms are different, but both produce an identity decision that is stronger than the evidence supporting it.
The implications are also different. The SSH flaw may provide an interactive account session on a vulnerable machine. GPUStack can expose a centralized administrative interface spanning several model workers and integrations. A single vulnerable control plane may therefore have a larger operational blast radius than an isolated SSH endpoint.
Neither CVE requires every product with the same name to be affected. Inventory quality determines whether patching teams can separate a vulnerable deployment from an unaffected one.
Why a successful update cannot close the entire incident
CISA's announcement refers to Binding Operational Directive 26-04, which establishes federal civilian agency requirements around risk-based remediation and forensic triage. The MyCERT advisory records the 12 November KEV deadline and the triage requirement for SSHole. That deadline is not a universal legal obligation for private hosting companies.
The underlying operational lesson applies much more broadly. A fixed SSH daemon will not remove a persistence mechanism that an attacker installed previously. Updating GPUStack will not necessarily revoke an administrative credential that was created before the fix.
For an affected SSH host, historical authentication and account changes matter. For a GPU control plane, administrative users, API credentials, custom model backends and downstream worker activity can all be relevant to assessing earlier access. Whether secrets need replacement depends on the privileges and data exposed by the affected system.
A version report tells an operator whether the original weakness remains in the installed software. It cannot tell the operator whether someone used that weakness yesterday. That is the practical significance of this week's KEV additions.