AuditClaw Github

• Outcome: Review
• Latest audit: Sep 10, 2026 · 7:51 PM UTC
• Version: 1.0.2

Overview

This skill is mostly a legitimate GitHub compliance checker, but it should be reviewed because its token guidance and token handling can overgrant or expose GitHub access.

Install only after reviewing the GitHub credential setup. Prefer a short-lived fine-grained PAT restricted to the specific organization and repositories being audited, avoid the classic repo scope, and do not pass tokens with --token. Expect GitHub security metadata and check results to be written into ~/.openclaw/grc/compliance.sqlite.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: scripts/github-permissions.json:24
• Finding: Overprivileged GitHub Token Guidance Violates the Read-Only Security Model## Vulnerability Details **File Location**: `SKILL.md:19-21`, `SKILL.md:55`, and `scripts/github-permissions.json:15-16,24-25` **Vulnerability Type**: Excessive GitHub token permissions **Risk Level**: Medium ### Vulnerable Code and Configuration `SKILL.md:19-21`: ```markdown ## Prerequisites - GitHub personal access token with read-only permissions (or classic token with `repo`, `read:org`, `security_events`) - Set as `GITHUB_TOKEN` environment variable ``` `SKILL.md:55`: ```markdown **Classic token alternative:** If fine-grained tokens unavailable, use scopes: `repo`, `read:org`, `security_events` ``` `scripts/github-permissions.json:15-16`: ```json "code_scanning_alerts": {"access": "read", "reason": "Code scanning (CodeQL) results"}, "actions": {"access": "read", "reason": "GitHub Actions workflow permissions and security"}, ``` `scripts/github-permissions.json:24-25`: ```json "classic_token_scopes": ["repo", "read:org", "security_events"], "classic_token_note": "If fine-grained tokens are not available, use a classic token with these 3 scopes" ``` ### Technical Analysis The Skill declares a read-only security model, but its fallback setup instructions recommend a classic personal access token with the broad `repo` scope. A classic token carrying this scope is not constrained to the read-only API operations used by the Skill and can provide extensive access to private repositories, including modification capabilities. The fine-grained permission manifest also requests Code Scanning Alerts and Actions permissions that are not exercised by the reviewed implementation. The CI/CD check reads workflow files through the repository Contents API, while no module retrieves CodeQL alerts or calls GitHub Actions APIs. Recommending unused or write-capable permissions violates least privilege. Although the audited code only performs read operations, the credential itself remains usable outside the Skill ...[truncated 1161 chars]
• Remediation: ## Remediation Suggestions 1. Remove the classic `repo` PAT recommendation or clearly state that it does not provide a read-only security boundary. 2. Require fine-grained PATs restricted to the specific organization and repositories being audited. 3. Grant only the permissions required by the checks the user enables. 4. Remove Code Scanning Alerts permission until the implementation actually performs a CodeQL or code-scanning check. 5. Remove Actions permission unless an Actions-specific API is introduced; workflow-file inspection currently uses Contents access. 6. Separate checks into permission profiles so high-sensitivity checks such as audit-log and 2FA inspection do not force every user to grant organization-administration access. 7. Keep tokens short-lived, rotate them regularly, and document immediate revocation procedures. 8. Prefer a GitHub App with explicitly selected read-only permissions where operationally feasible.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/github_evidence.py:261
• Finding: GitHub Token Can Be Exposed Through Command-Line Arguments## Vulnerability Details **File Location**: `scripts/github_evidence.py:261-286` **Vulnerability Type**: Sensitive credential exposure through process arguments and shell history **Risk Level**: Medium ### Vulnerable Code ```python parser.add_argument("--token", help="GitHub token (or set GITHUB_TOKEN env var)") parser.add_argument("--list-checks", action="store_true", help="List available checks") parser.add_argument("--test-connection", action="store_true", help="Test GitHub connectivity") args = parser.parse_args() if args.list_checks: print(json.dumps({"checks": list(ALL_CHECKS.keys())})) return if args.test_connection: test_connection(token=args.token) return if not args.org: parser.error("--org is required (unless using --list-checks or --test-connection)") if args.all: check_names = list(ALL_CHECKS.keys()) elif args.checks: check_names = [c.strip() for c in args.checks.split(",")] else: parser.error("Specify --all or --checks <list>") return run_sweep(args.db_path, args.org, check_names, token=args.token) ``` ### Technical Analysis The program accepts a GitHub PAT as the literal value of `--token`. Command-line arguments are commonly visible in shell history, process-monitoring tools, job-runner metadata, audit logs, crash diagnostics, and process listings available to other users or services on the same host. The token is subsequently used for authenticated GitHub API traffic. That network transmission is necessary for the declared functionality and no unrelated exfiltration endpoint was identified. The vulnerability is the additional argv-based credential ingestion mechanism, not authentication to GitHub itself. Environment-based token loading is already implemented, making the command-line option unnecessary for normal operation. ### Attack Path 1. A user runs a command such as: ```bash python3 scripts/github_evidence.py --t ...[truncated 1006 chars]
• Remediation: ## Remediation Suggestions 1. Remove the `--token` argument and accept credentials only through `GITHUB_TOKEN` or a protected credential provider. 2. For interactive use, support a non-echoing prompt through `getpass.getpass()` rather than accepting a literal argument. 3. For automated environments, integrate with a secret manager and pass credentials through protected environment injection or a restricted file descriptor. 4. Never print, log, or include token values in exception messages. 5. Document that users must not place PATs directly in shell commands, scripts, or CI job arguments. 6. Rotate any token that has previously been supplied through `--token`, especially if shell history or centralized process telemetry may have retained it. 7. Combine this correction with least-privilege, short-lived GitHub credentials to reduce the impact of any future disclosure.

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence
• Behavioral AST: exec() Call, eval() Call, Dynamic Import
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration

