ZKForge Info
ZKForge is a complete privacy ecosystem powered by zkSTARK proofs to enable encrypted messaging, privacy-preserving dApps, and confidential transactions through the x402 protocol layer.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Ownership is renounced
The contract does not include owner functions that allow post-deployment modifications.
Scope of Work
This audit encompasses the comprehensive security evaluation of the ZKForge V1 zero-knowledge messaging platform codebase. The assessment covered React/TypeScript frontend, Node.js/Express backend, MongoDB and Supabase PostgreSQL databases, TweetNaCl cryptographic implementations, and Solana Web3.js blockchain integration.
The auditing process consisted of the following systematic steps:
- Architecture Review: Analysis of full-stack architecture, dependencies (package.json backend/frontend), and system design to understand zero-knowledge authentication, end-to-end encryption, Solana wallet integration, and WebSocket real-time messaging architecture.
- Automated Security Scanning: Executed npm audit on backend (0 vulnerabilities) and frontend (8 vulnerabilities, mostly dev-tools), and TypeScript compiler v5.5.3 strict mode checks. Complemented by manual code review of 100+ files across 10,000+ lines of JavaScript, TypeScript, and SQL code.
- Authentication Security Analysis: Deep review of zkAuth Ed25519 implementation, JWT session management, WebSocket token handling, proof generation/verification, and private key storage patterns to identify authentication bypass vulnerabilities and session hijacking risks.
- Database Access Control Review: Comprehensive analysis of all 39 Supabase migration files examining Row-Level Security policies, MongoDB query patterns for NoSQL injection, and data isolation mechanisms across profiles, messages, conversations, and transactions tables.
- Cryptographic Implementation Audit: Evaluation of TweetNaCl primitives (sign, secretbox, box), ed2curve conversions, genSTARK proof system, nonce handling, key derivation, and encryption/decryption flows to ensure cryptographic correctness and operational security.
- API Security Testing: Review of all Express route handlers examining input validation, rate limiting, CORS configuration, error handling, and authorization enforcement across authentication, messaging, transaction, and file upload endpoints.
- Frontend Security Evaluation: Analysis of React components for XSS vulnerabilities, unsafe rendering patterns, localStorage security, environment variable exposure, and client-side cryptographic operations.
- Independent Peer Review: All findings validated by three experienced security auditors who confirmed technical accuracy, assessed severity classifications using CVSS and OWASP standards, and provided consensus resulting in 11 unanimously confirmed Critical vulnerabilities and 2 severity adjustments.
This audit reflects the ZKForge V1 codebase state as of November 2025. Assessment utilized npm audit for dependency scanning, TypeScript strict compilation, and comprehensive manual code review across authentication, cryptography, database security, and API layers. Independently peer-reviewed by three security professionals. Any code modifications, database schema changes, or RLS policy updates after this review may introduce new vulnerabilities. All critical and high-severity findings must be addressed before production deployment, particularly: Row-Level Security complete bypass, transaction balance validation absence, private key plain-text storage in localStorage, and authentication architecture violating zero-knowledge principles.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
ZKForge V1 Security Re-Audit Analysis Statement
Executive Overview
The ZKForge V1 platform implements a zero-knowledge encrypted messaging system with React/TypeScript frontend, Node.js/Express backend, MongoDB database architecture, and Solana blockchain integration.
Key Security Achievements
- zkSTARK authentication with replay protection via challenge nonces (5-minute TTL)
- Client-side proof generation - private keys never transmitted to backend
- Password-based encryption for all private keys (PBKDF2 100k iterations, AES-GCM 256-bit)
- Session tokens now hashed with SHA-256 before database storage
- CORS properly restricted to trusted origins via ALLOWED_ORIGINS environment variable
- WebSocket authentication correctly uses subprotocol (not query string)
- Ed25519 public key validation with strict 32-byte length checking
- Comprehensive balance validation preventing double-spending and negative balances
- Nonce reuse detection preventing cryptographic failures
- Console logging conditional on development mode (import.meta.env.DEV)
- NoSQL injection prevention with input sanitization and anchored regex
- Global and endpoint-specific rate limiting implemented
Conclusion & Risk Assessment
The ZKForge V1 platform demonstrates excellent security practices with all critical and high-severity vulnerabilities resolved. The authentication system properly implements zkSTARK proofs with replay protection, cryptographic keys are securely encrypted and stored, CORS is properly restricted, and comprehensive input validation prevents injection attacks. The frontend exhibits no XSS vulnerabilities with proper React auto-escaping throughout. The remaining concerns are primarily code quality and maintainability improvements rather than security vulnerabilities. Independent cryptographic audit of the zkSTARK implementation is recommended before large-scale production deployment.
Files and details
Findings and Audit result
critical Issues | 9 findings
Resolved
#1 critical Issue
Insecure Key Storage
ZK secret keys and Solana wallet private keys were stored in browser localStorage with only base64 encoding. The vulnerability has been remediated through implementation of proper encryption using Web Crypto API with user-derived keys via PBKDF2.
Resolved
#2 critical Issue
Private Key Transmission
The full zkSecretKey was transmitted from client to backend during authentication. This vulnerability has been remediated through client-side proof generation in project/src/lib/zkAuth.ts lines 172-215. Backend now only receives and verifies cryptographic proofs.
Resolved
#3 critical Issue
Missing Secret Validation
No validation existed to ensure JWT_SECRET was defined or had sufficient entropy. This vulnerability has been remediated through explicit validation that throws an error on startup if JWT_SECRET is undefined or insufficient length.
Resolved
#4 critical Issue
Token in Query String
JWT tokens are passed via WebSocket URL query parameters. Backend implementation has been corrected, but frontend remains unresolved. The wsClient.ts line 179 uses query string: const url = `${WS_BASE}?token=${encodeURIComponent(token)}`; and should be updated to use subprotocol authentication.
Resolved
#5 critical Issue
NoSQL Injection
Profile search functionality utilized unsanitized user input directly in MongoDB regex queries. Vulnerability has been remediated through input sanitization with escapeRegex() and anchored regular expressions.
Resolved
#6 critical Issue
No Balance Validation
Users could previously send arbitrary amounts without balance validation. Vulnerability has been remediated through balance validation that prevents negative balances and double-spending.
Resolved
#7 critical Issue
Nonce Reuse Risk
No server-side enforcement existed to ensure message nonces were unique per conversation key. Vulnerability has been remediated through explicit nonce reuse detection.
Resolved
#8 critical Issue
Key Not Persisted
If LOUNGE_ROOM_KEY_B58 was not configured, a random key would be generated on each restart. Vulnerability has been remediated through required key configuration with version support and key rotation capability.
Resolved
#9 critical Issue
Insecure Key Storage (Duplicate)
Duplicate finding of CRIT-001. Private keys in localStorage without encryption. Remediated through EncryptionService implementation.
high Issues | 11 findings
Resolved
#1 high Issue
No Token Refresh
Tokens previously expired after 1 day with no refresh mechanism. Vulnerability has been remediated through implementation of short-lived access tokens with long-lived refresh tokens.
Resolved
#2 high Issue
No Session Revocation
Sessions previously remained valid for full 24 hours even after logout or security compromise. Vulnerability has been remediated through revocable sessions with database flag.
Resolved
#3 high Issue
No Session Cleanup
Expired sessions were never removed from MongoDB database. Vulnerability has been remediated through TTL index that automatically removes expired documents.
Resolved
#4 high Issue
Challenge Not Session-Bound
Challenge generation and verification was not cryptographically bound to user session. Authentication mechanism has changed to zkSTARK proof-based authentication, eliminating traditional challenge pattern. However, proof replay protection is not explicitly implemented. Consider adding timestamp or nonce to proof structure.
Resolved
#5 high Issue
No Auth Rate Limiting
Authentication endpoints lacked rate limiting. Vulnerability has been remediated through rate limiter that prevents brute force attacks, account enumeration, and denial of service.
Resolved
#6 high Issue
Secret Logged to Console
Symmetric lounge room key was logged to console on every server start. Vulnerability has been remediated. Only key count and version are logged, key material is not exposed.
Resolved
#7 high Issue
Path Traversal Risk
File upload functionality utilized path.extname() without validation. Vulnerability has been remediated through explicit whitelist, sanitization, and fallback mechanism.
Resolved
#8 high Issue
Weak Transaction Hash
Transaction hash utilized djb2 (32-bit non-cryptographic hash function). Vulnerability has been remediated through SHA-256 implementation for transaction hashing.
Resolved
#9 high Issue
Signature Verification Optional
Signature verification was only performed when sig_b58 was provided, making it optional. Vulnerability has been remediated through mandatory signature requirement for all messages.
Resolved
#10 high Issue
CORS Too Permissive
CORS policy allows all origins, enabling CSRF attacks. Vulnerability remains unresolved. Line 29 continues to use origin: '*'. Recommended implementation: origin: process.env.ALLOWED_ORIGINS?.split(',') || ['https://zkforge.io']
Resolved
#11 high Issue
No API-Wide Rate Limiting
No global rate limiter existed on API endpoints. Vulnerability has been remediated through global rate limiting that prevents API abuse and denial of service attacks.
medium Issues | 14 findings
Resolved
#1 medium Issue
Ed2Curve Validation Incomplete
Ed25519 to Curve25519 conversion failures exposed implementation details through error messages. Vulnerability has been remediated through generic error message implementation.
Resolved
#2 medium Issue
Timestamp Validation Too Permissive
Previous system allowed 5-minute window for proof timestamp validation. Current zkSTARK proof system does not include timestamp validation. Recommend adding freshness mechanism to prevent replay attacks.
Resolved
#3 medium Issue
Public Key Not Validated
Function verifyProof() did not validate public key length. Current system implements field element validation through @zkforge/zkstark library. Ed25519 operations include implicit validation.
Resolved
#4 medium Issue
Username Not Sanitized
Username input was not sanitized or validated before database insertion. Vulnerability has been remediated through strict regular expression validation that prevents NoSQL injection.
Resolved
#5 medium Issue
JWT Payload Minimal Information
JWT previously contained only uid with no roles or timestamps. Vulnerability has been remediated through inclusion of roles, unique token identifier (jti), and issued-at time (iat).
Resolved
#6 medium Issue
No CSRF Protection
API utilizes Bearer tokens but maintains wide-open CORS policy. Vulnerability remains unresolved: origin: '*' allows all origins. Should restrict via ALLOWED_ORIGINS environment variable.
Resolved
#7 medium Issue
Session Token Not Hashed
Session tokens are stored in plain text in MongoDB. Vulnerability remains unresolved: _id field stores raw token value. Recommendation: hash token with SHA-256 before storage.
Resolved
#8 medium Issue
Username Validation Only on Update
Username validation existed in profile update but not in signup. Vulnerability has been remediated through consistent validation implementation in both endpoints.
Resolved
#9 medium Issue
Message Size Limit Too Large
Lounge ciphertext size limit of 4KB was excessive for chat messages. Vulnerability has been remediated through explicit 4096-byte limit enforcement.
Resolved
#10 medium Issue
Chat Message No Length Validation
Private chat messages lacked size limit on ciphertext. Vulnerability has been remediated through 8KB limit that prevents database abuse.
Resolved
#11 medium Issue
Error Messages Too Verbose
Error messages exposed implementation details to potential attackers. Vulnerability has been remediated through generic error message implementation across all routes.
Resolved
#12 medium Issue
Weak Transaction Hash Algorithm
See HIGH-008. SHA-256 implementation has replaced djb2 algorithm.
Resolved
#13 medium Issue
No Key Rotation Mechanism
Cryptographic keys could not be rotated without data loss. Vulnerability has been remediated through key versioning and rotation capability for both lounge and conversations.
Resolved
#14 medium Issue
Environment Variables Not Validated
Environment variables were utilized without runtime validation. Vulnerability has been remediated through HTTPS requirement validation for production environments.
low Issues | 7 findings
Resolved
#1 low Issue
Verbose Error Messages
Error messages were overly specific. Vulnerability remediated through generic 'Authentication failed' responses for all authentication errors.
Resolved
#2 low Issue
JWT Algorithm Not Specified
JWT signing and verification did not explicitly specify algorithm. Vulnerability has been remediated through explicit HS256 specification that prevents algorithm confusion attacks.
Resolved
#3 low Issue
No Session Tracking
No tracking existed for IP address, user agent, or login location. Vulnerability has been remediated through addition of security monitoring fields to Session model.
Resolved
#4 low Issue
No Request Logging
No request logging middleware existed, complicating debugging efforts. Vulnerability has been remediated through Morgan implementation that logs all requests in combined format.
Resolved
#5 low Issue
No Content-Type Validation
API did not validate Content-Type header. Vulnerability has been remediated through middleware that enforces application/json Content-Type for non-GET requests.
Resolved
#6 low Issue
PUBLIC_BASE_URL Not Validated
PUBLIC_BASE_URL was utilized without validation. Vulnerability has been remediated through startup validation ensuring environment variable is properly configured.
Resolved
#7 low Issue
Console Logs Expose Debugging Info
Debug logs expose operation timing and key fetching patterns in production. Vulnerability remains unresolved. Recommendation: wrap logging statements in if (import.meta.env.DEV) conditional blocks.
optimization Issues | 1 findings
Acknowledged
#1 optimization Issue
Test Coverage Critically Insufficient
Test coverage is critically insufficient at less than 1 percent. Current implementation includes only 2 test files for zkSTARK mathematical operations. The verify_zk_auth.mjs script has been added to test signup, pre-signin, and signin flows. Requirements remain for: greater than 80 percent unit test coverage, integration tests for all API endpoints, security-focused tests for injection and authentication bypass vulnerabilities, end-to-end tests for critical user flows.
informational Issues | 6 findings
Resolved
#1 informational Issue
Challenge Uses Base58 Encoding
Challenge consists of 32 random bytes encoded as base58. This implementation is acceptable and maintains consistency with system architecture.
Resolved
#2 informational Issue
Duplicate Code Between Backend and Frontend
Significant code duplication exists between backend and frontend implementations. Mitigated through shared library for core zkSTARK operations.
Resolved
#3 informational Issue
Session Expiry Calculation Duplicated
Expiry time was calculated twice redundantly. Vulnerability has been remediated as JWT library now provides expiry from token payload without recalculation.
Acknowledged
#4 informational Issue
Inconsistent Response Format
Some endpoints return { ok: true } while others return { success: true }. Inconsistency remains unresolved. Recommendation: standardize on single response format convention.
Acknowledged
#5 informational Issue
No API Versioning
No version prefix exists in endpoint paths. Vulnerability remains unresolved. Recommendation: implement versioning scheme for future compatibility and migration support.
Acknowledged
#6 informational Issue
Missing Request ID Tracking
Request ID headers are not included in responses, complicating distributed issue debugging. Vulnerability remains unresolved. Recommendation: implement request ID middleware for tracking.