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…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…