Skip to main content

Yamcs EUVDEUVD-2026-67840

| CVE-2026-55547 MEDIUM
Improper Authorization (CWE-285)
2026-08-28 https://github.com/yamcs/yamcs GHSA-cvw4-55pp-3hfq
4.3
CVSS 3.1 · Vendor: https://github.com/yamcs/yamcs
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain valid low-privilege Yamcs account
  2. Delivery
    Authenticate to Yamcs HTTP API (port 8090)
  3. Exploit
    GET /api/privileges returns complete privilege taxonomy
  4. Execution
    Identify high-value roles (ControlAccess, ChangeMissionDatabase)
  5. Persist
    Target privileged account holders for credential theft
  6. Impact
    Escalate to administrator-level access

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization verification
MITRE ATT&CK

1 technique across 1 tactic: Defense Evasion

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires a valid authenticated session with any Yamcs account - including the lowest-privilege operator, read-only, or guest-level accounts - established via HTTP Basic Auth or equivalent. Unauthenticated (anonymous) access cannot reach these endpoints. The vulnerability affects any Yamcs deployment where authentication is enabled, which is the production default. Deployments using only YamlAuthModule may receive an empty body from GET /api/roles (role objects are not persisted into the security store Directory in that auth backend), but GET /api/privileges always returns the full 31-privilege list regardless of auth module. No special network position, non-default configuration, or elevated privilege is required beyond possessing any valid account credential. Exploitation is limited by the requirement for at least low-privilege authentication (CVSS PR:L); purely external unauthenticated attackers cannot exploit this directly.

Impact

The NVD-assigned CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) accurately reflects the direct impact - limited confidentiality exposure of privilege metadata, not raw data or credentials. However, the real-world risk in Yamcs operational deployments is materially higher than the score implies: the disclosed privilege list (31 system privileges including ControlAccess and ChangeMissionDatabase) provides an attacker with the exact labels needed to identify high-value targets and chain subsequent attacks. The advisory explicitly notes ChangeMissionDatabase enables algorithm-level RCE. A POC is confirmed in the GHSA advisory, lowering exploitation effort. No EPSS score was provided in the input data. No CISA KEV listing exists at time of analysis, indicating no confirmed widespread active exploitation, though the niche deployment context (spacecraft operations) means KEV coverage may lag real-world targeting. The primary limiting factor is the PR:L requirement - exploitation is bounded to users with any valid Yamcs account.

Exploit ScenarioDerived

An attacker with a valid operator-level Yamcs account - obtained through credential theft, a shared service account, or social engineering - issues a single unauthenticated HTTP GET to /api/privileges with their Basic Auth header. The server responds with HTTP 200 and the complete list of 31 system privileges including ControlAccess and ChangeMissionDatabase. The attacker then queries /api/roles to map which roles carry those privileges, identifies which administrator accounts hold those roles, and proceeds to target those accounts for credential theft or session hijacking. A POC demonstrating this exact sequence is confirmed in the GHSA advisory.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Aug 28, 2026

Missing authorization checks on three IAM REST API endpoints in Yamcs allow any authenticated low-privilege user to enumerate the server's complete privilege taxonomy and role-to-privilege mappings, directly enabling targeted privilege escalation reconnaissance. Affected are yamcs-core versions up to 5.12.7 and 5.13.0 through 5.13.1, used in production spacecraft operations and ground station environments. A proof-of-concept is confirmed in the GHSA advisory; no active exploitation (CISA KEV) has been identified, but the leaked data (including the ControlAccess and ChangeMissionDatabase privilege names) provides a precise roadmap for chained attacks including, per the advisory, algorithm-level remote code execution.

RemediationAI

Upgrade yamcs-core to version 5.12.8 (for 5.12.x deployments) or 5.13.2 (for 5.13.x deployments); both releases add ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess) as the first statement in listRoles, getRole, and listPrivileges in IamApi.java, confirmed by patch commits at https://github.com/yamcs/yamcs/commit/c2aec1c242e656e48b52c7f87deea88183bb592d and https://github.com/yamcs/yamcs/commit/dcaec5f0b2f4231b8e313e94d79a937169c9e0ba. If immediate patching is not feasible, restrict network access to the Yamcs HTTP API port (default 8090) to trusted operator networks only via firewall or network segmentation - this limits the pool of authenticated users who can reach the unprotected endpoints, though it does not eliminate the flaw. Additionally, audit and minimize the number of low-privilege accounts to reduce the effective attack surface until patching is complete.

Affected VersionsENISA

yamcs 5.13.0, < 5.13.2
yamcs < 5.12.8

Affected Packages

