What is the CVSS score of CVE-2026-44596?

CVE-2026-44596 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of Yamcs are affected by CVE-2026-44596?

Yamcs mission control systems before version 5.12.7 lack brute-force protection on the authentication endpoint, and publicly available exploit code exists, enabling unauthenticated attackers to…. A patch is available.

Is there a public PoC exploit available for CVE-2026-44596?

Yes, a public proof-of-concept exploit is available for CVE-2026-44596. Prioritise patching immediately. EPSS: 0.1%.

How to fix or mitigate CVE-2026-44596?

Within 24 hours: Identify all systems running Yamcs and document current versions; implement immediate compensating controls such as WAF or reverse proxy rate limiting on the POST /auth/token endpoint (target: 5 requests per IP per second), and enable account lockout policies if configurable. Within 7 days: Develop and test upgrade plan to Yamcs 5.12.7 in a non-production environment, verifying compatibility with existing mission-critical processes. Within 30 days: Execute phased deployment of Yamcs 5.12.7 across all production instances, with full monitoring and rollback procedures in place.

Yamcs CVE-2026-44596

EUVD-2026-44956 CRITICAL

Improper Restriction of Excessive Authentication Attempts (CWE-307)

2026-05-27 https://github.com/yamcs/yamcs

GHSA-w5r6-mcgq-7pq4

Java Information Disclosure

9.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

9.8 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

4.8 MEDIUM

Endpoint is remote and unauthenticated (AV:N/PR:N/UI:N), but compromise requires guessing a weak credential (AC:H) and the flaw itself only facilitates conditional, partial account access (C:L/I:L/A:N), not the vendor's C:H/I:H/A:H.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Updated

Jul 17, 2026 - 18:59 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 17, 2026 - 18:52 vuln.today

cvss_changed

Severity Changed

Jul 17, 2026 - 18:52 NVD

MEDIUM CRITICAL

CVSS changed

Jul 17, 2026 - 18:52 NVD

6.5 (MEDIUM) 9.8 (CRITICAL)

Source Code Evidence Fetched

May 27, 2026 - 00:30 vuln.today

Analysis Generated

May 27, 2026 - 00:30 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

6 maven packages depend on org.yamcs:yamcs-core (6 direct, 0 indirect)

Ecosystem-wide dependent count for version 5.12.7.

DescriptionNVD

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:

java

// 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

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

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

Fix

Implement DRF-style throttling on /auth/token:

java

// 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)
}

Articles & Coverage 1

POC CVE-2026-44596: YAMCS yamcs-core < 5.12.7 Allows Unlimited Brute Force on Authentication Endpoint May 29, 2026

AnalysisAI

Missing brute-force protection in Yamcs (Yet Another Mission Control System) before 5.12.7 lets unauthenticated remote attackers submit unlimited password-guessing requests to the POST /auth/token endpoint in yamcs-core, which enforces no rate limiting, account lockout, or throttling (CWE-307). Publicly available exploit code exists (Exploit-DB 52605), though EPSS estimates real-world exploitation probability at only 0.05% (17th percentile) and the flaw is not listed in CISA KEV. The upstream fix (5.12.7) introduces a per-IP request cap defaulting to 5 auth requests per second.

Technical ContextAI

Yamcs is an open-source Java-based mission control system used to command and monitor spacecraft, satellites, and other remote payloads. The vulnerable component is the HTTP authentication layer in yamcs-core (Maven package org.yamcs:yamcs-core), specifically AuthHandler.handleToken() in AuthHandler.java, which serves OAuth-style password grant tokens via POST /auth/token backed by the SecurityStore login flow. The root cause is CWE-307 (Improper Restriction of Excessive Authentication Attempts): the handler passed every request straight to getSecurityStore().login() with no throttle, failed-attempt counter, CAPTCHA, or lockout, and neither the quickstart nor documentation guided operators to add such controls. The patch adds a new IP_LIMIT_CACHE with a per-IP counter, a configurable maxAuthRequestsPerSecond option (default 5), a HandlerContext fix to correctly parse the first X-Forwarded-For hop, and a new TooManyRequestsException that returns HTTP 429.

RemediationAI

Vendor-released patch: upgrade yamcs-core to 5.12.7 (or 5.13.0), which adds per-IP authentication rate limiting via the new maxAuthRequestsPerSecond HTTP server option (default 5 requests/second) and returns HTTP 429 on excess; see the advisory at https://github.com/yamcs/yamcs/security/advisories/GHSA-w5r6-mcgq-7pq4 and fix commit https://github.com/yamcs/yamcs/commit/309218c651680f79df11a8d0f8628f7033f98a83 with release https://github.com/yamcs/yamcs/releases/tag/yamcs-5.12.7. If immediate upgrade is not possible, place the /auth/token endpoint behind a reverse proxy or WAF that enforces request rate limits and IP-based throttling (note: this shifts correct client-IP handling to the proxy and requires trusting X-Forwarded-For), restrict network access to the Yamcs HTTP port (default 8090) to trusted management networks or VPN rather than exposing it to the internet, and enforce strong non-default passwords plus account lockout at the identity-provider level while rotating known default accounts such as 'operator'. These controls reduce brute-force feasibility but do not replace the throttling the patch provides.