T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:60- Finding
Unscoped Bulk Approval of Pending Peer Handshakes
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 60–65
Vulnerability Type: Unscoped trust approval that violates least privilege
Risk Level: HighComplete Code Snippet:
bash # Approve all pending handshakes PENDING=$(pilotctl --json pending | jq -r '.[].node_id') for peer in $PENDING; do pilotctl --json approve "$peer" & done waitTechnical Analysis
The mesh deployment workflow approves every handshake returned by
pilotctl --json pending. It does not correlate those requests with the peers inALL_PEERS, the intended swarm, or the handshakes initiated by the current workflow.Consequently, pre-existing or concurrently submitted requests can be approved even when they are unrelated to the requested topology. The parallel approval loop also removes an opportunity for identity review before trust is granted. This violates least-privilege and fail-closed access-control principles.
Attack Path
- An attacker submits a peer handshake before or during mesh deployment.
- The attacker's request appears in the daemon's pending-handshake collection.
- The skill executes
pilotctl --json pendingand extracts every pending node ID. - The loop invokes
pilotctl --json approvefor the attacker's node ID without validating its address, swarm membership, expected identity, or cryptographic fingerprint. - The attacker becomes an approved peer in the trusted communication environment.
Impact Assessment
A successful attacker can obtain unauthorized trusted-peer access. Depending on the permissions and semantics provided by
pilotctl, this may allow participation in swarm communications and access to topology or task information available to trusted peers. It may also provide a foothold for attacks against other connected nodes.The direct scope is the daemon and swarm environment in which the workflow runs. The available project evidence does not establish operating-sys ...[truncated 79 chars]
- Remediation
View remediation
Remediation Suggestions
- Record the exact peer identities associated with handshakes initiated by the current deployment.
- Approve only requests that can be correlated with the intended
ALL_PEERSset and selected swarm. - Validate immutable identity attributes, including node ID and cryptographic fingerprint; do not rely solely on mutable hostnames or addresses.
- Reject or leave untouched unsolicited, ambiguous, pre-existing, and unrelated pending requests.
- Avoid parallel bulk approval where it prevents identity review or reliable error handling.
- Require explicit operator confirmation for any request that cannot be cryptographically matched to an expected peer.
- Re-query each candidate immediately before approval and fail closed if its identity or membership has changed.
- Log each initiated handshake, verification result, approval decision, and failure for auditability.