We release patches for security vulnerabilities in the following versions:

We take the security of Actual MCP Server seriously. If you discover a security vulnerability, please report it responsibly.

Please do NOT report security vulnerabilities through public GitHub issues.

Instead, please report security issues to:

Email: security@example.com (replace with your actual email)

Or use GitHub's private vulnerability reporting:

1. Go to the repository's Security tab
2. Click "Report a vulnerability"
3. Fill out the vulnerability report form

Please include the following information in your report:

• Type of vulnerability (e.g., SQL injection, XSS, authentication bypass)
• Full path of affected source file(s)
• 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
• Potential fixes (if you have suggestions)

• Initial Response: Within 48 hours
• Status Update: Within 7 days
• Fix Timeline: Depends on severity
  • Critical: 1-7 days
  • High: 7-30 days
  • Medium: 30-90 days
  • Low: Best effort

1. You report the vulnerability privately
2. We acknowledge your report within 48 hours
3. We investigate and confirm the vulnerability
4. We develop a fix in a private repository
5. We notify you when the fix is ready
6. We release the fix and security advisory
7. We credit you in the advisory (if desired)

We will publicly acknowledge security researchers who responsibly disclose vulnerabilities (unless you prefer to remain anonymous).

1. Use Docker Secrets or Kubernetes Secrets for sensitive data:

   # Don't use environment variables for passwords
   # Use Docker secrets instead
   echo "your_password" > secrets/actual_password.txt
   chmod 600 secrets/actual_password.txt

2. Enable HTTPS with valid TLS certificates:

   # Use reverse proxy (nginx, Traefik) with Let's Encrypt
   # Never expose MCP server directly without HTTPS

3. Set Authorization Tokens:

   # Generate strong random token
   MCP_SSE_AUTHORIZATION=$(openssl rand -hex 32)

4. Restrict Network Access:

   # Use firewall rules to limit access
   # Example: Only allow from LibreChat server IP
   iptables -A INPUT -p tcp --dport 3600 -s 10.0.0.5 -j ACCEPT
   iptables -A INPUT -p tcp --dport 3600 -j DROP

5. Regular Updates:

   # Keep dependencies updated
   npm audit
   npm audit fix
   
   # Pull latest Docker image
   docker pull ghcr.io/agigante80/actual-mcp-server:latest

# Environment files should be read-only for owner
chmod 600 .env
chmod 600 secrets/*.txt

# Verify permissions
ls -la .env secrets/
# Should show: -rw------- (600)

# ❌ DON'T: Commit .env files to git
git add .env  # BAD!

# ✅ DO: Use .env.example as template
git add .env.example  # OK

# ✅ DO: Add .env to .gitignore
echo ".env" >> .gitignore

1. Input Validation: Always validate user input with Zod schemas

   const InputSchema = z.object({
     id: z.string().uuid(),
     amount: z.number().int().positive(),
   });

2. SQL Injection Prevention: Use parameterized queries (Actual Budget API handles this)

3. Authentication: Never log or expose passwords

   // ❌ BAD
   logger.debug('Password:', password);
   
   // ✅ GOOD
   logger.debug('Authentication successful');

4. Error Handling: Don't expose sensitive info in errors

   // ❌ BAD
   return { error: `Database error: ${dbError.message}` };
   
   // ✅ GOOD
   logger.error('Database error:', dbError);
   return { error: 'An internal error occurred' };

5. Dependencies: Keep dependencies up-to-date

   npm audit
   npm outdated

• No hardcoded credentials
• Input validation with Zod
• Error messages don't leak sensitive data
• Logging doesn't contain passwords/tokens
• Dependencies are up-to-date
• Tests cover security-critical paths

1. No Built-in Authentication: The MCP server doesn't implement user authentication

   • ⚠️ Impact: Anyone with network access can use the server
   • ✅ Mitigation: Use reverse proxy with authentication (nginx + Basic Auth, OAuth2 Proxy)
   • ✅ Mitigation: Use MCP_SSE_AUTHORIZATION token for SSE transport
   • ✅ Mitigation: Firewall rules to restrict access

2. Direct Actual Budget Access: Server has full access to Actual Budget

   • ⚠️ Impact: All operations are allowed (read/write/delete)
   • ✅ Mitigation: Run with least-privilege Actual Budget user (if supported in future)
   • ✅ Mitigation: Regular backups of Actual Budget data

3. No Rate Limiting: No built-in rate limiting

   • ⚠️ Impact: Potential for abuse or DoS
   • ✅ Mitigation: Use reverse proxy with rate limiting (nginx limit_req)
   • ✅ Mitigation: Internal concurrency limiting (5 concurrent requests)

4. Local Data Storage: Budget data cached in SQLite

   • ⚠️ Impact: Sensitive financial data on disk
   • ✅ Mitigation: Encrypt Docker volumes or VM disks
   • ✅ Mitigation: Restrict file system permissions
   • ✅ Mitigation: Regular backups with encryption

• Read-only mode: Option to disable write operations
• API key authentication: Built-in token validation
• Rate limiting: Per-client request throttling
• Audit logging: Complete operation history
• Role-based access: Different permission levels
• Data encryption: Encrypt local SQLite database

We will publish security advisories for confirmed vulnerabilities:

• GitHub Security Advisories: View advisories
• Release Notes: Security fixes documented in releases

• No External Connections: Data stays between MCP server and Actual Budget
• No Telemetry: We don't collect usage data or analytics
• GDPR Compatible: All data is user-controlled and local

We follow security best practices from:

• OWASP Top 10: Web application security risks
• CWE Top 25: Most dangerous software weaknesses
• NIST Cybersecurity Framework: Security standards

For security-related questions (not vulnerability reports):

• GitHub Discussions: Security category
• Email: security@example.com (replace with your actual email)

We thank the following researchers for responsibly disclosing vulnerabilities:

No vulnerabilities reported yet.

Last Updated: November 2025