Brute-forcing the Ground Station: Two Medium Bugs, One Path Into Yamcs Mission Control

A missing authorization check and a missing rate limit look minor on their own. Chained, they point from any low-privilege login toward operator access on a spacecraft control server. Here is how the chain works, why the ground segment is the prize, and what our sensors do and do not see.

What Yamcs is, and where it sits

Yamcs, short for Yet Another Mission Control System, is an open-source Command, Control, and Communication framework maintained by Space Applications Services. It monitors and controls remote systems across simulation, testing, and live operations: spacecraft, payloads, rovers, and ground stations. It handles manual and automated commanding, command stacks and procedures, telemetry processing, alarms, and mission timelines, and it speaks the space-sector protocols including CCSDS. In plain terms, it is the console operators sit at to talk to something that is flying.

That is exactly what makes it interesting to an attacker. The satellite itself is hard to reach, but the ground segment is ordinary infrastructure: Java servers, web APIs, and login screens. It is reachable in ways an orbiting spacecraft is not, and it holds the commanding authority over what happens up there. Yamcs is used on real missions, notably ESA's OPS-SAT, which puts it squarely in the space-sector critical infrastructure conversation.

The two flaws

Both were reported in May 2026 and fixed on May 27 in yamcs-core 5.12.7. Both are the kind of quiet defect that a code review can miss and a scanner rarely flags with urgency.

CVE-2026-44595, missing authorization in the IAM API. Classified as CWE-862, this is a broken access control flaw. The identity and access management endpoints, listUsers, getUser, listGroups, and getGroup, fail to enforce the required SystemPrivilege.ControlAccess check. The result is that any authenticated user, including a freshly created account with no privileges at all, can call GET /api/iam/users and retrieve every username, every superuser flag, and every group membership. It is pure reconnaissance, but it removes all the guesswork about who the high-value accounts are.

CVE-2026-44596, no rate limiting on authentication. Classified as CWE-307, improper restriction of excessive authentication attempts, this one lives at POST /auth/token. The endpoint accepts grant_type=password requests with no throttling, no lockout, and no backoff. It returns HTTP 401 for a bad password indefinitely and never returns HTTP 429, so an unauthenticated attacker can run a password-guessing attack at the full speed of the network.

How the chain works

Read on its own, a user-enumeration bug is an information leak and a missing rate limit is a hardening gap. Read together, they are a two-step plan.

First, an attacker with any foothold account calls the IAM API and lists the users, learning which names carry superuser status. Yamcs supports self-registration and various identity providers in some deployments, so obtaining that first low-privilege account is not always a high bar. Second, they take those exact usernames to the token endpoint and brute-force the passwords, unbothered by lockouts or throttling. The enumeration bug turns a blind spray into a targeted attack, and the missing rate limit removes the one control that would normally make online guessing impractical.

An account on a Yamcs server can command a spacecraft. That makes credential access here access to the mission itself.

Why the ground segment is the prize

Space systems get discussed as if the risk lives in orbit, but the commanding authority lives on the ground. A Yamcs operator account can issue commands, acknowledge alarms, and drive mission timelines. An attacker who reaches that console does not need to defeat the spacecraft's own protections, because they are speaking with the voice that the spacecraft already trusts. The ground segment is the soft underbelly precisely because it looks like ordinary IT, and ordinary IT is where credential attacks already thrive.

How serious is this, honestly

We want to be precise. Both flaws are rated Medium, CVSS 4.3 and 6.5. Neither appears in CISA's Known Exploited Vulnerabilities catalog, and we have found no evidence of exploitation in the wild. One of the two requires a valid low-privilege account to start, and the other still requires guessing a real password, which strong credentials and short lockouts would defeat. The fix has been available since late May. This is not a five-alarm, patch-tonight remote-code-execution event, and we will not dress it up as one.

What earns it a place on our watch is the combination of a genuine space-sector control system and fresh public proof-of-concept code for both bugs, published to the community exploit collections. That is the scenario where a proof-of-concept can matter on its own merits, well before anything reaches a catalog of exploited vulnerabilities.

What our sensors see

We run a fleet of honeypots, so we checked our own data. We do not emulate a Yamcs server or a CCSDS ground station, so we did not capture this specific chain, and we will not claim otherwise. An actor hunting Yamcs would not find the right surface on our generic decoys.

What we do see, continuously, is the precondition the second bug depends on. Un-throttled credential brute-forcing is the single most common behavior against every login service we expose. Attackers assume there is no rate limit and no lockout, and they act accordingly, hammering SSH, web, and API logins at machine speed. CVE-2026-44596 is not an exotic technique, it is the everyday behavior of the internet meeting a server that forgot to say no.

What to do

Reference