[security] GitHub OAuth can bind signed user tokens to an unverified public email

[coygeek]

Summary

Crabbox documents GitHub browser login as a supported coordinator authentication boundary: signed cbxu_ user tokens carry the caller's owner, org, and GitHub login, and normal user tokens are scoped to their own owner/org resources. That boundary depends on the owner claim being anchored to a verified GitHub identity.

At commit 0ec69d6427646c7bddffbac2c33576f211c203b1, githubIdentity in worker/src/oauth.ts prefers verified email addresses from /user/emails, but it initializes owner from user.email returned by /user and keeps that value whenever /user/emails returns no verified address. GitHub documents /user.email as the publicly visible profile email, while /user/emails is the endpoint that reports verified state. As a result, a successful GitHub OAuth login can produce a signed Crabbox user token whose trusted owner is a public profile value rather than a verified email.

This is in scope under Crabbox's security policy because it affects coordinator authentication, owner scoping, and optional admin-owner promotion for the supported trusted-team model. It does not depend on hostile tenants sharing one broker or on a trusted operator attacking their own leased machine.

Affected Components

• worker/src/oauth.ts:197-201: the OAuth authorization URL requests read:user user:email read:org.
• worker/src/oauth.ts:231-251: the callback exchanges the GitHub code, resolves identity.owner, checks allowed org/team membership by identity.login, and signs a Crabbox user token.
• worker/src/oauth.ts:428-456: githubIdentity starts with owner = user.email || "", overwrites it only if /user/emails contains a verified address, and otherwise keeps the public email fallback.
• worker/src/auth.ts:166-192: issueUserToken signs the selected owner into the cbxu_ token payload.
• worker/src/auth.ts:90-101: authenticateRequest trusts the signed payload's owner, org, and login for GitHub-authenticated requests.
• worker/src/auth.ts:107-117: githubUserIsAdmin promotes a signed user token to admin if payload.owner matches CRABBOX_GITHUB_ADMIN_OWNERS or payload.login matches CRABBOX_GITHUB_ADMIN_LOGINS.
• worker/src/http.ts:29 and worker/src/fleet.ts: coordinator handlers use the trusted x-crabbox-owner/x-crabbox-org request context for lease, run, usage, bridge, portal, and sharing authorization decisions.

Attack Path

Attacker role: a GitHub user who passes the deployment's configured GitHub org/team allowlist and can complete crabbox login --url <broker-url>.

Prerequisites:

• GitHub browser login is enabled.
• The attacker is an active member of an allowed org/team.
• The GitHub API response for /user/emails contains no verified email for the attacker, while /user.email contains a public profile email value.
• For admin impact, the deployment also grants admin by CRABBOX_GITHUB_ADMIN_OWNERS and that owner list contains the public-email value selected by the attacker. CRABBOX_GITHUB_ADMIN_LOGINS is not affected by this email fallback because it compares the GitHub login, not owner.

Steps:

1. The attacker configures their GitHub public profile email to the owner value they want Crabbox to trust.
2. The attacker completes the normal GitHub OAuth flow through crabbox login --url <broker-url>.
3. githubAuthCallback calls githubIdentity(accessToken).
4. githubIdentity reads /user, sets owner from user.email, then calls /user/emails.
5. If /user/emails has no verified: true entry, githubIdentity keeps the public profile email instead of failing closed or falling back to a non-email login-derived identity.
6. issueUserToken signs that value into the cbxu_ token as payload.owner.
7. Later requests authenticate as auth: "github" with owner: payload.owner; requestWithAuthContext injects it as x-crabbox-owner.
8. Fleet, portal, usage, run, bridge, and sharing handlers use the trusted owner/org context for visibility and management checks. If the forged owner matches a real owner in the same org, the attacker can be treated as that owner. If the forged owner also matches CRABBOX_GITHUB_ADMIN_OWNERS, the same signed user token receives admin scope.

The closest missing control is in worker/src/oauth.ts:445-456: Crabbox does not require the owner email to come from a verified /user/emails entry before signing it into a long-lived user token.

Impact

The supported coordinator identity boundary can bind a Crabbox user token to an unverified GitHub public profile email. That breaks the documented expectation in docs/security.md and docs/features/auth-admin.md that GitHub user tokens are trusted owner/org credentials for the authenticated GitHub user.

Practical outcomes include:

