Security hardening: findings from peon-app audit (2026-07-26)

[hironate]

Summary

Static security review of peon-app (control plane). Not a live pentest.

Result: 0 Critical · 3 High · 8 Medium · 5 Low · 2 Info

No confirmed Critical unauthenticated remote RCE. Strongest gaps: auth rate limiting, notification SSRF, and service delete without container teardown.

High (do first)

[ ] H-01 — No rate limiting on login / signup / OTP / forgot-password

• Where: src/app/api/auth/login, signup, resend-otp, forgot-password
• Risk: Password brute-force, 6-digit OTP spray, email flood
• Fix: IP + account rate limits; CAPTCHA after N failures; alert on bursts

[ ] H-02 — Notification webhook SSRF

• Where: src/services/internal/notifications/notifications.ts (postJson)
• Risk: Workspace admin can point Discord/Slack/WEBHOOK URLs at internal/metadata hosts
• Fix: HTTPS-only; block private/link-local/metadata IPs; reject unsafe redirects

[ ] H-03 — Service delete does not stop/remove host containers

• Where: src/services/internal/service/lifecycle.ts remove()
• Risk: Orphaned containers/volumes; public DB ports may stay exposed
• Related: warn: stop service before delete — containers keep running #16 (UI warning only)
• Fix: Teardown on delete (or require stop first), similar to server deleteResources

Medium

• M-01 Git-over-SSH StrictHostKeyChecking=no — deploy/engine.ts (pin known_hosts / prefer GitHub App HTTPS)
• M-02 Host-key TOFU + fail-open on unparseable pin — lib/ssh/host-key.ts
• M-03 Generic deploy webhooks = URL token only — add HMAC + rate limit
• M-04 No CSP / HSTS / frame security headers — next.config.ts
• M-05 ENCRYPTION_KEY SHA-256 fallback accepts weak secrets — require 32-byte base64
• M-06 DB dump/restore inlines unquoted passwords — lib/docker/databases.ts
• M-07 API tokens have no scopes (full role via MCP) — add read/deploy/admin scopes
• M-08 Terminal ticket in WebSocket query string — prefer header / first-message auth

Low / Info

• L-01 bcrypt cost 10; no password max length
• L-02 7-day sessions without idle timeout
• L-03 resend-otp without pending-signup guard
• L-04 Admin paths gated by owner email vs isInstanceAdmin mismatch in proxy.ts
• L-05 Keep Dependabot / CI dependency audit required
• I-01 Document PaaS trust model (admin Dockerfile/terminal = host control)
• I-02 Public DB port footgun — warn / auto-close on stop/delete

Already in good shape (no action)

• Project/workspace RBAC on service APIs
• AES-256-GCM secrets at rest
• Revocable sessions (sid + AuthSession)
• OTP hashed + attempt caps
• Git sync shell quoting + safe ref names
• GitHub/GitLab/Stripe signature verification
• SSH hostVerifier Peon→VPS (fix: verify SSH host keys with trust-on-first-use and optional pinning #15)
• Terminal re-checks membership on connect
• Chat mutating tools require approval
• Agent push bearer + timingSafeEqual

Suggested 30-day order

1. H-01, L-03 — auth rate limits
2. H-02 — SSRF guards
3. H-03 — delete teardown (beyond warn: stop service before delete — containers keep running #16 warning)
4. M-01, M-04, M-05 — git host keys, headers, encryption key
5. M-03, M-06, M-07 — webhooks, DB shell, token scopes
6. M-08, L-02, L-05 — terminal ticket, idle timeout, CI audit

Limitations

Static review only. No production exploit attempts. Infra / AWS IAM / host OS outside this repo.

[JamBalaya56562]

I'd like to pick up H-01 if it isn't already in progress.

Two things I ran into reading that area that aren't quite captured above.

The client IP is attacker-controlled today. extractSessionMeta
(src/lib/auth/session-meta.ts) takes the first entry of X-Forwarded-For,
falling back to X-Real-IP, with no trusted-proxy check. Any client can set
that header, so an IP-keyed limiter would be bypassed by varying it per
request — and the same value is what gets stored on AuthSession. However
H-01 is shaped, deciding how the client IP is derived (trusted proxy hop count
or allowlist, configurable for people not behind a proxy) has to come first, or
the limit is decorative.

The OTP attempt cap resets on resend. MAX_ATTEMPTS = 5 in
services/internal/email/otp.ts is per OTP record, and generateAndSend
deletes the existing record before creating a fresh one with attempts = 0.
With resend-otp unthrottled the cap can be reset at will, so "OTP hashed +
attempt caps" under Already in good shape is a little optimistic. Rate
limiting resend is what makes that cap real — worth folding into H-01 rather
than carrying it only as L-03.

On scope: there is no second factor to fall back on. twoFactorSecret /
twoFactorRecoveryCodes / twoFactorConfirmedAt exist on User, but there is
no TOTP dependency and no production code reads them, so those columns are
unused. Not a vulnerability in itself — there is nothing to bypass — but it
does mean the password is the only gate, which I think supports H-01 sitting at
the top of the list.

Before writing anything I'd rather agree on the shape, since several of the
choices are yours:

1. Where. proxy.ts runs on the edge runtime, so it can't reach Prisma.
   That points at the route layer — the route() wrapper in
   lib/http/response.ts could take an opt-in rate limit option so the auth
   routes get it without touching each handler. Happy to do it per-route
   instead if you prefer explicit over implicit.
2. Store. Postgres, unless you want to take on Redis. There's precedent in
   EmailOtp.attempts, and auth volume is low enough that a table is fine. A
   per-process in-memory counter would be simpler but silently wrong as soon as
   the app is scaled out.
3. Keying and response. My suggestion: a generous per-IP limit plus a
   per-account backoff, and never a hard account lockout — an unauthenticated
   request should not be able to lock a user out. 429 with Retry-After.
   H-01 mentions CAPTCHA; I'd leave that out of a first PR since it pulls in a
   third party and a config surface, unless you want it now.
4. Config. Limits as env vars with sane defaults, or fixed?

Tell me what you'd prefer and I'll open a PR. Happy to take M-01 (the
StrictHostKeyChecking=no follow-up I flagged in #15) separately too.

On M-02 — that fail-open on an unparseable pin is mine, from #15. I chose it so
a corrupted stored value couldn't lock a server out with no way back, but
you're right that it is fail-open. If you'd rather it refuse and surface a
"clear the stored host key" error instead, say the word and I'll change it.

[JamBalaya56562]

Two notes from reviewing #22, recorded here rather than on the PR since neither is something that PR needs to fix.

Password spraying is outside what per-email limiting can cover. One attempt per account across many accounts never trips an email bucket; only the IP bucket would, and that depends on the client IP being trustworthy (the first point in my earlier comment). So spraying stays open until the trusted-proxy question is resolved, independently of #22.

On the OTP attempt cap (MAX_ATTEMPTS resetting on resend, my second point above): #22 adds a 5/hour per-email limit on resend-otp, which caps the practical ceiling at roughly 25 guesses/hour against a 10⁶ space. That's acceptable in practice, so I don't think the reset itself needs fixing — but the two are now coupled, and raising the resend limit later would quietly widen the OTP ceiling. Worth a comment at one of the two sites.