Proxmox VE 7: Scans and Brute Force Exploit a Logging Blind Spot

A SANS ISC diary documents brute-force attacks against Proxmox VE 7 where an authentication endpoint returns HTTP 200 even on failed logins, making the attacks invisible to monitoring that only watches for 401 responses.

A Proxmox VE 7 authentication endpoint responds with HTTP 200 even when login fails. For defenders monitoring only 401 codes, the attack leaves no trace. According to a SANS Internet Storm Center diary based on honeypot logs, this technical quirk fuels a brute-force campaign detected alongside an advisory for vulnerabilities in obsolete software versions.

Key Takeaways

A SANS ISC diary documents attack logs from IP 62.60.130.193 against Proxmox VE endpoints.
The /api2/extjs/access/ticket endpoint always returns HTTP 200; only a 77-byte payload signals failure.
The /api2/json/access/ticket endpoint alternates 401 and 308 responses in documented brute-force logs.
The 308 code preserves the POST method on redirect, unlike 301 and 302.
The cited Proxmox advisory concerns version 7 exclusively, which has been unsupported for "a couple of years."
No actual compromise is documented; the data rests on a single primary source.

The Data: What the Source Documents

Johannes B. Ullrich, Dean of Research at SANS.edu, published a technical diary on the SANS Internet Storm Center. Honeypot sensors detected a spike in port 8006 scans and additional brute-force traffic against Proxmox authentication endpoints. The source does not specify the diary's publication date.

Logs show timestamp 09/09/2026 15:26:14 +0000 for the first relevant event. IP 62.60.130.193 generated repeated POST requests to /api2/json/access/ticket, with alternating 401 and 308 responses. The 308 code, defined in RFC 7538, indicates a permanent redirect that preserves the POST method: unlike 301, the client must repeat the request with the same method and body.

On the same target, the /api2/extjs/access/ticket endpoint always returns code 200 regardless of authentication outcome. The source indicates a payload size of 77 bytes signals login failure.

"A return payload size of 77 bytes should indicate failure." — Johannes B. Ullrich, SANS Internet Storm Center

The source documents no actual compromise, nor does it identify the entity behind IP 62.60.130.193. It provides no CVE identifier, public exploit, or exact Proxmox VE 7 sub-version affected. The geographic scope and total scale of the scans are not quantified.

The Problem: Two Endpoints, Two Behaviors

The documented campaign hits two authentication endpoints simultaneously with different technical characteristics. On /api2/json/access/ticket, the attacker receives explicit feedback: 401 for bad credentials, 308 for redirect. This pattern lets defenders distinguish failed attempts from potential successes.

On /api2/extjs/access/ticket, the situation is reversed. The uniform 200 code eliminates the visible signal: a detection system configured to alert on 401 sequences will see nothing. The only residual indicator is the payload size, 77 bytes for failure.

The source does not specify whether this metric is accessible in standard monitoring systems. It does not indicate Proxmox-side logging configurations that would expose the real outcome independent of the HTTP code. The observation on 308 is limited to the code's technical property; the source does not compare this behavior with 301 or 302 nor assert that other codes would stop the attack.

Context: Advisory and Obsolete Versions

The SANS ISC diary links the detected activity to a Proxmox advisory published about a week prior. The cited vulnerability affects Proxmox VE version 7 exclusively, which has been unsupported for "a couple of years."

"About a week ago, Proxmox published an advisory revealing a vulnerability in older versions of Proxmox VE, its flagship Virtual Environment product. The vulnerability only affects version 7, which has not been supported for a couple of years now." — Johannes B. Ullrich, SANS Internet Storm Center

Version 8 and supported releases are not affected, according to the report. For operators maintaining Proxmox VE 7 installations, the end-of-life status means no security patches from the vendor.

What to Do Now

For operators with exposed Proxmox VE 7 instances, the SANS ISC diary suggests a specific verification step: check whether monitoring systems log the 77-byte payload size on the /api2/extjs/access/ticket endpoint. Anyone filtering only on HTTP 401 codes risks missing brute-force attempts on this path.

For installations on supported versions, the source rules out impact from the cited vulnerability. The implicit recommendation is migration from version 7, already out of support. The source documents no additional mitigations and provides no alternative detection patterns beyond the 77-byte payload.

What We Know and What We Don't

Verified facts: A SANS ISC diary documents brute-force logs with a 401/308 pattern on /api2/json/access/ticket and a 200/77-byte behavior on /api2/extjs/access/ticket. The Proxmox advisory came about a week before detection. Version 7 has been unsupported for "a couple of years." IP 62.60.130.193 is the only origin documented in the shown logs.

Verified limits: The exact publication date of the SANS diary is not stated. The attacker's identity is unknown. No public exploit is documented, nor is it documented whether scans led to compromises. The total scale of activity is not quantified. It is not verified whether other endpoints or versions exhibit the same 200 behavior.

The Diary's Limits

The data rests on a single primary source not corroborated by independent sources. It was not possible to independently verify the logs or the cited Proxmox advisory. The September 9, 2026 date refers to the log timestamp, not a confirmed diary publication date. No entity has been identified behind IP 62.60.130.193. The source does not use terms like "masking," "evasion," or "opportunistic logic": these are interpretations not documented in the original diary.

Information is based on the cited source and current as of publication.

Sources

Sources and references

Get DeafLetter