maven org.yamcs:yamcs-core fix: 5.12.8, 5.13.2
euvd yamcs fix: 5.12.8, 5.13.2

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in maven, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Yamcs is a Java-based mission control framework (Maven artifact org.yamcs:yamcs-core) used in satellite and spacecraft ground operations. The vulnerability is in IamApi.java, where three HTTP handler methods - listRoles (GET /api/roles), getRole (GET /api/roles/{name}), and listPrivileges (GET /api/privileges) - omit the ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess) call that every adjacent write and user-management endpoint in the same class correctly enforces. CWE-285 (Improper Authorization) describes this root cause precisely: the authorization mechanism exists and functions correctly elsewhere in the class; it was simply never invoked for these three read endpoints. The affected CPE is pkg:maven/org.yamcs:yamcs-core across both the 5.12.x and 5.13.x release lines.

Know when Java gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

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
vuln.today AI 4.3 MEDIUM

Network-accessible REST API requires any valid account (PR:L); disclosure is limited to privilege metadata with no integrity or availability impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/yamcs/yamcs).

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

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

DescriptionCVE.org

Summary

Missing authorization checks on three IAM API endpoints (GET /api/roles, GET /api/roles/{name}, GET /api/privileges) allow any authenticated user - regardless of their assigned permissions - to enumerate the complete list of system privileges and role definitions. An attacker with only a low-privilege account (e.g., a read-only operator) can retrieve the full privilege taxonomy of the server, including the names and assignments of all administrator-level capabilities. This information directly enables targeted privilege escalation attacks.

---

Details

Three handler methods in IamApi.java serve sensitive security metadata without performing any authorization check:

File: yamcs-core/src/main/java/org/yamcs/http/api/IamApi.java

java
// Line 73 - GET /api/roles
@Override
public void listRoles(Context ctx, Empty request, Observer<ListRolesResponse> observer) {
    SecurityStore securityStore = YamcsServer.getServer().getSecurityStore();
    List<Role> roles = securityStore.getDirectory().getRoles();
    // No ctx.checkSystemPrivilege() call - any authenticated user proceeds
    ...
    observer.complete(responseb.build());
}

// Line 87 - GET /api/roles/{name}
@Override
public void getRole(Context ctx, GetRoleRequest request, Observer<RoleInfo> observer) {
    SecurityStore securityStore = YamcsServer.getServer().getSecurityStore();
    Role role = securityStore.getDirectory().getRole(request.getName());
    // No ctx.checkSystemPrivilege() call
    observer.complete(toRoleInfo(role));
}

// Line 112 - GET /api/privileges
@Override
public void listPrivileges(Context ctx, Empty request, Observer<ListPrivilegesResponse> observer) {
    SecurityStore securityStore = YamcsServer.getServer().getSecurityStore();
    List<SystemPrivilege> privileges = new ArrayList<>(securityStore.getSystemPrivileges());
    // No ctx.checkSystemPrivilege() call
    observer.complete(responseb.build());
}

By contrast, all write operations and user-management endpoints in the same file correctly enforce authorization. For example:

java
// Line 126 - GET /api/users (correctly protected)
public void listUsers(...) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ← present
    ...
}

// Line 142 - POST /api/users (correctly protected)
public void createUser(...) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ← present
    ...
}

The three vulnerable endpoints share the same ControlAccess protection requirement as the user-management endpoints but were never given the corresponding check.

Route definitions (confirmed in yamcs-api/src/main/proto/yamcs/protobuf/iam/iam.proto):

GET /api/privileges   → IamApi.listPrivileges()
GET /api/roles        → IamApi.listRoles()
GET /api/roles/{name} → IamApi.getRole()

---

PoC

<img width="2324" height="1086" alt="image" src="https://github.com/user-attachments/assets/98ec3e81-556d-41e1-9211-10a5b9ad0d59" />

Environment

  • Yamcs version: 5.13.1-SNAPSHOT (latest master)
  • Auth module: YamlAuthModule (default)
  • Two accounts available: admin (Administrator) and operator (Operator)
  • Calculate the Basic Auth credentials for the two accounts (this needs to be done only once). Please modify according to the actual situation. These credentials will be used in subsequent commands. Here, there is a test low-privilege account named "operator" with the password "password".

<img width="2243" height="223" alt="image" src="https://github.com/user-attachments/assets/5614013c-2143-4f61-aba3-eab1cba24b67" />

powershell -command "[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes('admin:admin'))"

powershell -command "[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes('operator:password'))"

Step 1 - Confirm that protected endpoints correctly return 403 for low-privilege users

cmd
curl -s -o nul -w "HTTP %{http_code}" http://localhost:8090/api/users -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="

Expected: HTTP 403 - the user-list endpoint enforces ControlAccess.

Step 2 - Enumerate all system privileges with the operator account

cmd
curl -s http://localhost:8090/api/privileges -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="

Actual response (HTTP 200):

C:\Users\20616>curl -s http://localhost:8090/api/privileges -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="
{
  "systemPrivileges": ["ChangeMissionDatabase", "CommandOptions", "ControlAccess", "ControlActivities", "ControlAlarms", "ControlArchiving", "ControlCommandClearances", "ControlCommandQueue", "ControlFileTransfers", "ControlLinks", "ControlProcessor", "ControlServices", "ControlTimeCorrelation", "ControlTimeline", "CreateInstances", "GetMissionDatabase", "ManageAnyBucket", "ManageParameterLists", "ModifyCommandHistory", "ReadActivities", "ReadAlarms", "ReadCommandHistory", "ReadEvents", "ReadFileTransfers", "ReadLinks", "ReadSystemInfo", "ReadTables", "ReadTimeline", "WriteEvents", "WriteTables", "web.AccessAdminArea"]
}

