VYPR
Moderate severityGHSA Advisory· Published May 27, 2026· Updated May 27, 2026

Yamcs has No Rate Limiting on Authentication Endpoint

CVE-2026-44596

Description

Summary

The authentication endpoint POST /auth/token in yamcs-core lacks any form of rate limiting, account lockout, or failed attempt throttling. As a result, an unauthenticated remote attacker can perform unlimited password guessing attempts against any user account.

This missing rate limiting vulnerability (CWE-307) significantly increases the risk of successful brute-force attacks.

Root

Cause

File: yamcs-core/src/main/java/org/yamcs/http/auth/AuthHandler.java

POST /auth/token has no rate limiting, no lockout after failed attempts, and no CAPTCHA. The handler processes unlimited authentication requests without any throttling mechanism:

// AuthHandler.java — handleToken()
// No throttle, no failed attempt counter, no lockout
private void handleToken(HandlerContext ctx) {
    ...
    getSecurityStore().login(token).whenComplete((info, err) -> {
        // Directly attempts authentication with no rate check
    });
}

This is absent by default — the official quickstart and documentation contain no guidance on configuring rate limiting.

Impact

An attacker can make unlimited authentication attempts against any account. This enables efficient brute-force attacks against any account.

Proof of

Concept

# 20 attempts — zero rate limiting
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "Attempt $i: HTTP %{http_code}\n" \
    -X POST "http://TARGET:8090/auth/token" \
    -d "grant_type=password&username=operator&password=operator12$i"
done
# All return HTTP 401 — no HTTP 429 ever

Confirmed: 20 attempts in 0.07 seconds, no rate limiting enforced.

Fix

Implement DRF-style throttling on /auth/token:

// Track failed attempts per IP
private static final Cache<String, Integer> FAILED_ATTEMPTS =
    CacheBuilder.newBuilder().expireAfterWrite(15, TimeUnit.MINUTES).build();

private static final int MAX_ATTEMPTS = 10;

private void handleToken(HandlerContext ctx) {
    String ip = ctx.getRemoteAddress();
    int attempts = Optional.ofNullable(FAILED_ATTEMPTS.getIfPresent(ip)).orElse(0);
    if (attempts >= MAX_ATTEMPTS) {
        throw new TooManyRequestsException("Rate limit exceeded");
    }
    // ... existing auth logic
    // On failure: FAILED_ATTEMPTS.put(ip, attempts + 1)
}

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Yamcs-core authentication endpoint lacks rate limiting, allowing unlimited brute-force password guessing against any account.

Vulnerability

The POST /auth/token endpoint in yamcs-core (file yamcs-core/src/main/java/org/yamcs/http/auth/AuthHandler.java) contains no rate limiting, account lockout, or failed-attempt throttling (CWE-307). The handleToken() method directly calls getSecurityStore().login(token) without any check on request frequency or consecutive failures, as confirmed in the codebase [1][2]. This affects all versions using the default implementation, with no built-in configuration for rate limiting in the official quickstart or documentation [1][2].

Exploitation

An unauthenticated remote attacker can send arbitrary numbers of POST /auth/token requests with guessed credentials (e.g., using grant_type=password&username=operator&password=). The server responds with HTTP 401 on failure but never returns HTTP 429 (too many requests), enabling the attacker to test passwords as fast as the network allows — for example, 20 attempts completed in 0.07 seconds [1][2].

Impact

Successful brute-force compromise of any valid user account, leading to full authentication bypass and access to yamcs-core system functions using the victim’s privileges. The attack requires no prior authentication or special network position, only HTTP reachability to the endpoint [1][2].

Mitigation

No official patched release has been published as of the advisory date (2026-05-27). The vendor recommends implementing DRF-style throttling on /auth/token, e.g., tracking failed attempts per IP with CacheBuilder.newBuilder().expireAfterWrite(15, TimeUnit.MINUTES).build() and rejecting requests after 10 failures ([1][2]). Until a patch is available, administrators should add an external rate-limiting reverse proxy (e.g., Nginx limit_req) or a web application firewall rule in front of the yamcs-core service. The CVE is not listed on CISA’s Known Exploited Vulnerabilities catalog.

AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected packages

Versions sourced from the GitHub Security Advisory.

PackageAffected versionsPatched versions
org.yamcs:yamcs-coreMaven
< 5.12.75.12.7

Affected products

2

Patches

0

No patches discovered yet.

Vulnerability mechanics

Root cause

"Missing rate limiting, account lockout, and failed-attempt throttling in the `POST /auth/token` handler allows unlimited password guessing."

Attack vector

An unauthenticated remote attacker sends repeated `POST /auth/token` requests to the target server (default port 8090) with `grant_type=password`, a target username, and a guessed password [ref_id=1][ref_id=2]. Because the handler lacks any rate limiting, account lockout, or CAPTCHA, the attacker can fire hundreds of requests per second — the advisory confirms 20 attempts complete in 0.07 seconds with no HTTP 429 response ever returned [ref_id=1][ref_id=2]. This enables efficient brute-force password guessing against any user account [CWE-307, note: CWE-307 is pre-assigned to this CVE in the summary].

Affected code

The vulnerability resides in `yamcs-core/src/main/java/org/yamcs/http/auth/AuthHandler.java`, specifically in the `handleToken()` method that processes `POST /auth/token` requests [ref_id=1][ref_id=2]. The handler directly calls `getSecurityStore().login(token)` without any throttle, failed-attempt counter, or lockout mechanism [ref_id=1][ref_id=2]. No rate-limiting configuration is present in the official quickstart or documentation [ref_id=1][ref_id=2].

What the fix does

The advisory recommends implementing DRF-style throttling by tracking failed attempts per IP address using a Guava Cache with a 15-minute expiry [ref_id=1][ref_id=2]. When the count for an IP reaches `MAX_ATTEMPTS` (suggested value: 10), the handler should throw a `TooManyRequestsException` instead of proceeding with authentication [ref_id=1][ref_id=2]. On each failed login, the per-IP counter is incremented; on success it would be reset. No official patch commit is provided in the bundle — the fix is described only as advisory guidance [ref_id=1][ref_id=2].

Preconditions

  • authNo authentication required — the endpoint is publicly accessible
  • networkAttacker must have network access to the target's /auth/token endpoint (default port 8090)
  • configNo rate-limiting or lockout configuration must be in place (default configuration)

Reproduction

```bash # 20 attempts — zero rate limiting for i in $(seq 1 20); do curl -s -o /dev/null -w "Attempt $i: HTTP %{http_code}\n" \ -X POST "http://TARGET:8090/auth/token" \ -d "grant_type=password&username=operator&password=operator12$i" done # All return HTTP 401 — no HTTP 429 ever ```

Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

2

News mentions

0

No linked articles in our index yet.