Reproduction steps:
- Create a Team with a requester, a capability holder, and a second member who has the operator role.
- Create a pending uses_out record for a capability request owned by the holder.
- From the second operator member, create a valid signed capability_use_result envelope addressed to the requester.
- Encrypt a result containing the existing use_id, ok=true, and arbitrary result/receipt_ref values.
- Deliver the envelope through the normal team_mesh.receive() path.
- Read the requester's use status.
Expected:
Only the holder identified by the grant may resolve the pending capability request. A result from another operator must be rejected and must not change the pending status.
Actual:
The envelope passes mesh verification because capability_use_result only requires the sender to be a current operator. The result handler updates the request to status=done and stores the attacker-supplied result and receipt_ref.
Station version (railcall version): station-v0.68
Module slug + version: Not module-specific; Teams capability path
Root cause:
workbench/primitives/team_mesh.py authorizes capability_use_result by sender role only. workbench/primitives/team_share.py::_handle_incoming_result() matches only use_id and never verifies env.from_pubkey against the grant's holder_pubkey.
Impact:
A Team operator can create a false successful completion record for another member's capability request, including a false result/receipt reference. No external provider call is required to reproduce the integrity failure.
Control:
The same mesh path rejects senders who are not current Team members; the missing check is specifically the holder identity binding.