[security] Artifact broker keys omit org from upload namespace

[coygeek]

[security] Artifact broker keys omit org from upload namespace

Summary

Brokered artifact uploads are authorized with Crabbox's normal authenticated coordinator identity, which includes both owner and org, but the signed storage namespace includes only the owner and caller-selected artifact prefix. As a result, the same owner identity operating in two Crabbox org scopes can request upload grants for the same prefix and artifact name and receive signed PUT/read URLs for the same object key.

This crosses the supported Crabbox boundary for authenticated coordinator resource isolation. SECURITY.md treats access to another owner's resources contrary to documented authorization as in scope, and docs/security.md documents owner/org scoping for coordinator data and signed user tokens. The issue does not depend on hostile arbitrary tenants sharing one broker; it depends on a legitimate authenticated identity in one org colliding with artifacts expected to belong to another org.

Affected Components

• Checked commit: 6dba4afd1c5a4be0a780cf035d1b397e8982d478
• Component: coordinator artifact broker
• Affected files:
  • worker/src/fleet.ts
  • worker/src/artifacts.ts
  • internal/cli/artifacts_publish.go
  • internal/cli/coordinator.go
  • worker/test/fleet.test.ts

Attack Path

Attacker role:

Authenticated user token or shared/operator token for an owner identity that can operate in a different Crabbox org scope.

Prerequisites:

• The coordinator artifact broker is configured with CRABBOX_ARTIFACTS_BACKEND, bucket credentials, and either signed read URLs or CRABBOX_ARTIFACTS_BASE_URL.
• The same owner identity can authenticate or be attributed in two org scopes that the deployment treats as separate Crabbox authorization scopes.
• A victim org publishes artifacts at a reusable or observable broker prefix, or the attacker can predict the victim's artifact prefix and file name.

Steps:

1. In org A, a victim publishes artifacts through the broker. The CLI sends POST /v1/artifacts/uploads with a prefix and file list, then uploads bytes through the returned signed PUT URLs.
2. In org B, the attacker authenticates as the same owner identity and sends the same POST /v1/artifacts/uploads request with the same prefix and file name.
3. createArtifactUploads calls artifactUploadResponse(this.env, input, requestOwner(request)), so the org from the authenticated request is not part of the signing context.
4. artifactUploadResponse computes the storage prefix as artifactPrefix(config.prefix, owner, request.prefix), and artifactPrefix joins only the configured prefix, owner, and caller prefix.
5. The returned upload grant targets the same object key for org A and org B. Uploading attacker-controlled bytes through the grant overwrites or spoofs the artifact bytes and read URL expected by the victim org.

Control/data flow:

authenticated request in org B
  -> createArtifactUploads authenticates normally but passes requestOwner only
  -> artifactUploadResponse builds configPrefix/owner/requestPrefix
  -> artifactObjectKey appends attacker-selected artifact name
  -> signed PUT and read URL collide with org A for the same owner/prefix/name

Impact

This is a cross-org artifact integrity issue with limited confidentiality impact in deployments that use the coordinator artifact broker. A user valid in one org can collide with artifacts generated for another org that shares the same owner identity because org is ignored in the signed object namespace, even though other coordinator resources and user tokens carry owner/org identity.

The practical outcome is that an attacker can replace or pre-create artifacts that another org expects to be isolated under its own Crabbox scope, such as screenshots, logs, manifests, or PR evidence published by brokered artifact workflows. If artifact URLs or manifests are shared across workflows, the same namespace collision can also expose one org's artifact URL/key material to another org for identical owner/prefix/name tuples.

Severity Assessment

CVSS Assessment

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

The issue requires an authenticated Crabbox credential and a deployment that treats organizations as separate scopes, so it is not an unauthenticated or admin-impacting bug. It is still security-relevant because the coordinator signs write/read access to storage objects and the missing org segment enables cross-scope artifact spoofing or overwrite.

Recommended Remediation

Include the request organization in the brokered artifact namespace and make that tuple part of the server-side signing contract. A minimal fix is to pass both requestOwner(request) and requestOrg(request, this.env) from createArtifactUploads into artifactUploadResponse, then build keys using an unambiguous org+owner namespace such as configPrefix/org/owner/requestPrefix/name.