The operator account receives the server's complete privilege taxonomy - all 31 system privileges including ControlAccess (full user management) and ChangeMissionDatabase (algorithm-level RCE, see related advisory).

Step 3 - Enumerate all defined roles with the operator account

cmd
curl -s http://localhost:8090/api/roles -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="

Actual response (HTTP 200):

C:\Users\20616>curl -s http://localhost:8090/api/roles -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="
{
}

The endpoint returns HTTP 200 (no authorization check triggered). The empty body reflects the test environment: the YamlAuthModule stores role names as plain strings in users.yaml and does not persist Role objects into the security store's Directory. In any Yamcs instance where roles have been created through the REST API (POST /api/roles), this endpoint returns the full role-to-privilege mapping for every defined role.

Step 4 - Attempt to read a specific role by name

cmd
curl -s http://localhost:8090/api/roles/Administrator -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="

Actual response:

C:\Users\20616>curl -s http://localhost:8090/api/roles/Administrator -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="
{
  "code": 404,
  "type": "NotFoundException",
  "msg": "Resource not found"
}

The 404 is a business-logic outcome (the role object does not exist in the Directory for this test configuration), not an authorization rejection. The server never checked whether the caller is permitted to read role data - it proceeded to the lookup and returned the lookup result. In a deployment where roles are registered as objects, this endpoint returns their full privilege configuration to any authenticated user.

Observed vs Expected

RequestExpectedActualNote
GET /api/users (operator)403403 ✓Auth check present
GET /api/privileges (operator)403200 ✗Confirmed - full privilege list leaked
GET /api/roles (operator)403200 ✗Auth check absent; empty only in this test setup
GET /api/roles/Administrator (operator)403404 ✗No auth check; 404 = role not in Directory, not access denied

---

Impact

Vulnerability type: Broken Function Level Authorization (BFLA) / Missing Authorization (OWASP API Security Top 10 2023: API5)

Who is impacted: Any deployment of Yamcs that has authentication enabled (the default for production setups) and has more than one user tier. This includes the vast majority of operational Yamcs installations in ground station, satellite operations, and mission control contexts.

Direct impact:

  • Any authenticated user, including operators, guest accounts, or service accounts with minimal privileges, can retrieve the server's complete privilege taxonomy and all role-to-privilege mappings.

Chained impact: The disclosed privilege names and role definitions provide an attacker with a precise roadmap for privilege escalation:

  1. Identify which privilege grants the capability they need (e.g., ChangeMissionDatabase for RCE via the algorithm engine, ControlAccess for full user management).
  2. Identify which roles carry that privilege.
  3. Target the accounts that hold those roles for credential theft, session hijacking, or social engineering.

In mission-critical environments (spacecraft operations, industrial control), unauthorized privilege escalation via this information leak could have safety implications beyond IT security.

---

Fix

Add ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess) as the first statement in each of the three affected methods, matching the pattern already used by adjacent endpoints in the same file:

java
// IamApi.java - apply to all three methods

public void listRoles(Context ctx, Empty request, Observer<ListRolesResponse> observer) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ADD THIS LINE
    ...
}

public void getRole(Context ctx, GetRoleRequest request, Observer<RoleInfo> observer) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ADD THIS LINE
    ...
}

public void listPrivileges(Context ctx, Empty request, Observer<ListPrivilegesResponse> observer) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ADD THIS LINE
    ...
}

Threat Intelligence Overview

EPSS Score
0.3%
Top 84% exploitable
Prevalence
Low
niche spacecraft mission control framework, aerospace sector deployments only
Threat Intel
1
1 sources
Exploit
POC
Public exploit code exists
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC Yes
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
No
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

42
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +22
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.

More in Java

View all
CVE-2012-4681 CRITICAL POC
9.8 Aug 28

Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m

CVE-2015-7450 CRITICAL POC
9.8 Jan 02

Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti

CVE-2013-2465 CRITICAL POC
9.8 Jun 18

Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent

CVE-2011-3544 CRITICAL POC
9.8 Oct 19

Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug

CVE-2010-1871 HIGH POC
8.8 Aug 05

JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to

CVE-2012-1723 CRITICAL POC
9.8 Jun 16

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up

CVE-2013-0422 CRITICAL POC
9.8 Jan 10

Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using

CVE-2012-0507 CRITICAL POC
9.8 Jun 07

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up

CVE-2015-4852 CRITICAL POC
9.8 Nov 18

The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers

CVE-2012-5076 CRITICAL POC
9.8 Oct 16

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow

CVE-2017-3066 CRITICAL POC
9.8 Apr 27

Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla

CVE-2012-0391 CRITICAL POC
9.8 Jan 08

The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy