How a Pre-Launch QC Pass Found Four Critical Vulnerabilities in One Day

Outcome: 4 critical vulnerabilities found and fixed; launch unblocked within 24 hours
When: 2026-03-29
Source: Issue thread BRO-439, child issues BRO-442 through BRO-452

Context

Argus is a media catalog and asset management service built by Brookfield Digital. By late March 2026, the product was functional: users could upload images, get AI-generated metadata, search their library, and access assets via MCP tools. The founder was preparing to launch publicly.

Before flipping the switch, a comprehensive QC evaluation was commissioned — not a manual checklist, but a systematic agent-led review covering code quality, UI/UX, and the agent integration surface.

The Problem

The opening QC report was unambiguous:

“Verdict: NOT READY FOR LAUNCH — 2 critical security/data integrity issues must be resolved before any public exposure.”

The agent had found four critical vulnerabilities that would have reached production:

SSRF vulnerability in upload-from-url — No URL validation on the upload-by-URL endpoint. An attacker could supply an internal network address and use Argus as a proxy to reach infrastructure that should never be exposed. Filed as BRO-448 (CRITICAL).
Broken tenant isolation — The companyId context was never set in the asset analysis pipeline. In a multi-tenant system, this meant an asset uploaded by one workspace could be analyzed against data from another. Filed as BRO-446 (CRITICAL).
Missing Stripe webhook signature verification — Webhook events were accepted without verifying the Stripe signature, making it trivially easy to fake payment events. Filed as BRO-447 (CRITICAL).
Legacy API_KEY environment variable synthesizing a fake enterprise company — A backdoor left over from development: a certain environment variable would create a fake enterprise tenant and bypass all access controls. Filed as BRO-449 (CRITICAL).

In addition, the audit found three HIGH-severity issues and two MEDIUM issues. The HIGH findings: a credit-deduction race condition allowing negative balances (BRO-442), a brute-force vulnerability in the magic link flow with no rate limiting on 6-digit codes (BRO-443), and missing content-type/magic-byte validation on file uploads (BRO-450). The MEDIUM findings: an authentication middleware bug leaking favicon.ico 401s (BRO-444) and a documentation error in the MCP package name (BRO-445).

What Was Done

The QC report decomposed each finding into a separate tracked issue with severity classification and a clear fix description. Eleven child issues were created (BRO-442 through BRO-452). The Founding Engineer was assigned the security fixes; the CEO coordinated and performed independent verification on each.

All nine security issues were resolved in a single day. Three separate commits (4ab26e5, 7d41f56, a48f74a) addressed the fixes in batches. The CEO ran independent QC verification against each fix before closing the subtask.

The closing comment on BRO-439:

“All 9 subtasks completed and independently QC verified by CEO.”

One additional item emerged mid-thread: the founder asked whether an agent could invite them to an Argus workspace. Investigation showed it was architecturally blocked — the invite endpoint required session auth, not API key auth. This was filed as a separate gap (BRO-453) rather than treated as a launch blocker.

Verifiable Outcome

Metric	Value	Source
Critical vulnerabilities found	4	BRO-446, 447, 448, 449 — each titled CRITICAL severity in the audit (tracker priority field: high)
High-severity issues found	3	BRO-442 (credit race condition), BRO-443 (brute force), BRO-450 (file content-type validation)
Medium issues found	2	BRO-444 (favicon 401), BRO-445 (MCP docs)
Total security subtasks	9	BRO-442 through BRO-451
All fixed and QC verified	Yes	Closing comment on BRO-439, commits cited
Time from audit to all-clear	~1 day	BRO-439 created and closed 2026-03-29
Independent QC verification	CEO	Closing comment: “independently QC verified by CEO”

Why This Story Matters

Four critical vulnerabilities — SSRF, broken tenant isolation, missing payment signature verification, an active backdoor — would have been live in a public product if this pass hadn’t run. None of them required a specialist security audit or a dedicated security team. A single agent, given access to the codebase and a clear mandate (“is this launch-ready?”), found all of them in a few hours.

The pattern — comprehensive audit as a decomposed set of tracked issues, each independently verified before close — is repeatable and applicable to any code review moment in a development cycle.