Normalize the org segment with the same path-part handling used for owner and prefix. Add a compatibility decision for existing owner-only artifact URLs, such as keeping old objects readable until expiry while signing all new grants under a versioned or org-aware prefix.

Validation

Validation method:

Source review against the isolated verification checkout at commit 6dba4afd1c5a4be0a780cf035d1b397e8982d478.

Evidence:

• worker/src/coordinator-entry.ts authenticates non-health, non-agent coordinator routes before fleet handling and writes trusted x-crabbox-owner and x-crabbox-org headers from the auth context.
• worker/src/auth.ts verifies signed user tokens carrying both owner and org, and requestWithAuthContext forwards both values to downstream fleet handlers.
• worker/src/fleet.ts:8879-8884 handles POST /v1/artifacts/uploads, reads the authenticated JSON body, and calls artifactUploadResponse(this.env, input, requestOwner(request)); it does not pass requestOrg(request, this.env).
• worker/src/artifacts.ts:57-68 accepts only owner as identity context and computes prefix = artifactPrefix(config.prefix, owner, request.prefix).
• worker/src/artifacts.ts:191-213 builds the object key prefix from the configured prefix, owner, and caller-supplied request prefix, then appends the normalized file name.
• worker/test/fleet.test.ts:16040-16075 asserts the current brokered key shape as qa/peter@example.com/pr-42/screenshots/after.png, demonstrating the org segment is absent from the signed key and read URL.
• internal/cli/artifacts_publish.go:203-253 shows the CLI sends caller-selected Prefix and file Name values to the broker and trusts the returned Key and URL for publication.
• internal/cli/coordinator.go:1644-1647 sends artifact upload requests to POST /v1/artifacts/uploads.

Counterevidence considered:

• internal/cli/artifacts_publish.go:255-273 generates a timestamped default prefix when the user does not provide one, which reduces accidental collisions. It does not protect direct API clients, scripted publication with stable prefixes, or intentional reuse after an attacker observes a manifest or URL.
• worker/src/artifacts.ts:173-180 rejects traversal in artifact names, so this is not arbitrary key traversal. The issue is that two otherwise valid org-scoped requests are signed into the same owner-only namespace.

Suggested regression coverage:

• Add a worker/test/fleet.test.ts case that sends two authenticated POST /v1/artifacts/uploads requests with the same owner, prefix, and file name but different x-crabbox-org values, and assert the returned prefix, key, upload URL, and read URL differ.
• Add focused worker/src/artifacts.ts unit coverage for the org-aware prefix builder, including path-like org names and empty/default-org behavior.

Verification command:

npm test --prefix worker -- fleet.test.ts

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 25, 2026, 8:59 PM ET / 00:59 UTC.

Summary
Keep open: current main still signs brokered artifact object keys under config prefix, owner, and caller prefix only, while the authenticated coordinator identity and docs treat owner/org as the normal authorization scope.

Reproducibility: yes. A high-confidence source reproduction is to send two authenticated POST /v1/artifacts/uploads requests with the same owner, prefix, and file name but different orgs; current main passes only owner into the key builder, so both requests target the same key.

Next step
This is a valid security-sensitive bug, but the org-aware key format and compatibility behavior for existing artifacts need maintainer/security review before a repair lane should implement it.

Security
Needs attention: The issue raises a concrete authenticated cross-org artifact integrity concern; no patch was available to review.

Review details

Best possible solution:

Add a normalized org segment to newly signed brokered artifact keys, preserve or document the read behavior for existing owner-only URLs through their expected lifetime, and cover same owner/prefix/name across different orgs with Worker tests.

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

Yes. A high-confidence source reproduction is to send two authenticated POST /v1/artifacts/uploads requests with the same owner, prefix, and file name but different orgs; current main passes only owner into the key builder, so both requests target the same key.

Is this the best way to solve the issue?

Yes, the narrow fix is to make the server-side artifact signing namespace include org as part of the authenticated identity. The remaining maintainer decision is the compatibility path for already-published owner-only keys and URLs.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live Worker test was run in this read-only review; the reproduction is source-level, but the code path is direct.
• Changing the object key shape is compatibility-sensitive for existing owner-only artifact keys and read URLs, so maintainers should choose the migration/read-expiry behavior deliberately.

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

