Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

GitHub MCP Server

v1.0.0

GitHub MCP Server enables AI agents to manage repos, read/update files, handle issues/PRs, branches, and automate GitHub workflows via the API.

0· 1.8k·21 current·24 all-time
bySiddharth Menon@buddhasource
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
VirusTotalVirusTotal
Suspicious
View report →
OpenClawOpenClaw
Suspicious
medium confidence
!
Purpose & Capability
The name and description match the SKILL.md instructions (GitHub repo and issue/PR management). However, the registry metadata declares no primary credential or required env vars while the SKILL.md explicitly instructs the user to provide a GITHUB_PERSONAL_ACCESS_TOKEN (and recommends scopes such as repo/read:org). That omission is an inconsistency: a GitHub integration legitimately needs credentials, so the metadata should declare them.
Instruction Scope
The runtime instructions themselves stay within the stated purpose: cloning repos, reading/updating files, creating issues/PRs, branch operations, and examples of workflows. The instructions do not ask agents to read unrelated system files or other credentials. They do, however, show example commands (npm install -g, git clone, npx) and configuration that will cause the agent to run external commands if followed.
Install Mechanism
This is an instruction-only skill (no install spec in registry), but the SKILL.md recommends installing @modelcontextprotocol/server-github via npm or building from a GitHub repo. Those sources are standard (GitHub/npm), not obviously malicious, but the registry's lack of an install spec means there's no pinned, auditable package/version; the use of 'npx -y' (runs remote code immediately) and unpinned installs increases risk unless the package and source are verified.
!
Credentials
The skill requires a GitHub token to operate, and the SKILL.md recommends broad scopes (e.g., repo full access). Yet requires.env in metadata is empty and primary credential is unset. Asking for full repo permissions is proportionate to many operations but should be explicit and minimized (fine-grained token limited to specific repos and scopes). The metadata omission prevents automated validation and is a meaningful gap.
Persistence & Privilege
The skill does not request always:true and has no declared config paths; that's appropriate. However, the platform default allows autonomous invocation. Combined with a GitHub token that grants write/merge/release rights, an autonomously-invoking agent could make destructive or sensitive changes. Consider adjusting invocation policies or token privileges accordingly.
What to consider before installing
This skill appears to do what it says (manage GitHub repos) but the registry metadata is incomplete: SKILL.md shows you must supply a GITHUB_PERSONAL_ACCESS_TOKEN (often with wide 'repo' scopes), yet the skill declares no required credentials. Before installing or using it: - Require the publisher to update metadata to list required env vars (e.g., GITHUB_PERSONAL_ACCESS_TOKEN) and to pin an install source/version. - Prefer a fine-grained GitHub token scoped only to the specific repos and permissions needed (Contents Read/Write, Issues/PRs only where necessary), and set an expiration. Avoid granting org-wide or full 'repo' scope when not needed. - Avoid running unpinned npx installs (-y) or global npm installs without auditing the package; prefer installing a specific, vetted release and review its source code. - Treat the token as sensitive: store it in a secrets manager or environment not accessible to other skills/agents. - If you do not want the agent to act autonomously, restrict the skill's invocation (disable autonomous invocation or require manual approval for actions that write/merge/create releases). What would change this assessment: metadata that declares the exact required env var(s), a pinned/official install source (GitHub release or verified npm package with version), and explicit recommendations for least-privilege token scopes would raise confidence toward 'benign'. Conversely, discovery of untrusted third-party install instructions, requests for unrelated credentials, or commands that read unrelated system files would lower confidence further.

Like a lobster shell, security has layers — review code before you run it.

latestvk972hf06g7mmy00dmyp0fykwed814f90

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

Comments