Skip to content
Security & Trust

One forged header is being used to probe GPUStack AI servers

SANS saw requests exploiting CVE-2026-102895, which affects GPUStack versions before 2.2.0, released months earlier

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
One forged header is being used to probe GPUStack AI servers
In brief
  • SANS Internet Storm Center reports exploit attempts against CVE-2026-102895, an authentication bypass in GPUStack versions before 2.2.0.
  • The flaw exists because the software trusts a client-supplied header to say where a request came from.
  • Check whether any GPUStack instance runs a version older than 2.2.0, and who can reach it.

A password check that believes a sticky note

A common security failure is trusting a label because it looks official. The GPUStack flaw is a clean example. A request carries a note saying it comes from the machine itself, and the software believes the note.

On November 12, Johannes Ullrich of the SANS Internet Storm Center reported exploit attempts against CVE-2026-102895. He calls it a trivial authentication bypass. The target, GPUStack, is an open-source tool for running a cluster of GPUs. SANS notes these chips usually serve AI workloads, which makes the software an attractive target.

What SANS saw

The requests are simple. SANS shows a plain GET request for the front page with one extra header, X-Gpustack-Real-IP, set to 127.0.0.1. The requests came from the address 144.91.73.103.

SANS adds that the same address has, in recent days, also looked for other AI-related resources. These include model-listing paths such as /v1/models and /v1/messages, which AI services commonly expose. The report does not say whether any attempt succeeded.

One address is one data point. It shows someone is trying the bug. It does not show how widely.

How the bug works

Many organisations put a proxy in front of an application. The proxy receives the visitor's request and passes it on. Because the application then sees only the proxy, the proxy often adds a header such as X-Forwarded-For to record the visitor's real address.

That is harmless while the header is only information. SANS explains that GPUStack goes further and makes a security decision with it. If the header names loopback, 127.0.0.1, GPUStack skips authentication. Loopback means the server talking to itself, so the software treats the caller as trusted.

The weakness is that the sender controls the header. An attacker can write 127.0.0.1 into it. SANS traces the flaw to a familiar design habit: a proxy adds a custom header, and the application downstream believes it.

Why the timeline matters

SANS says all GPUStack versions before 2.2.0 are affected. Version 2.2.0 was released at the end of June. Public disclosure of the flaw came at the end of July. The CVE ID was assigned on November 4.

So a release that avoids the flaw existed for about four months before the flaw had a number. The sources do not say who knew what in that period. The gap still raises a practical question. Tools that track patches by CVE ID may not have flagged this version until early November.

Teams that apply vendor releases on a schedule are more likely to already be on 2.2.0 or later, but should confirm the version. Teams that update only when an alert names a CVE may be running an older build.

What this shows about AI infrastructure

The lesson here is that AI infrastructure inherits old web mistakes. Nothing about this bug is new or specific to AI. It is a trust error that predates GPU clusters. What changes is the prize. A server that manages GPUs sits close to expensive compute and to the models that run on it.

The probes for model endpoints suggest the person behind that address is looking for AI services, not only this flaw. That is our reading of the paths listed. SANS only reports that the address searched for them.

Questions to put to your team

Ask these this week:

First, do we run GPUStack anywhere, including test clusters and teams' own experiments? Second, is every instance on version 2.2.0 or later? Third, can the internet reach any of them directly, or only through a proxy we control?

Fourth, does any system we run make an access decision from a header the client can set? The GPUStack advisory is GHSA-gj9m-f8ph-pmhr on GitHub. Fifth, does our patch process follow vendor release notes, or only CVE feeds?

A header is a claim, not a credential. Software that treats a header as proof lets in anyone who can write it.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: SANS Internet Storm Center.