• Cross-owner impersonation inside the same allowed org if an attacker can make Crabbox sign an owner value that matches another user's Crabbox owner identity.
• Unauthorized visibility or management of owner-scoped leases, runs, logs, usage, portal state, bridge attachments, and sharing state where handlers compare the trusted owner/org context.
• Optional admin escalation when a deployment uses CRABBOX_GITHUB_ADMIN_OWNERS and the selected public email matches an admin-owner value.
• Audit and attribution confusion because repeated logins can produce different owner identities for the same GitHub login when the public email fallback changes.

The issue is bounded by the GitHub org/team allowlist: the attacker must still be accepted by the configured GitHub membership checks. It is nevertheless a reportable Crabbox boundary issue because the flawed value is persisted in a signed coordinator credential and consumed by authorization code.

Severity Assessment

CVSS Assessment

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

The primary score models cross-owner confidentiality impact plus limited integrity and availability impact from owner-scoped management operations. Deployments that use CRABBOX_GITHUB_ADMIN_OWNERS with collidable owner values can have higher integrity and availability impact, but the base score avoids assuming that optional configuration.

Recommended Remediation

Require the signed owner to come from a verified GitHub email source, or use a non-email stable GitHub identity when no verified email is available.

Suggested changes:

1. In githubIdentity, do not initialize or preserve owner from /user.email.
2. Select owner only from /user/emails entries with verified: true, preferring the primary verified email.
3. If no verified email exists, either reject the OAuth callback with GitHubAuthorizationError or deliberately use a stable login/id-derived owner such as <login>@users.noreply.github.com with documentation that it is not an email-verified owner.
4. Keep admin-owner grants tied only to verified owner values. Continue using CRABBOX_GITHUB_ADMIN_LOGINS for login-based grants where that is the intended deployment policy.
5. Add regression tests covering the no-verified-email case and the admin-owner promotion case.

Validation

Validation method: static source review against the isolated verification checkout plus official GitHub REST API documentation.

Evidence:

• worker/src/oauth.ts:197-201 requests read:user user:email read:org, so Crabbox has the API scope needed to query verified email state.
• worker/src/oauth.ts:439-456 fetches /user, sets owner to user.email, then only overwrites it when /user/emails contains a verified primary or verified secondary email.
• worker/src/oauth.ts:231-251 passes identity.owner directly into issueUserToken.
• worker/src/auth.ts:166-192 signs input.owner into the cbxu_ token payload without recording whether it came from a verified GitHub email.
• worker/src/auth.ts:90-101 trusts the signed owner for every GitHub-token request.
• worker/src/auth.ts:107-117 checks that same signed owner against CRABBOX_GITHUB_ADMIN_OWNERS.
• docs/security.md describes signed user tokens as carrying owner, org, and GitHub login, and says admin scope can come from a signed GitHub user token whose verified email or login matches the configured admin lists.
• docs/features/auth-admin.md documents that GitHub user tokens get their trusted owner/org/login from the signed token and that normal user tokens are scoped to their own resources.
• GitHub's /user documentation identifies email as the publicly visible profile email, while /user/emails is the endpoint that returns email entries with a verified field.

Counterevidence and limits:

• GitHub org/team membership is still checked by login before the token is issued.
• CRABBOX_GITHUB_ADMIN_LOGINS is not affected by the email fallback because it compares the signed login.
• Admin escalation through CRABBOX_GITHUB_ADMIN_OWNERS depends on deployment configuration. The owner-identity binding bug and cross-owner authorization risk do not require that optional admin list.
• Runtime reproduction was not attempted because the issue is fully visible in the OAuth/auth source path and no source edits or external GitHub test account should be created for verification.

Suggested regression tests:

• Mock /user to return { "login": "attacker", "email": "victim@example.test" } and /user/emails to return only unverified entries or an empty list. The OAuth callback should fail closed, or should issue a token with the documented non-email fallback rather than victim@example.test.
• Mock a token issued from the no-verified-email path and assert that authenticateRequest does not promote it through CRABBOX_GITHUB_ADMIN_OWNERS.

[clawsweeper]

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

Summary
Keep open: current main and the latest release still initialize the GitHub token owner from the public profile email before looking for verified emails, then trust the signed owner for normal scoping and optional admin-owner promotion.

Reproducibility: yes. source-reproducible. Current main initializes the GitHub owner from the public profile email, only replaces it with verified /user/emails data, signs it, and later trusts it for owner/admin decisions.

