DO NOT open a public GitHub issue for security vulnerabilities. Report them responsibly to security@rethunk.tech.

Response SLA: We aim to respond to security reports within 24 hours.

When reporting a vulnerability, please include:

• Description of the vulnerability
• Affected component(s) and version(s)
• Steps to reproduce, if applicable
• Potential impact
• Suggested fix, if available

rethunk-github-mcp is an MCP server that exposes GitHub API operations to LLMs. It has elevated security implications due to API access, cross-repo visibility, and write-capable automation.

• Critical: The server authenticates with GitHub via personal access token or app credentials.
• Tokens must never be embedded in code or logs.
• Environment variables such as GITHUB_TOKEN require protection.
• Token scopes should be limited to the minimum required operations.
• Prefer separate tokens for read-only rollups vs. write-capable automation.

• High: MCP tools batch multiple API calls; rapid rate-limit exhaustion is possible.
• Tools such as repo_status and ecosystem_activity can execute many API calls per invocation.
• Implement rate-limit detection and backoff in client code.
• Monitor for unusual token usage patterns.

• Medium: Sensitive repo or org data, including private repository names and CI logs, could be exposed.
• Treat all tool outputs as potentially sensitive.
• Do not expose raw upstream data in logs or error messages.
• Validate all inputs to prevent API-injection style abuse.

• High: Some tools create or mutate GitHub state: pr_create, pr_comment_batch, issue_from_template, release_create, workflow_dispatch, labels_sync, and check_run_create.
• Accidental or repeated calls can create duplicate PRs, issues, reviews, releases, workflow runs, or check runs.
• Use least-privilege tokens and prefer test repositories for first-time validation.
• Treat write-capable tokens as operational credentials with tighter blast-radius controls than read-only rollups.

• High: Tools operate across multiple repos and orgs if configured.
• Ensure token scopes do not exceed intended access.
• Validate repo access before returning sensitive data.
• Be mindful of PR labels, commit messages, and CI logs that may contain secrets.

• Use GitHub personal access tokens or app credentials.
• Never commit tokens; use environment variables only.
• Rotate tokens regularly.
• Keep read-only and write-capable tokens separate when possible.
• Monitor token usage through GitHub audit logs.

• Validate all input parameters such as repo names, refs, and workflow identifiers.
• Implement exponential backoff for rate-limit responses.
• Set timeouts on API calls to prevent hanging.
• Log API calls without exposing tokens.

• Do not expose raw GitHub API responses without review.
• Sanitize error messages so tokens and other secrets cannot leak.
• Be mindful of CI logs and commit messages that may contain sensitive material.
• Trim suspiciously large outputs.

• Prefer idempotent write tools where available; labels_sync converges to a declared state.
• For non-idempotent tools, assume retries may create additional state and confirm inputs before re-running.
• Use branch protections, repository permissions, and GitHub audit logs as defense in depth.

• Keep octokit and related GitHub API packages up to date.
• Run bun audit regularly and address high or critical vulnerabilities.
• Review major version updates for API contract changes.

Latest release only.

None currently known. Reports are welcome via security@rethunk.tech.

• Octokit SDK is the official GitHub SDK; monitor it for updates.
• Review the GitHub API changelog for breaking changes and security fixes.
• Be aware of GitHub's own abuse prevention and rate limiting.

• Keep the Bun runtime updated for security patches.
• Monitor @octokit/rest and @octokit/graphql releases.
• Keep TypeScript current; stronger typing reduces avoidable runtime mistakes.

• Test read-only tools with read-only tokens before production deployment.
• Test write-capable tools against a throwaway or explicitly approved repository before production use.
• Validate rate-limit handling with heavy multi-repo queries.
• Test error handling with invalid repos or tokens.
• Do not test against production tokens; use a limited-scope test credential.

If a security vulnerability is discovered:

1. Report immediately to security@rethunk.tech and do not disclose publicly.
2. Include reproduction steps and affected version(s).
3. Allow 24-48 hours for initial response and triage.
4. Coordinate a disclosure timeline if a patch is required.
5. Credit will be given to the reporter if desired.

• Security Issues: security@rethunk.tech
• General Support: support@rethunk.tech
• Website: rethunk.tech

Last updated: 2026-05-07