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

CVE-2026-44595 has a CVSS 3.1 base score of 4.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. EPSS exploitation probability: 0.0%.

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

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

Is there a patch available for CVE-2026-44595?

Yes, a patch is available for CVE-2026-44595. Update the affected software to the latest version immediately.

Yamcs yamcs-core CVE-2026-44595

EUVD-2026-44954 MEDIUM

Missing Authorization (CWE-862)

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

GHSA-p2rj-mrmc-9w29

Java Authentication Bypass

4.3

CVSS 3.1 · Vendor: https://github.com/yamcs/yamcs

Severity by source

Vendor (https://github.com/yamcs/yamcs) PRIMARY

4.3 MEDIUM

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

Primary rating from Vendor (https://github.com/yamcs/yamcs) · only source for this CVE.

CVSS VectorVendor: https://github.com/yamcs/yamcs

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

May 27, 2026 - 00:28 vuln.today

Analysis Generated

May 27, 2026 - 00:28 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.

DescriptionCVE.org

Summary

The IAM API endpoints (listUsers, getUser, listGroups, and getGroup) in yamcs-core do not enforce the required SystemPrivilege.ControlAccess check. As a result, any authenticated user (even those with low or no privileges) can enumerate all user accounts in the system, including their usernames, superuser status, and group memberships.

This constitutes a broken access control vulnerability (CWE-862) that leaks sensitive user information.

Root Cause

File: yamcs-core/src/main/java/org/yamcs/http/api/IamApi.java:125,180,357,372

listUsers(), getUser(), listGroups(), and getGroup() do not require SystemPrivilege.ControlAccess. Any authenticated user - regardless of privileges - can enumerate all users, their superuser status, and group memberships:

java

// listUsers - NO checkSystemPrivilege
public void listUsers(Context ctx, Empty request, ...) {
    var sensitiveDetails = ctx.user.hasSystemPrivilege(SystemPrivilege.ControlAccess);
    // sensitiveDetails=false for low-priv users, but name/superuser/active still exposed
    for (User user : users) {
        UserInfo userb = toUserInfo(user, sensitiveDetails, directory);
        responseb.addUsers(userb);
    }
}

Compare with properly protected endpoints:

java

// createUser - correctly protected
public void createUser(Context ctx, ...) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess); // present

Impact

Any authenticated user can:

List all user accounts in the system
Identify which accounts have superuser privileges
Use this information to target privileged accounts

Proof of Concept

bash

# Authenticate as any low-privilege user GET access_token
curl -s -X POST "http://localhost:8090/auth/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=password&username=lowpriv&password=lowpriv123"
# Enumerate all users - no ControlAccess required
curl -s "http://TARGET:8090/api/users" \
  -H "Authorization: Bearer $TOKEN" #paste access_token

Output (confirmed):

json

{
  "users": [
    { "name": "admin", "superuser": true, "active": true },
    { "name": "operator", "superuser": true, "active": true },
    { "name": "lowpriv", "superuser": false, "active": true }
  ]
}

Fix

Add ControlAccess check to listUsers, getUser, listGroups, getGroup:

java

public void listUsers(Context ctx, Empty request, ...) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess); // ADD THIS
    ...
}

AnalysisAI

Broken access control in Yamcs yamcs-core allows any authenticated user to enumerate all user accounts, superuser status, and group memberships via the IAM API. The four endpoints - listUsers, getUser, listGroups, and getGroup - in IamApi.java (lines 125, 180, 357, 372) fail to call ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess), a guard that is correctly applied to write operations like createUser. Affected versions are all releases prior to 5.12.7; a proof-of-concept using a single bearer-token HTTP GET is publicly documented in the GitHub Security Advisory GHSA-p2rj-mrmc-9w29, and no active exploitation (CISA KEV) has been identified at time of analysis.

Technical ContextAI

Yamcs (Yet Another Mission Control System) is an open-source Java-based mission control framework for spacecraft operations; the core module (pkg:maven/org.yamcs:yamcs-core) exposes an HTTP/REST API. Its IAM (Identity and Access Management) layer uses a SystemPrivilege model where sensitive operations are gated by explicit calls to ctx.checkSystemPrivilege(). CWE-862 (Missing Authorization) applies here: the read-path handlers omit the gate present on all write-path handlers, creating an asymmetric privilege model. The CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N confirms the flaw is network-reachable, low complexity, requires only low-privilege authentication (PR:L), and yields a partial confidentiality impact with no integrity or availability consequences.

RemediationAI

Upgrade to org.yamcs:yamcs-core version 5.12.7 or later, which adds the missing ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess) call to listUsers, getUser, listGroups, and getGroup in IamApi.java. The advisory and patch details are at https://github.com/yamcs/yamcs/security/advisories/GHSA-p2rj-mrmc-9w29. If an immediate upgrade is not feasible, a compensating control is to restrict network access to the Yamcs HTTP API (default port 8090) at the firewall or reverse-proxy layer so that only explicitly authorized operator clients can reach /api/users and /api/groups endpoints - note this trades operational accessibility for security and may break legitimate tooling. There is no known configuration flag to disable the affected endpoints individually without modifying source code.