[security] Manage-share run events can reattribute runs into another lease's audit history

[coygeek]

[security] Manage-share run events can reattribute runs into another lease's audit history

Summary

POST /v1/runs/:id/events correctly requires the caller to own the run before appending an event, but it separately accepts an optional leaseID from the event body. If that supplied lease ID differs from the run's current lease, the coordinator only checks whether the caller can manage the target lease. A user with manage share access to another owner's lease can therefore append an event to one of their own runs that changes the run's lease attribution to the shared lease.

This crosses Crabbox's supported trusted-team boundary because the documented run-history model says lease owners receive read-only audit access to work on their leases, while lease shares do not grant access to runs created by other actors. The affected path lets a share recipient create misleading backing-lease attribution and place an unrelated run into the target lease owner's audit/history views.

Affected Components

• worker/src/fleet.ts:10032-10045: The run-event route first checks that the caller can write the run, then accepts input.leaseID; for a different lease ID it performs a raw lease lookup and authorizes the supplied lease with leaseManageableByRequest.
• worker/src/fleet.ts:11740-11743: leaseManageableByRequest treats a manage share recipient the same as the lease owner for this check, so the event route accepts a cross-owner lease ID when the caller has manage-share access.
• worker/src/fleet.ts:11959-11982: Appending the event calls applyRunEventSummary, persists the event, persists the mutated run, and broadcasts the event after the event body has been allowed to change the run summary.
• worker/src/fleet.ts:15495-15506: applyRunEventSummary copies event.leaseID into run.leaseID, turning the event body's lease ID into durable run attribution metadata.
• worker/src/fleet.ts:11829-11840: When the run lease ID changes, setRunLeaseAttribution records the target lease ID and the target lease owner's owner/org identity in run.leaseIDs and run.leaseOwners.
• worker/src/fleet.ts:10151-10180: Run history listing uses run.leaseIDs, ensureRunLeaseAttribution, and runReadableToRequest, so a reattributed run appears in lease-filtered run history for the target lease owner.
• worker/src/fleet.ts:6576-6606: Portal run detail, log, and event routes use runReadableToRequest; once the target lease owner is in the run attribution list, they can read the reattributed run detail, logs, and events as audit data.
• docs/features/history-logs.md:68-73: The documented history contract says backing lease owners get read-only audit access to work on their lease, and explicitly says lease shares do not grant access to runs created by other actors.

Attack Path

Attacker role: authenticated non-admin user who has manage share access on a lease owned by another owner or org.

Prerequisites:

• The attacker has a valid Crabbox user token.
• Another operator has shared a lease with the attacker using the manage role.
• The attacker owns any run record that is writable by their identity.

Steps:

1. The attacker creates or selects one of their own runs.
2. The attacker sends POST /v1/runs/<attacker-run-id>/events with an event body containing leaseID for the other operator's shared lease.
3. The coordinator validates that the attacker owns the run, then validates only that the attacker has manage access to the supplied lease.
4. The event summary updates the run's primary leaseID and records the supplied lease owner's identity in the run's backing-lease attribution.
5. The other lease owner's history, portal, log, event, and live-event audit paths can now show the attacker's unrelated run as work attributed to that lease.

Impact

This is an audit-history integrity issue. A manage-share recipient can cause unrelated runs to appear under another operator's lease history and can make that lease owner receive read-only audit access to run detail, logs, events, telemetry, and live event subscriptions that were not created as work on their lease.

The issue does not grant admin authority, mutate the target lease lifecycle, or allow a user without manage-share access to target the lease. The practical impact is that Crabbox's coordinator-stored run history can no longer be treated as a reliable record of which runs were actually backed by a lease, and lease owners may be shown misleading or attacker-controlled run history under their lease audit surface.

Severity Assessment

CVSS Assessment

Metric	v3.1	v4.0
Score	4.3 / 10.0	5.3 / 10.0
Severity	Medium	Medium
Vector	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N	CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Calculator	CVSS v3.1 Calculator	CVSS v4.0 Calculator

The score is Medium because exploitation requires an authenticated user who already has manage-share access to the target lease, and the effect is limited to coordinator run-history integrity. The attack does not expose Crabbox credentials or provider resources directly, but it does cross the documented audit attribution boundary for lease owners and shared users.

Recommended Remediation Approach

Bind event-supplied lease attribution to the run's existing backing-lease relationship instead of treating manage-share access to an arbitrary lease as sufficient. The event route should only accept a replacement leaseID when it is part of a legitimate run/lease replacement flow or otherwise matches the run's current owner/org and established attribution state. If manage share users need to operate on shared leases, keep that permission scoped to lease management actions and avoid letting it rewrite unrelated run history.

Add regression coverage for a user with manage share access who attempts to append a run event with a different owner's lease ID to their own unrelated run. The expected behavior should be rejection or a non-attributing event that cannot alter run.leaseID, run.leaseIDs, or run.leaseOwners.

Validation

Validation method: source review against current main at cd9ede0bd4611e044d7d60279c8ff35ac9c3db6e.

Confirmed evidence:

• The run-event endpoint allows input.leaseID to name a lease other than the run's current lease when leaseManageableByRequest passes for that lease.
• A manage share recipient satisfies leaseManageableByRequest.
• The accepted event mutates durable run attribution through applyRunEventSummary and setRunLeaseAttribution.
• Run history, portal run pages, logs, events, and live event subscriptions use the resulting attribution to grant read-only audit access to backing lease owners.
• Crabbox's documented history contract says lease owners get audit access to work on their lease and that lease shares do not grant access to runs created by other actors.

Counterevidence and limits:

• Users with only use share access are already blocked from re-tagging unrelated runs into lease-owner audit views.
• The event body is bounded metadata and does not by itself mutate the target lease lifecycle or provider resources.
• The attacker must already be authenticated and have manage-share access on the target lease.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 6, 2026, 11:09 AM ET / 15:09 UTC.

Summary
Keep open: current main still allows the exact manage-share event-attribution path, while the earlier merged fix only tightened use-share re-tagging to require manage access. Prior maintainer discussion suggests manage may have been intended as the accepted boundary, so this needs an explicit security/product decision rather than cleanup closure.

Reproducibility: yes. Source inspection on current main shows an owned run plus a different manage-shared lease can pass the event endpoint guard, store the event lease ID, and add that lease owner to run attribution; I did not run the Worker harness in this read-only review.

Next step
Security-sensitive manage-share attribution semantics need maintainer review before any repair lane changes the recently accepted authorization contract.

Maintainer decision needed

• Question: Should manage-share recipients be allowed to add owner-readable run audit attribution to a shared lease through post-create run events, or should that be limited to the lease owner/admin or a validated replacement flow?
• Rationale: Current docs and VISION.md push against silent retargeting of ownership claims, but the recent related maintainer discussion accepted manage access as the guard, so automation should not choose the permanent authorization contract.
• Likely owner: steipete — They authored the shared-lease audit model and made the related expected-behavior call, so they are the best available owner for the contract decision.
• Options:
  • Block event-only manage reattribution (recommended): Reject or ignore manage-share event lease IDs unless the run already belongs to that lease or a server-validated replacement flow proves the backing lease relationship.
  • Confirm manage-share as trusted: Document that manage-share recipients may create owner-readable audit attribution through run events and close this as accepted behavior after maintainer sign-off.
  • Add a dedicated attach path: Keep ordinary events from expanding attribution and add a narrow API for post-create lease attachment with explicit validation and tests.

Security
Needs attention: Needs attention: the issue is a source-reproducible authorization-boundary report around shared lease run attribution.

Review details

Best possible solution:

Decide and document whether manage-share is trusted for post-create audit attribution; if not, restrict event-supplied lease IDs to existing run attribution or a server-validated replacement flow and add manage-share regression coverage.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection on current main shows an owned run plus a different manage-shared lease can pass the event endpoint guard, store the event lease ID, and add that lease owner to run attribution; I did not run the Worker harness in this read-only review.

Is this the best way to solve the issue?

Unclear. Blocking manage-share event-only attribution is the safer reading of the docs and VISION.md, but the recent related fix intentionally made manage access the guard, so maintainers need to confirm the desired contract before implementation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Prior maintainer discussion treated manage access as the intended post-create attribution boundary, so changing it now would reverse a recently accepted security/product contract unless maintainers explicitly agree.
• Tightening this path could break clients that create an owned run first and later attach a manage-shared lease through run-event metadata.

Codex review notes: model internal, reasoning high; reviewed against cd9ede0bd461.

Label changes

Label changes:

• add P2: The report is a bounded authorization-integrity issue with authenticated manage-share prerequisites and limited audit-history impact.
• add impact:security: The issue concerns a shared-lease authorization boundary and cross-owner run audit attribution.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P2: The report is a bounded authorization-integrity issue with authenticated manage-share prerequisites and limited audit-history impact.
• impact:security: The issue concerns a shared-lease authorization boundary and cross-owner run audit attribution.

Evidence reviewed

Security concerns:

• [medium] Manage-share events can rewrite run audit attribution — worker/src/fleet.ts:10038
  A run owner can submit a different leaseID in event metadata when they have manage access to that lease, and the current summary path persists that lease into owner-readable attribution.
  Confidence: 0.9

What I checked:

• Repository policy read: AGENTS.md was read fully before review; its security/configuration guidance and provider-neutral boundary guidance were applied as review context. (AGENTS.md:1, cd9ede0bd461)
• Current event route permits manage-share lease IDs: The run-event endpoint requires the caller to own the run, then allows a different input lease ID when the referenced lease exists and leaseManageableByRequest passes. (worker/src/fleet.ts:10032, cd9ede0bd461)
• Manage shares satisfy the guard: leaseManageableByRequest returns true for role owner or manage, and leaseAccessRoleForPrincipal returns manage for direct or org manage shares. (worker/src/fleet.ts:11740, cd9ede0bd461)
• Accepted event mutates durable attribution: boundedRunEvent preserves a valid input leaseID, applyRunEventSummary copies it into run.leaseID, and appendRunEventRecord adds attribution for the resulting lease ID. (worker/src/fleet.ts:11965, cd9ede0bd461)
• Documented audit boundary: The history docs say backing lease owners get read-only audit access for work on their lease and that lease shares do not grant access to runs created by other actors. (docs/features/history-logs.md:68, cd9ede0bd461)
• Existing tests cover use-share but not manage-share: The current regression test blocks a use-share user from re-tagging an unrelated run, while the issue's manage-share variant still passes the source guard. (worker/test/fleet.test.ts:21051, cd9ede0bd461)

Likely related people:

• steipete: Authored the shared-lease run audit model in fix: preserve shared-lease run audit trails #397 and later commented on the related expected-behavior boundary in [security] Use-only lease shares can attach forged runs to the lease owner's history #710. (role: feature owner and recent decision participant; confidence: high; commits: 2291401be492, 42552dbcecf5, 68f3d826575c; files: worker/src/fleet.ts, worker/test/fleet.test.ts, docs/features/history-logs.md)
• TurboTheTurtle: Authored the merged run-event lease audit re-tagging fix that changed the event guard to leaseManageableByRequest and added the current use-share regression coverage. (role: recent fix author; confidence: high; commits: e0d13b3af5ea; files: worker/src/fleet.ts, worker/test/fleet.test.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.