You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Vouch request: security fix for supervisor workload server (PR #4898) #4899
Hi! I'd like to contribute a security fix and be vouched.
What I'd like to work on: PR #4898 fixes an authorization gap in the self-hosted supervisor's workload server (apps/supervisor/src/workloadServer/index.ts): the dequeue route skips authorizeWorkloadRequest entirely, and in enforce mode an absent token header bypasses enforcement. The PR adds the missing guard + rejects absent tokens in enforce mode — 7 lines + a doc-comment correction.
Background: I do independent security audits of OSS AI/workflow infrastructure (recent public work includes security fixes merged or in review across LiteLLM, vLLM, BentoML, LangChain, and Arize Phoenix). This came out of an authorized audit of trigger.dev's new self-host deployment lane.
Status of the PR: all CI checks passed before the vouch bot closed it (check-vouch, require-draft, CodeRabbit review, Devin review). The diff is single-purpose per your contribution guide. Happy to make any changes reviewers want.
There's a second, related hardening finding (MCP/egress) queued behind this one per your one-issue-per-PR rule — I'll send it as its own PR once vouched.
Hi @AUTHENSOR can you clarify who authorized this audit?
We may update the self-hosting docs at some point in the future with instructions on the env vars.
On the issue itself: the self-hosted setup is designed for single-tenant use, with code and users you trust. It is not designed to run untrusted code or untrusted payloads.
I'm a funded independent researcher — my work red-teaming OSS AI evaluation and safety infrastructure is covered by a grant from the Survival and Flourishing Fund. This is OSS code, and I didn't probe or impact live infra. I read the repo, found the supervisor gap, and filed a working fix with a reproducible PoC. That's my "authorization".
I see the single-tenant/trusted-code design point. But the variable exists for users who DO want the boundary — and in enforce mode an absent token header still passes, and the dequeue route skips the check entirely. The switch promises enforcement it doesn't deliver. That's the bug.
Activity
carderne commentedon Sep 7, 2026
Hi @AUTHENSOR can you clarify who authorized this audit?
We may update the self-hosting docs at some point in the future with instructions on the env vars.
On the issue itself: the self-hosted setup is designed for single-tenant use, with code and users you trust. It is not designed to run untrusted code or untrusted payloads.
AUTHENSOR commentedon Sep 7, 2026
I'm a funded independent researcher — my work red-teaming OSS AI evaluation and safety infrastructure is covered by a grant from the Survival and Flourishing Fund. This is OSS code, and I didn't probe or impact live infra. I read the repo, found the supervisor gap, and filed a working fix with a reproducible PoC. That's my "authorization".
I see the single-tenant/trusted-code design point. But the variable exists for users who DO want the boundary — and in enforce mode an absent token header still passes, and the dequeue route skips the check entirely. The switch promises enforcement it doesn't deliver. That's the bug.