Soju06/codex-lb - security scan

Repository: Soju06/codex-lb Commit scanned: f212300dbe60492accdb09115a6a64ba87646c86 Scan date: 2026-07-01 Disclosure status: public — post-only (clean scan; no upstream issue filed)

Summary

Severity Count
Critical 0
High 47
Medium 29
Low 0 (filtered at --min-severity medium)
Info 0

Total findings: 76 (0 real after curation)

codex-lb is a load balancer and proxy for ChatGPT/Codex accounts: pool multiple accounts, store their OAuth tokens, expose an OpenAI-compatible endpoint, and manage it all from a web dashboard with usage tracking. That makes it the most credential-dense target in the series so far — the whole product is “hold other people’s LLM account tokens and broker requests through them.”

This is the 11th clean scan, and the most instructive kind: the finding that would actually matter for a credential proxy is one a static scanner never raises, and the maintainer had already engineered it correctly. Semgrep’s 47 “high” findings are, on inspection, database migrations and Markdown.

Top findings

1. The finding that matters — localhost auth-bypass — is correctly defended

2. The 47 “high” findings are database migrations and Markdown

3. The one live-code SQL area is parameterized

4. Credential logging and crypto are careful / protocol-mandated

Patterns observed

For a credential proxy, the real risk surface is the one semgrep can’t see. The whole security question for codex-lb is “can someone who isn’t you reach the dashboard or the pooled tokens?” — and that reduces to how it decides a request is “local,” how it stores account tokens, and whether the proxy is an open relay. None of those are AST-pattern findings; a rule engine has nothing to say about them. This is the same lesson the zotero-mcp completeness sweep taught: for a given project class, you have to manually walk the class-specific surface, because the scanner’s high-severity list is orthogonal to it. Here the walk turned up a maintainer who built a dedicated request_locality module, a CIDR-gated trusted-proxy model, header sanitization, and a firewall IP-resolution test — the exact controls the threat needs.

The count is migrations again. 47 highs sounds alarming on a token broker; ~30 are Alembic DDL and the rest are Markdown and parameterized analytics SQL. Auto-flagging alembic/versions/** (developer-authored, deploy-time, no request input) as candidate-FP would have collapsed the high bucket to near-zero — the same “migrations aren’t request paths” point that keeps recurring.

Spec-driven engineering shows in the security posture. codex-lb is built with an openspec/ spec directory, DECISIONS.md, and AGENTS.md/CLAUDE.md — and the security-relevant behavior (forwarded-header sanitization, trusted- proxy CIDRs, auth modes) is each backed by a written spec. The discipline that usually produces good docs here also produced the correct locality handling. Dashboard auth is password + optional TOTP, tokens are encrypted at rest, and dependencies are current under Renovate (trivy found nothing).

Notes on the tool

Disclosure timeline

This is a post-only clean-scan write-up. The credential-proxy risk that matters (localhost auth-bypass via spoofed locality) is correctly engineered behind a trusted-proxy CIDR model, the SQL that runs on requests is parameterized, the credential logging is correlation-id-only, and the flagged SHA-1 is protocol-mandated. Nothing cleared the quality gate.

Reproduce

git clone https://github.com/Soju06/codex-lb /tmp/scan-target
python scanner/run_scan.py --repo /tmp/scan-target \
  --reports-dir ./reports/soju06-codex-lb \
  --min-severity medium --ignore-samples