Label changes

Label changes:

• add P2: This is a normal-priority security boundary bug with authenticated prerequisites and limited blast radius to deployments using the artifact broker.
• add impact:security: The issue concerns authorization-scope isolation and signed artifact upload/read URLs across owner/org identities.
• 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:fix-shape-clear: 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: This is a normal-priority security boundary bug with authenticated prerequisites and limited blast radius to deployments using the artifact broker.
• impact:security: The issue concerns authorization-scope isolation and signed artifact upload/read URLs across owner/org identities.

Evidence reviewed

Security concerns:

• [medium] Artifact grants omit org from signed storage namespace — worker/src/artifacts.ts:67
  The coordinator signs artifact PUT/read URLs using owner and caller prefix but not org, which can let two org scopes for the same owner collide on the same object key.
  Confidence: 0.91

Acceptance criteria:

• npm test --prefix worker -- fleet.test.ts
• npm run check --prefix worker

What I checked:

• Current upload route drops org before signing: createArtifactUploads reads the authenticated upload request but calls artifactUploadResponse(this.env, input, requestOwner(request)), with no requestOrg passed into the signing path. (worker/src/fleet.ts:8879, 6dba4afd1c5a)
• Object prefix builder is owner-only: artifactUploadResponse accepts only owner, and artifactPrefix joins config prefix, owner, and caller prefix before artifact names are appended. (worker/src/artifacts.ts:57, 6dba4afd1c5a)
• Existing test locks in owner-only key shape: The brokered upload test expects qa/peter@example.com/pr-42/..., demonstrating the current signed key and read URL omit an org segment. (worker/test/fleet.test.ts:16024, 6dba4afd1c5a)
• Auth context carries org: The coordinator authentication layer injects both x-crabbox-owner and x-crabbox-org into downstream requests, so the missing org is specific to the artifact broker path. (worker/src/auth.ts:126, 6dba4afd1c5a)
• Documented scope uses owner/org: The security guide says user tokens mutate leases, runs, and usage for their own owner/org identity, and the root security policy treats cross-owner resource access and artifact integrity failures as in-scope boundaries. (docs/security.md:85, 6dba4afd1c5a)
• Latest release does not contain a fix: The latest release tag inspected still has artifactUploadResponse(env, request, owner) and artifactPrefix(configPrefix, owner, requestPrefix), so the central issue is not fixed in v0.33.0 either. (worker/src/artifacts.ts:57, 966e99599db4)

Likely related people:

• steipete: Commit b568298 introduced brokered artifact publishing across the CLI, Worker artifact signer, fleet route, tests, and docs, making this the strongest feature-history signal for the affected path. (role: feature owner; confidence: high; commits: b56829801970, 966e99599db4; files: worker/src/artifacts.ts, worker/src/fleet.ts, worker/test/fleet.test.ts)
• coygeek: Current-line blame in this checkout attributes the artifact broker signer, route, and security policy lines to ae54e7a, and the same person supplied the detailed source-level report. (role: recent area contributor; confidence: medium; commits: ae54e7ae9577; files: worker/src/artifacts.ts, 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.

[steipete]

Consolidating #758 into this canonical tracker.

Current main confirms two distinct manifestations of the same brokered artifact key-contract defect:

1. authenticated org is omitted, so the same owner/prefix/name collides across orgs;
2. authenticated owner and caller prefix are normalized as interchangeable path segments, so owner=alice/team,prefix=run-1 collides with owner=alice,prefix=team/run-1.

Decision: new brokered grants will use an opaque v2 namespace:

<configured-root>/v2/org/<base64url(utf8(org))>/owner/<base64url(utf8(owner))>/<normalized-request-prefix>/<artifact-name>

This is a new-write-only change. The CLI already treats returned keys and URLs as opaque. Existing public URLs continue addressing their existing objects, and existing presigned read URLs continue until their configured expiry; no dual-write or legacy lookup path is needed.

Acceptance must cover both cross-org and identity/prefix collisions, including slash, backslash, and Unicode identity values. One security review and implementation here will close both reports.