Next step
Security-sensitive OAuth owner binding needs maintainer review before choosing fail-closed versus stable-fallback behavior and rollout handling.

Security
Needs attention: The issue describes a concrete GitHub OAuth identity-binding weakness in the coordinator auth path.

Review details

Best possible solution:

Bind owner only to a verified GitHub email or a documented stable non-email fallback, then add no-verified-email and admin-owner regression tests.

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

Yes, source-reproducible. Current main initializes the GitHub owner from the public profile email, only replaces it with verified /user/emails data, signs it, and later trusts it for owner/admin decisions.

Is this the best way to solve the issue?

Unclear until maintainers choose the compatibility policy. The narrow maintainable fix is to remove the public-email fallback and either require a verified email or use a documented stable login-derived fallback.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A fix may change owner identity for users whose GitHub API response has no verified email, so maintainers should choose between fail-closed behavior and a documented stable non-email fallback.
• The latest release contains the same fallback, so existing deployments may already have long-lived user tokens minted under the old owner-binding behavior.
• No live GitHub OAuth account reproduction was run; the source path is clear enough to keep open, but maintainer security review should decide disclosure and rollout handling.

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

Label changes

Label changes:

• add P0: The issue reports a current coordinator auth and authorization bypass where a signed GitHub token can carry an unverified owner with cross-owner and admin-owner consequences.
• add impact:security: The affected behavior concerns trusted identity binding, signed credentials, owner-scoped authorization, and optional admin promotion.
• add impact:auth-provider: The affected flow is GitHub OAuth identity resolution and the signed user-token auth path.
• 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:

• P0: The issue reports a current coordinator auth and authorization bypass where a signed GitHub token can carry an unverified owner with cross-owner and admin-owner consequences.
• impact:security: The affected behavior concerns trusted identity binding, signed credentials, owner-scoped authorization, and optional admin promotion.
• impact:auth-provider: The affected flow is GitHub OAuth identity resolution and the signed user-token auth path.

Evidence reviewed

Security concerns:

• [high] Verify GitHub owner identity before signing tokens — worker/src/oauth.ts:445
githubIdentity can preserve a public profile email as owner when no verified email is returned, and that owner is later trusted for resource scoping and admin-owner checks.
  Confidence: 0.9

What I checked:

• Current OAuth owner selection keeps public email fallback: githubIdentity initializes owner from user.email, only overwrites it when /user/emails returns a verified address, and otherwise keeps that fallback before using the noreply identity only when owner is empty. (worker/src/oauth.ts:445, 184979d683b7)
• OAuth callback signs selected owner into user token: The callback passes identity.owner into issueUserToken and stores that same owner in the completed login response. (worker/src/oauth.ts:242, 184979d683b7)
• Signed owner is trusted for auth and admin-owner checks: authenticateRequest returns the signed token payload owner, while githubUserIsAdmin compares that owner against CRABBOX_GITHUB_ADMIN_OWNERS. (worker/src/auth.ts:90, 184979d683b7)
• Repository security policy treats coordinator ownership as a product boundary: The root security policy says coordinator authentication, ownership, and sharing controls remain product boundaries, including access to another owner's resources contrary to documented authorization. (SECURITY.md:22, 184979d683b7)
• Docs describe signed user tokens as owner-scoped and admin-owner capable: Operational docs describe signed user tokens carrying owner/org/login and admin scope from configured verified emails or logins, so the selected owner value is security-relevant. (docs/security.md:67, 184979d683b7)
• Existing tests cover verified-email happy path only: The GitHub OAuth tests mint tokens when /user/emails returns a verified primary email; no no-verified-email rejection or stable fallback regression is present in the inspected area. (worker/test/fleet.test.ts:17649, 184979d683b7)

Likely related people:

• Peter Steinberger: Git history shows the GitHub browser-login implementation introduced worker/src/oauth.ts and the owner-selection path, then later OAuth hardening touched the same file. (role: introduced behavior and recent OAuth area contributor; confidence: high; commits: ce6b96065a90, 3af7656579c9; files: worker/src/oauth.ts, worker/src/auth.ts, worker/test/fleet.test.ts)
• Vincent Koc: History shows adjacent signed-token auth work added GitHub admin-owner promotion, which is one of the affected consequences of trusting the selected owner. (role: adjacent auth contributor; confidence: medium; commits: 3d84a15258bf; files: worker/src/auth.ts, worker/test/http.test.ts, docs/security.md)

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.