Verify/rotate credentials exposed in git history and record the outcome

[paccloud]

What to build

Confirm whether the Stack Auth keys and Neon database owner credentials that were previously committed (documented in SECURITY_NOTICE.md) were actually rotated. If not, rotate them now in the Stack Auth and Neon dashboards and update Vercel environment variables. Record the rotation date in SECURITY_NOTICE.md. Optionally scrub the secrets from git history afterwards.

Context: the secrets are still retrievable from git history today. See AUDIT_REPORT.md §3.3 (branch claude/repo-audit-improvement-ozhlau), task 0.4.

Human required: needs access to the Stack Auth dashboard, Neon console, and Vercel project settings.

Acceptance criteria

• The old DATABASE_URL recoverable from git history no longer authenticates
• The old Stack Auth secret server key is revoked
• Production still works after rotation (login, OAuth, sync)
• SECURITY_NOTICE.md records the rotation date

Blocked by

None - can start immediately

[paccloud]

This was generated by AI during triage.

Re-triage: reopened as ready-for-human

This was closed as completed on 2026-06-12, but nothing on main (d6ee642) records that a rotation happened:

• SECURITY_NOTICE.md still says the credentials "MUST be rotated immediately" and gives no rotation or revocation date.
• Neon is still the production database. api/_lib/db.js connects via DATABASE_URL, and the SQL Connect verdict keeps Neon in production. The leaked owner connection string therefore still matters until it is reset.
• History is not scrubbed. Commit a51ef33 (reachable from main) still contains credential-bearing connection strings and Stack Auth keys. Only counts were checked; no values were read or used.
• Stack Auth is gone from the code (Move auth to Firebase #63), but a retired project's secret should still be revoked.
• The current tracked env files contain placeholders only. No new credential-like strings were committed since 2026-06-10.

If you already rotated: just add the dates to SECURITY_NOTICE.md and close this again.

Why this can't go to an agent: rotation needs Neon, Stack Auth, and Vercel dashboard access. An agent must never test a leaked credential to confirm it's dead. Scrubbing history with a force-push is your call.

Agent Brief

Category: bug
Summary: Rotate the leaked Neon DB credential, revoke the retired Stack Auth secret, and record both in the security notice.

Current behavior: Commits reachable from main contain a Neon owner connection string and Stack Auth project and server keys. Neon is still the production database. The security notice records no rotation.

Desired behavior: The leaked Neon credential no longer authenticates, and production uses a new credential set in Vercel. The retired Stack Auth project or secret is revoked, and no STACK_* env vars remain in Vercel. The security notice records the date of each action and whether history was scrubbed or the risk was accepted.

Key interfaces: DATABASE_URL (Vercel production and preview env), the Neon role and password, the Stack Auth project and server key, the security notice document.

Acceptance criteria:

• The owner confirms, via the Neon dashboard or a connection attempt they run themselves, that the old owner credential is rejected
• Production still reads and writes saved calcs after the new DATABASE_URL is set
• The Stack Auth project or secret is revoked, and the STACK_* env vars are removed from Vercel
• The security notice lists the rotation and revocation dates and the decision on scrubbing history

Out of scope:

• Migrating off Neon (the Firebase SQL Connect evaluation)
• Firebase web config keys, which are public by design

---

Generated by Claude Code

[paccloud]

This was generated by AI during triage.

Update: the runbook and scanner are ready. Rotation still needs you.

An agent inventoried every commit on every ref (356 commits, 49 branches, 73 PR refs, 1 tag) in a full mirror, which it deleted afterwards. No credential value was printed, stored or used. Everything below is redacted. The work is on branch claude/repo-audit-improvement-ozhlau (commit b730775). It is not a PR yet.

Correction to my earlier comment. I said commit a51ef33 "contains" the credentials and treated it as the origin. That was misleading. a51ef33 is only the oldest commit visible in a shallow clone. The credentials were introduced in 1eef6e2 (2025-12-16) and removed from main in 0d36e57 (2026-03-28).

What leaked

Service	What	Secret?	Action
Neon Postgres	Connection string with the owner-role password (one distinct value, in both app/.env.development and app/.env.production)	Yes, and Neon is still the production database	Reset the password (step 1)
Stack Auth (retired)	Secret server key	Yes, but unused by the code since #63	Revoke it or delete the project
Stack Auth	Project ID and publishable client key	No, public by design	None
Legacy JWT	Weak hardcoded JWT_SECRET fallback in an old server/server.js (also at the tip of tag v1.0.0)	Weak	Check the value set in Vercel
Firebase	Web config, project ID only	No	None

Exposure: the repository is public. The values were on main for about 3.4 months. They are still at the tip of 8 branches and appear in 12 PR refs. Assume they were copied, which is why step 1.2 (check other Neon branches) and 1.7 (review Neon connection logs) are in the checklist.

What is ready

• SECURITY_NOTICE.md is rewritten as an ordered checklist with blank "done on" cells. It says plainly that no rotation is recorded.
• CI now has a secret scan job. It fails the build if a real-looking credential is committed. It never prints the matched text, and it has tests.
• An owner-only --history mode shows exactly which commits carry hits. Run it on a full mirror, not a shallow clone.

Still yours, and this issue stays open until it's done

1. Reset the Neon owner password, update DATABASE_URL in Vercel (Production, Preview, Development), redeploy, and check the old string is refused from your own machine.
2. Revoke the Stack Auth key.
3. Confirm JWT_SECRET is a real random value.
4. Record the dates and the git-history decision in SECURITY_NOTICE.md. Accepting the risk after rotating is the default, since the old values are then dead.
5. Turn on GitHub secret scanning and push protection in Settings, under Code security.

One thing I could not confirm: commit ee0e0be, 45 minutes before 1eef6e2, also touched the env files. The inventory says it held placeholders only, but this clone can't show it. The --history scan will settle it.

---

Generated by Claude Code