Wildcard rule flaw lets Ankaios workloads read full cluster state
An advisory published on 7 September 2026 says Eclipse Ankaios wrongly authorises empty field masks when an allow rule starts with a wildcard.
By The Agentic Times ·
A security advisory published on 7 September 2026 describes an authorisation bypass in Eclipse Ankaios that lets an authenticated workload read or overwrite cluster state it should not be able to touch. The advisory, tracked as GHSA-287g-w4gp-cqxr and CVE-2026-84173, says versions v0.5.1 through v1.0.1 are affected.
The problem sits in the agent-side Control Interface authoriser, the component that decides whether a workload's request to the cluster is permitted. According to the advisory, the authoriser incorrectly evaluates multi-segment allow rules whose first path segment is a wildcard. A rule such as *.workloads.some_workload is meant to scope a workload's access to one small part of the cluster state. Instead, the flawed check can treat a request with no scope at all as a match for that narrow rule.
In practice, the advisory says, an authenticated workload whose access is restricted by such a rule can send a CompleteStateRequest or an UpdateStateRequest with an empty field mask. A field mask is the list of state paths a request applies to. Because the empty mask is incorrectly matched against the scoped rule, the request may be authorised, allowing the workload to read the complete cluster state or to replace state outside its authorised subtree.
The advisory states that only a rule consisting solely of * is intended to authorise an empty mask. That single-asterisk mask has "different, intentionally unrestricted semantics" and should be used only when full-state access is genuinely wanted, according to the advisory.
The consequences described are unauthorised disclosure or modification of other workloads and of cluster configuration. In other words, one workload that was supposed to see only its own slice of the system could inspect everything the cluster knows, or push a state update that reaches beyond its own subtree. The advisory does not report any known exploitation.
For operators who cannot yet move to a fixed release, the advisory sets out a configuration workaround. Until an update containing the fix is installed, it says, administrators should avoid Control Interface allow-rule filter masks that have several segments and begin with a wildcard, giving *.workloads.some_workload as the example to steer clear of. Those rules should be replaced with explicit paths, such as desiredState.workloads.some_workload, where that substitution is possible.
The practical lesson for anyone running agent-style workloads behind a policy engine is that the safety of a deployment can depend on how a single character is parsed. A leading wildcard reads as a convenience in a rule file, but here it changed the meaning of the rule from "this subtree only" to something closer to "anything". Reviewing existing rule sets for leading wildcards is the fastest way to work out whether a given cluster is exposed, since the workaround and the audit are the same task.
The advisory is published as a GitHub security advisory for Eclipse Ankaios and lists the affected version range as v0.5.1 to v1.0.1 inclusive. It refers to "an update containing the fix" as something operators should install once available, and directs those waiting to the rule-rewriting mitigation in the meantime.
Sources
- github.comhttps://github.com/advisories/GHSA-287g-w4gp-cqxr