Findings (16)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 92% confidence
• Finding: The core purpose mostly aligns with GitHub compliance checking, but the declared description presents the skill as doing 9 read-only checks with no declared permissions. The supplied code does more than passive read-only checking: it persists evidence to a local compliance database, updates integration tracking state, and can call a helper script to mutate database contents. It also supports a separate test-connection mode that probes authenticated access to organizations, repositories, and rate limits. These are material undeclared capabilities and involve write access to local resources, so the description does not fully and accurately represent the code's behavior.

Credential Access

High

• Category: Privilege Escalation

Content

**9 checks | Read-only token permissions | Evidence stored in shared GRC database**

## Security Model
- **Read-only access**: Uses fine-grained personal access token with read-only repository and organization permissions. No write access.
- **Credentials**: Uses `GITHUB_TOKEN` env var. No credentials stored by this skill.
- **Dependencies**: `PyGithub==2.8.1` (pinned)
- **Data flow**: Check results stored as evidence in `~/.openclaw/grc/compliance.sqlite` via auditclaw-grc

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

**9 checks | Read-only token permissions | Evidence stored in shared GRC database**

## Security Model
- **Read-only access**: Uses fine-grained personal access token with read-only repository and organization permissions. No write access.
- **Credentials**: Uses `GITHUB_TOKEN` env var. No credentials stored by this skill.
- **Dependencies**: `PyGithub==2.8.1` (pinned)
- **Data flow**: Check results stored as evidence in `~/.openclaw/grc/compliance.sqlite` via auditclaw-grc

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

**9 checks | Read-only token permissions | Evidence stored in shared GRC database**

## Security Model
- **Read-only access**: Uses fine-grained personal access token with read-only repository and organization permissions. No write access.
- **Credentials**: Uses `GITHUB_TOKEN` env var. No credentials stored by this skill.
- **Dependencies**: `PyGithub==2.8.1` (pinned)
- **Data flow**: Check results stored as evidence in `~/.openclaw/grc/compliance.sqlite` via auditclaw-grc

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

