gpt-mcp-server

CRITICAL ISSUES: 1. Weak Password Hashing: The mock OAuth provider (NeDBUsersStore) uses SHA256 for password hashing, which is not cryptographically secure for user credentials in production environments and is highly susceptible to brute-force and rainbow table attacks. The code acknowledges this is 'for demo purposes' but it's a severe vulnerability if used. 2. Access Token Logging: When `LOG_REQUEST_RESPONSE` environment variable is set to `true`, the full `Authorization` header (including sensitive access tokens) is explicitly logged in plaintext to the console (main.ts, `oauthHeaders.authorization` in access log middleware). This is a severe security risk as access tokens grant access to user data and should never be logged. 3. Wildcard CORS for Admin API: The admin API (admin-server.ts) uses `Access-Control-Allow-Origin: *` (wildcard CORS). While the local version runs on a separate port, the Vercel deployment integrates it into the main app. Exposing an administrative interface with such permissive CORS without strong authentication and origin checks is a high security risk. OTHER ISSUES: - Non-persistent Data in Serverless: The in-memory MCP sessions and the NeDB database (when `OAUTH_DB_PATH` points to `/tmp/db` on Vercel) are not persistent across serverless function invocations or server restarts, leading to data loss for OAuth clients, users, and sessions. This is a functional limitation, not a direct security flaw in the code logic itself, but impacts the reliability and security posture of the OAuth provider in a production serverless environment.