Back to skill

Security audit

GitHub Auto Reply

Security checks for vulnerabilities and agentic risk

Overview

This skill is a straightforward guide for setting up automatic GitHub issue replies, with some operational cautions around public comments and GitHub Actions hardening.

Before installing, review the reply text because comments may be public, restrict the workflow to intended repositories, add explicit minimal permissions, and pin the GitHub Action to a reviewed commit or approved version policy instead of broadly allowing all actions.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:50
Finding
Mutable GitHub Action Reference and Overly Broad Actions Allowlist<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:47-53` and `SKILL.md:77-79` **Vulnerability Type**: Supply-chain dependency risk **Risk Level**: Medium The documented workflow uses a mutable major-version tag for a GitHub Action: ```yaml steps: - name: Comment on issue uses: actions/github-script@v6 with: script: | const issue = context.payload.issue; const labels = issue.labels.map(l => l.name); ``` The documentation also directs users to enable an unrestricted Actions policy: ```markdown ### 2. Enable Actions - Repository Settings > Actions > Allow all actions ``` ### Technical Analysis The `actions/github-script@v6` dependency is referenced through a mutable version tag rather than an immutable, reviewed commit SHA. A version tag can resolve to different code after the workflow has been reviewed. Consequently, repository users cannot guarantee that future workflow runs execute the exact dependency revision originally audited. The recommendation to select “Allow all actions” unnecessarily expands the permitted dependency set. This permits workflows to invoke arbitrary third-party actions rather than limiting execution to GitHub-authored or explicitly approved actions. The example also does not declare explicit workflow-level or job-level `permissions`. Effective access therefore depends on repository and organization defaults. The workflow legitimately needs permission to create issue comments, but its token should not receive unrelated write capabilities. ### Attack Path 1. A repository administrator follows the documentation and permits all GitHub Actions. 2. The workflow or a subsequent workflow references an action through a mutable tag or introduces an unreviewed third-party action. 3. The referenced action is compromised, maliciously modified, or replaced with an unsafe revision. 4. GitHub downloads and executes that action on the hosted runner during a workflow run. 5. The action accesses the ...[truncated 1134 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin `actions/github-script` to a reviewed full commit SHA instead of a mutable version tag: ```yaml permissions: contents: read issues: write jobs: reply: runs-on: ubuntu-latest steps: - name: Comment on issue uses: actions/github-script@<reviewed-full-commit-sha> with: script: | // Existing reviewed script ``` 2. Record the corresponding release version in a comment so maintainers can track updates while preserving immutable execution: ```yaml uses: actions/github-script@<reviewed-full-commit-sha> # v6.x.x ``` 3. Replace “Allow all actions” with an organization or repository policy that permits only GitHub-authored actions or an explicit allowlist of reviewed actions. 4. Declare minimal token permissions explicitly. This workflow requires `issues: write` to create comments and should normally use `contents: read`; unrelated write permissions should be disabled. 5. Review dependency updates before changing the pinned SHA. Use an automated dependency-update tool configured to propose pull requests for action updates, and require code review before merging them. 6. Avoid exposing repository or organization secrets to this job unless they are strictly required. Apply environment protections and branch protections to reduce the consequences of a compromised workflow dependency. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Natural-Language Policy Violations

Medium
Confidence
91% confidence
Finding
The skill content is primarily in Chinese and presents Chinese as the default interaction language without clearly documenting locale expectations or requiring user opt-in. In a GitHub customer-support context, this can lead to inappropriate or confusing automated public replies, reducing trust and potentially disclosing that responses are mismatched or automated in multilingual repositories.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill describes automated GitHub Issue replies but does not clearly warn users that it will post public comments automatically on newly opened issues. This can cause unintended public disclosure, reputational harm, or spam-like behavior if enabled without explicit operator awareness, especially because GitHub issue comments are externally visible by default.

Static analysis

No suspicious patterns detected.