| Version | Supported |
|---|---|
Latest (master branch) |
✅ |
| Older tags | ❌ |
Only the current master branch receives security fixes.
Do not open a public GitHub issue for security vulnerabilities.
Please report security issues privately by emailing:
fieldtrack-tech [at] gmail.com
Include in your report:
- A description of the vulnerability
- The file(s) or component(s) affected
- Steps to reproduce (if applicable)
- Potential impact assessment
- Any suggested fix (optional but appreciated)
You will receive an acknowledgement within 48 hours and a resolution timeline within 7 days for confirmed vulnerabilities.
Vulnerability: CVE-2023-48223 (fast-jwt algorithm confusion)
Context:
- This project uses ES256 (ECDSA, asymmetric) JWTs issued by Supabase
@fastify/jwtpackage has a transitive dependency onfast-jwt@^6.0.2, which is vulnerable- However, @fastify/jwt is ONLY used in tests (moved to devDependencies)
- Production code NEVER loads @fastify/jwt or fast-jwt
Mitigation:
- Production: Uses
jsonwebtoken+jwks-rsafor verification (completely separate library, not vulnerable) - Tests: Uses
@fastify/jwt(HS256, test-only, matches test secret in CI environment) - Enforcement:
algorithms: ["ES256"]is explicitly set in jwtVerifier.ts - Defense-in-depth: Header algorithm is validated before signature verification (3 layers total)
- Dependency boundary: CI verifies
@fastify/jwtis NOT in production bundle
Risk Level: NONE
Why this is safe:
- Asymmetric keys (JWKS endpoint): CVE-2023-48223 exploits symmetric key confusion, which cannot happen with asymmetric keys
- Explicit algorithm restriction to ES256 prevents fallback to HS256
- Token audience is validated (blocks service_role tokens)
- Test environment is isolated; @fastify/jwt only used in test server
- Production dependencies do NOT include @fastify/jwt or fast-jwt (verified by CI)
- No fast-jwt code can execute in production (dependency not present)
Monitoring:
- CI checks:
npm ls @fastify/jwt --prod(verifies not in production) - Audit level:
--audit-level=critical(only critical runtime vulnerabilities fail) - Package.json: @fastify/jwt moved to devDependencies
- Waiting for upstream fast-jwt fix anyway
- Authentication and authorization bypasses
- Tenant isolation failures (cross-organization data access)
- JWT validation weaknesses
- SQL injection or data exfiltration via Supabase queries
- Rate limiting bypasses that could enable denial-of-service
- Sensitive data exposure (logs, error responses, API responses)
- Remote code execution vulnerabilities
- Dependency vulnerabilities with known CVEs affecting production functionality
- Issues in the example/test environment configuration (
tests/setup/env-setup.tsuses intentionally fake credentials) - Vulnerabilities that require physical access to the VPS
- Issues in third-party services (Supabase, GitHub, GHCR)
- Theoretical vulnerabilities without a working proof of concept
These design decisions are intentional and not vulnerabilities:
sequence_numberingps_locationsis nullable by design during mobile stabilization — ordering falls back torecorded_atGET /debug/redisis disabled in production (NODE_ENV=productionreturns 404) — this is enforced in code, not just config- JWT claims are re-validated on every request using Zod — stale or malformed claims are rejected even if the signature is valid
- Rate-limit counters are stored in Redis with a separate connection from the job queue to prevent counter manipulation via queue exhaustion
Dependencies are managed via npm ci (deterministic installs from package-lock.json). To audit for known vulnerabilities:
cd backend
npm auditCritical and high severity vulnerabilities in production dependencies block deployment via CI.