Please do not open a public issue for a security vulnerability. A public report tells everyone running this software about the hole at the same moment it tells us.

Report privately through GitHub's private vulnerability reporting: go to the Security tab of this repository → Report a vulnerability. This creates a private advisory visible only to you and the maintainers, and needs no email exchange to get started.

If you cannot use GitHub advisories, email support@databounty.io with SECURITY in the subject line. Please do not include the details in an unencrypted attachment you would not want forwarded.

Please include, as far as you can:

• What the issue is, and which app it affects (apps/api, apps/web, apps/admin, apps/landing).
• Steps to reproduce, or a proof-of-concept request.
• The commit SHA you tested against.
• What an attacker gets out of it (read another user's submissions, escalate to admin, escape the execution sandbox, and so on).

We will acknowledge your report, tell you whether we consider it in scope, and keep you updated as we work on a fix. If we disagree that it is a vulnerability, we will say so and explain why rather than going quiet.

Please give us reasonable time to ship a fix before disclosing publicly. We will credit you in the advisory unless you ask us not to.

This project has not yet cut a tagged release. Only the current main branch is supported — fixes land there, and there are no backports to older commits. If you are running a fork or a pinned commit, you are responsible for pulling fixes forward.

In scope — anything that lets someone:

• Read, modify, or delete data belonging to another user or workspace.
• Gain a role they were not granted (admin, member, support), or act past a role check. Note that the API's requireRole() is the real security boundary; the admin console's client-side redirect is UX only, and reporting that redirect as bypassable is not a finding by itself.
• Escape or abuse the execution sandbox that runs contributed code.
• Forge, replay, or steal session cookies, API keys, or MCP OAuth tokens.
• Cause the validation pipeline to report a check as passed when it did not run, or was skipped, unsupported, or unconfigured. We treat dishonest trust state as a security issue, not a cosmetic one — the whole product rests on those claims being true.
• Read files, environment variables, or network destinations the API should not reach.

Out of scope:

• Missing wallet, payment, escrow, payout, or on-chain functionality. None of it exists in this codebase by design — see Where we draw the line. Its absence is not a bug.
• Findings that require a misconfigured deployment you control, where the fix is your configuration (for example running with a weak SESSION_SECRET, or exposing the API with CORS_ORIGINS set to *).
• Optional integrations behaving as documented when unconfigured. Execution sandboxing, LLM review, and notification channels fail closed and say so rather than silently passing; that is the intended behavior.
• Automated scanner output with no demonstrated impact, missing security headers with no exploit path, or dependency CVEs that are not reachable from this code.
• Social engineering, physical attacks, or denial of service by brute traffic volume.

If you self-host, these are yours to get right, and no upstream fix can cover them:

• Set a strong, unique SESSION_SECRET. Do not reuse the example value.
• Set CORS_ORIGINS to exactly the frontend origins you run — no wildcard.
• Serve every app over HTTPS. Session cookies are not safe over plain HTTP.
• Keep apps/api/.env out of version control. It is gitignored here; keep it that way in your fork.
• Give the database its own credentials, not a superuser shared with anything else.
• Read DEPLOYMENT.md for which integrations fail closed and what has to be true for a real deployment.

Production-only npm audit --omit=dev --package-lock-only against the per-app lockfiles that CI and the Dockerfiles actually install from, re-run 2026-09-09:

Production is clean across all four apps. The four apps/api high-severity rows that stood here previously (mysql2, deepmerge-ts, and their carriers @prisma/config and prisma) were fixed by tested version overrides on 2026-09-09, not accepted as exceptions — see below.

This table is production-only by design (--omit=dev), matching what npm prune --omit=dev actually ships in the Dockerfile's runner stage. vitest/@vitest/mocker are pure devDependencies — never installed in that image — and remain the one open item; see their subsection below.

apps/<app>/package-lock.json is the authoritative source. Both Dockerfile (COPY apps/api/package.json apps/api/package-lock.json ./ then npm ci) and ci.yml (cache-dependency-path: apps/${{ matrix.app }}/package-lock.json, working-directory: apps/<app>) install from it. In the private development workspace these apps are also npm workspaces under a parent package.json, and that parent keeps its own lockfile — npm honours overrides only from the workspace root during a workspace install, so a local node_modules/ can resolve different (older) versions than the shipped lockfile. That divergence was real and observed: qs resolved to the vulnerable 6.15.3 locally while the shipped lockfile already carried the fixed 6.16.0.

Two consequences, both load-bearing:

• Audit the per-app lockfile, in isolation from any workspace root (copy package.json + package-lock.json into an empty directory and run npm audit --package-lock-only there). Auditing a local node_modules/ reports the developer's tree, not the artefact.
• The parent workspace is a private development convenience. It is not exported and never builds a released image.

Declared in apps/api/package.json overrides:

@prisma/config and prisma needed no override of their own: both were reported solely as carriers of the two packages above, and both drop off the report once those resolve to patched versions.

This reverses an earlier recorded decision. The previous revision of this section stated that overriding these transitive versions had been "evaluated and rejected" because it would "mask an advisory in a CLI that never runs in the serving process while risking the config loader." The masking half of that reasoning does not apply — an override to a patched release is an upgrade, not a suppression. The config-loader risk was the real concern, since @prisma/config@7.9.1 pins deepmerge-ts to exactly 7.1.5 and ^8.0.2 is a semver-major jump past that pin. It was tested rather than assumed, in an isolated npm ci install of the shipped lockfile with the overrides applied:

Residual maintenance risk, stated plainly: deepmerge-ts@8 is held past an exact pin by an override. A future Prisma release could depend on 7.x-specific deepmerge-ts behaviour, and the override would then force an untested combination. Re-run the four checks above on every Prisma upgrade, and drop the override entirely once Prisma ships a release whose own dependencies are unaffected.

Not part of the production count above on purpose: vitest is a direct devDependency and @vitest/mocker only exists beneath it, so a --omit=dev audit — matching what npm prune --omit=dev ships in the runner stage — never installs either.

Clearing condition: a dedicated vitest 3 → 5 migration with a full passing test run. Until then this row stays, and it is the only dependency advisory this repository carries.

Three findings from this section's prior revision are now resolved in apps/api/package.json and its lockfile, each verified with a full test run before being applied:

• qs 6.15.3 → ^6.16.0. Added "overrides": { "qs": "^6.16.0" } to apps/api/package.json. It satisfies express@5.2.1's qs@^6.14.0 and body-parser's qs@^6.15.2, so this is a no major-version bump anywhere fix, exactly as previously recorded as available. Verified the override actually takes effect in a standalone install matching how CI installs this app (working-directory: apps/api, no parent-workspace package.json in the published tree) — a plain in-place npm install from this monorepo checkout does not apply it, because the sibling databounty-v1-parity-rebuild workspace root shadows it; that root is dev-only tooling, absent from the published repo.
• nodemailer 9.0.6 → ^9.1.1. Same major version, no code change needed. Fixes four advisories: GHSA-8m3c-c648-2xjj (disableFileAccess/disableUrlAccess bypass via legacy resolveContent() signature), GHSA-wmmp-3585-3rmp (IDN/punycode allow-list bypass), GHSA-2x7j-588g-ccc2 (quadratic-time address parsing DoS), GHSA-cc9r-2j5m-2m83 (recipient-domain validation bypass via RFC 5322 comment mis-parsing).
• vitest 2.1.9 → ^3.2.7. A major-version bump, taken deliberately to close a critical (CVSS 9.8) advisory — GHSA-5xrq-8626-4rwp, arbitrary file read/execution when Vitest's UI server is listening — fixed at 3.2.6. Tested before applying: ran the full suite (npm test, which pins --maxWorkers=1 --minWorkers=1 because these integration tests share one database) against a fresh disposable Postgres database on both the original vitest@2.1.9 and the bumped vitest@3.2.7, from a clean git clone-equivalent standalone copy of apps/api. Same 4 pre-existing failures on both versions (src/pipeline.integration.test.ts, all dependent on an unconfigured execution/LLM provider producing a different pipeline-stage outcome than the test expects — a known, already-documented gap, not something this bump introduced or fixed) — the version bump changed zero test outcomes. @vitest/mocker's own moderate advisory is not fixed by this bump (see the table row above); vitest's own critical advisory is.

Result: the previously-projected "4 High / 0 Moderate" outcome from removing just the qs row did not land exactly as predicted, because two more advisories (the vitest critical one, and @vitest/mocker's moderate one) had been published against this dependency tree since 2026-09-05 and were caught by this same pass. Net: one critical advisory closed, qs and nodemailer fully closed, one moderate (@vitest/mocker) scoped-excepted above. That row now requires vitest 5, not 4: the advisory range was subsequently widened to <= 4.1.10, so npm's only fix is vitest@5.0.0.

Stated plainly, because a dependency claim that overstates its evidence is exactly the kind of dishonest trust state this policy treats as a security issue:

• Reachability above was established from apps/api/package-lock.json and an installed tree. Re-verified 2026-09-09 against the generated export candidate's own per-app lockfiles, each audited in isolation from the development workspace root (package.json + package-lock.json copied into an empty directory, npm audit --package-lock-only): production is 0 across all four apps and the only remaining row is the dev-only vitest one. Re-run this at export time if the lockfiles change again.
• The module-load probes cover the static import graph reachable from the entry points this app actually imports. A dependency that reached one of these packages through a dynamic import on a code path the probe never triggered would not show up. No such path was found by inspection; that is an inspection result, not a proof.
• These packages are still present on disk in the production image, now at patched versions rather than absent. npm prune --omit=dev (Dockerfile, runner stage) does not remove prisma, mysql2, @prisma/config, deepmerge-ts, express, body-parser or qs, because @prisma/client pulls the Prisma CLI in as an optional peer. "Patched" is the claim being made here; "not shipped" is not.
• No exploit was attempted against any of these packages. These are reachability findings.