We release patches for security vulnerabilities. Currently supported versions:
| Version | Supported |
|---|---|
| 1.x | ✅ |
| < 1.0 | ❌ |
We take the security of Whatseerr seriously. If you believe you have found a security vulnerability, please report it to us as described below.
Please do NOT report security vulnerabilities through public GitHub issues.
Instead, please report them via one of the following methods:
- GitHub Security Advisories (preferred): Use the Security tab to privately report vulnerabilities
- GitHub Issues: For non-critical security concerns, you may create a private issue
Please include the following information:
- Type of vulnerability
- Full paths of source file(s) related to the vulnerability
- Location of the affected source code (tag/branch/commit or direct URL)
- Step-by-step instructions to reproduce the issue
- Proof-of-concept or exploit code (if possible)
- Impact of the vulnerability
- Acknowledgment: We will acknowledge receipt of your vulnerability report within 48 hours
- Updates: We will provide regular updates on our progress
- Timeline: We aim to patch critical vulnerabilities within 7 days
- Credit: We will credit you in the security advisory unless you prefer to remain anonymous
-
API Keys: Never commit API keys to version control
- Store API keys in
config.json(already in.gitignore) - Use environment variables for sensitive data when possible
- Rotate API keys regularly
- Store API keys in
-
File Permissions:
chmod 600 config/config.json # Readable only by owner -
Network Security:
- Run Whatseerr behind a reverse proxy (nginx, Traefik)
- Use HTTPS for webhook endpoints when exposed to internet
- Restrict webhook access to WAHA and Seerr IPs if possible
-
Run as Non-Root User: The container runs as root by default. For production, consider creating a non-root user:
USER node -
Read-Only Root Filesystem:
docker run --read-only -v /path/to/config:/config:rw whatseerr
-
Resource Limits:
# docker-compose.yml services: whatseerr: deploy: resources: limits: cpus: '0.5' memory: 512M
-
Network Isolation:
- Use Docker networks to isolate services
- Only expose necessary ports
-
Dedicated User: Create a dedicated user in Seerr for Whatseerr
- Limit permissions to only what's needed
- Use a separate API key per integration
-
Admin Users: Carefully manage
admin: trueflag inuserIdMappings- Admin users can approve/decline requests
- Review admin list regularly
- API Key: Use a strong, unique API key for WAHA
- Session Management: Use dedicated session names
- Webhook Validation: Verify webhook requests come from WAHA
-
Updates: Keep Whatseerr and dependencies up to date
docker pull ghcr.io/sufxgit/whatseerr:latest
-
Audit Logs: Regularly review logs for suspicious activity
docker logs whatseerr-bot | grep -i "error\|warn"
-
Dependency Scanning: Use tools like
npm auditto check for vulnerabilitiesnpm audit npm audit fix
- LID (Linked ID) cannot be resolved until users initiate a chat with the bot
- This is a WhatsApp limitation, not a security issue
- Admins will be notified when LID resolution fails
- Built-in rate limiting protects against abuse (100 requests/minute by default)
- Configurable via
config.json:rateLimit.maxRequests
- Users must be configured in
userIdMappingsto interact with the bot - Messages from unknown users are ignored (logged but not processed)
When we receive a security vulnerability report, we will:
- Confirm the vulnerability and determine its impact
- Develop and test a fix
- Release a security advisory and new version
- Credit the reporter (unless anonymity requested)
We follow the principle of responsible disclosure and request that security researchers:
- Allow reasonable time to respond before public disclosure
- Make a good faith effort to avoid privacy violations and service disruption
- Do not access or modify other users' data
For security-related questions or concerns, please use GitHub Security Advisories or contact the maintainers through GitHub issues.