When a user asks to set up GitHub integration, guide them through these steps:

### Step 1: Create Fine-Grained Personal Access Token
Direct user to: GitHub → Settings → Developer Settings → Personal Access Tokens → Fine-grained tokens

### Step 2: Configure Token Permissions

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

When a user asks to set up GitHub integration, guide them through these steps:

### Step 1: Create Fine-Grained Personal Access Token
Direct user to: GitHub → Settings → Developer Settings → Personal Access Tokens → Fine-grained tokens

### Step 2: Configure Token Permissions
- Name: `auditclaw-grc`

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

When a user asks to set up GitHub integration, guide them through these steps:

### Step 1: Create Fine-Grained Personal Access Token
Direct user to: GitHub → Settings → Developer Settings → Personal Access Tokens → Fine-grained tokens

### Step 2: Configure Token Permissions
- Name: `auditclaw-grc`

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: The skill description frames the capability as read-only GitHub checks, but this code writes evidence and integration status into a local compliance database. That mismatch can undermine operator trust and lead to unintended persistence of collected repository or organization metadata, which is especially relevant in agent/skill ecosystems where users rely on manifest-declared side effects.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The markdown states that the skill runs automated GitHub security checks and stores evidence in a shared compliance database, which affects user or organizational data handling. The description does not include any warning about what data will be collected, persisted, or the implications of writing audit evidence to shared storage.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 89% confidence
• Finding: The skill declares executable behavior that uses environment variables and shell commands, but it does not define an explicit tool scope such as allowed-tools or permissions. That creates an avoidable trust gap: consumers cannot easily constrain what the skill may invoke, increasing the risk of unintended command execution or environment access if the implementation changes or is abused.

Session Persistence

Medium

• Category: Rogue Agent

Content

**9 checks | Read-only token permissions | Evidence stored in shared GRC database**

## Security Model
- **Read-only access**: Uses fine-grained personal access token with read-only repository and organization permissions. No write access.
- **Credentials**: Uses `GITHUB_TOKEN` env var. No credentials stored by this skill.
- **Dependencies**: `PyGithub==2.8.1` (pinned)
- **Data flow**: Check results stored as evidence in `~/.openclaw/grc/compliance.sqlite` via auditclaw-grc

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Intent-Code Divergence

Medium

• Confidence: 98% confidence
• Finding: The check unconditionally reports force-push protection as passing based solely on branch protection being enabled, but it never verifies the actual force-push setting. This can produce false compliance evidence, causing administrators or auditors to believe a protected branch blocks force pushes when the repository configuration may still allow them.

Description-Behavior Mismatch

Medium

• Confidence: 87% confidence
• Finding: The top-level docstring explicitly states that the orchestrator 'stores results as evidence in the GRC database.' This is a meaningful behavior not reflected in the manifest's narrower description of GitHub compliance evidence collection via read-only checks, creating a semantic mismatch between declared scope and actual implementation.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: Check results are serialized and stored as evidence without any explicit user warning at execution time that repository or organization metadata will be persisted locally. In compliance contexts, this can capture sensitive internal configuration state and create retention/privacy issues if operators believed the tool was only performing transient read-only checks.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

"--description", f"GitHub {check_name} check: {result['passed']}/{result['total']} passed",
            "--file-content", json.dumps(result, default=str),
        ]
        proc = subprocess.run(cmd, capture_output=True, text=True)
        if proc.returncode == 0:
            return {"status": "stored", "method": "db_query"}

• Confidence: 70% confidence
• Finding: subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Context-Inappropriate Capability

Low

• Confidence: 76% confidence
• Finding: The `test_connection` routine enumerates organizations, repositories, and rate limit details to assess token access. While operationally useful, this capability is ancillary to the stated purpose of performing the nine compliance checks and collecting evidence, and it exposes additional account-access inspection behavior not described in the manifest.