Gmail AutoAuth MCP Server
@gongrzhe/server-gmail-autoauth-mcp@1.1.1155K weekly downloads. Convenient OAuth flow, broad Gmail permissions, and three one-liner security fixes that haven't been applied.
Findings
Path traversal in download_attachment
Attachment filenames from email MIME metadata are passed directly to path.join() without path.basename() sanitization. A malicious sender can craft a filename like ../../.ssh/authorized_keys to write to arbitrary paths on the filesystem.
No CSRF state parameter in OAuth callback
The OAuth flow starts an HTTP server on localhost:3000 but generates no state parameter. Another process on localhost can race the callback and complete the exchange with an attacker-controlled authorization code.
OAuth tokens stored as plaintext at 0644 permissions
credentials.json is written to ~/.gmail-mcp/ with fs.writeFileSync() at default umask permissions (0644 on macOS). Any process running as the user can read a long-lived Gmail refresh token.
Arbitrary OAuth callback URL from command line
process.argv[3] is passed directly as the OAuth redirect URI with no validation. Documented usage shows a third-party domain (gmail.gongrzhe.com) as the callback target. A malicious wrapper can redirect tokens to an attacker-controlled server.
Overly broad Gmail scopes
gmail.modify + gmail.settings.basic grants full inbox read/write/delete and the ability to create forwarding filters. Most use cases need only gmail.readonly + gmail.send.
mcp-evals in runtime dependencies
An eval framework with a single anonymous maintainer is included in dependencies rather than devDependencies, adding unnecessary attack surface to production installs.
MCP SDK pinned at ^0.4.x (14 months outdated)
The MCP SDK is at version 1.x. Running on pre-stable 0.4.x means running on unmaintained protocol semantics.
Useful tool. Three of seven findings are 1-2 line fixes. Patch before production.