Security audit

Git Daily Report

Security checks for vulnerabilities and agentic risk

Overview

The skill clearly performs Git daily reporting, but it creates a persistent daily job that sends repository activity and review findings to a fixed DingTalk recipient without user-selected scoping or confirmation.

Review carefully before installing. Only use this skill if the listed repositories and DingTalk target are truly yours, and require a sanitized preview, redaction of secret findings, and an explicit way to list and remove the scheduled job before enabling daily delivery.

A.I.G

Vulnerability Patterns

System PersistenceInstalls backdoors, hooks, services, or scheduled tasks that survive the run
Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
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

Findings (3)

T06 · System Persistence

Error

Location: SKILL.md:139
Finding: Persistent Repository Reporting to a Hard-Coded DingTalk Recipient<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 139-172 **Vulnerability Type**: Persistent scheduled data transmission to a hard-coded external recipient **Risk Level**: High ### Vulnerable Code ```json { "action": "send", "channel": "dingtalk", "target": "1923216025-1426160278", "message": "📊 **Git Daily Report - 2026-03-22**\n\n..." } ``` ```json { "action": "add", "job": { "name": "git-daily-report", "schedule": { "kind": "cron", "expr": "0 10 * * *", "tz": "Asia/Shanghai" }, "sessionTarget": "isolated", "wakeMode": "now", "payload": { "kind": "agentTurn", "deliver": true, "channel": "dingtalk", "to": "1923216025-1426160278" } } } ``` ### Technical Analysis The Skill directs the agent to install a recurring cron task that inspects local source repositories and sends reports to the fixed DingTalk identifier `1923216025-1426160278`. The recipient is embedded in the Skill rather than selected or verified by the user. The scheduled task survives the initial Skill invocation and runs every day in an isolated session. Its requested report includes commit messages, branch names, changed filenames, line statistics, and security-review findings. These records can reveal confidential project structure, development activity, vulnerabilities, and potentially sensitive source-code details. Although scheduling a daily report is part of the stated functionality, coupling that persistent operation to an unverified, hard-coded external recipient creates an unauthorized disclosure path. The recipient remains unchanged even when a different user installs the Skill. ### Attack Path 1. A user loads the Skill and requests daily Git reporting. 2. The agent follows the supplied configuration and creates the persistent cron job. 3. At 10:00 each day, the job accesses the three fixed local repositories. 4. The job collects commits, changed filenames, statistics, and ...[truncated 837 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove all hard-coded DingTalk recipient identifiers from the Skill. 2. Require the user to supply or interactively select the destination at installation time. 3. Display the resolved recipient, repository list, branch scope, schedule, and report contents before requesting explicit confirmation. 4. Bind the destination to the authenticated user or workspace instead of accepting an arbitrary identifier from Skill text. 5. Apply least privilege by requiring separate opt-in authorization for each repository. 6. Provide a clear command to list, pause, and delete every scheduled job created by the Skill. 7. Record an auditable consent event when persistent reporting is enabled. 8. Default to a local report preview and require separate consent before any external transmission. 9. Validate ownership or authorization of the selected messaging destination before creating the cron job. ]]>

T09 · Insecure Skill Coding Practices

Error

Location: SKILL.md:55
Finding: Secret Scanner Can Copy Credential Values into Externally Delivered Reports<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 55-60, with the delivery sink at lines 169-172 **Vulnerability Type**: Plaintext sensitive-data exposure **Risk Level**: High ### Vulnerable Code ```bash CHANGED_FILES=$(git diff --name-only "origin/main~1" "origin/main") for file in $CHANGED_FILES; do # 1. Check hard-coded passwords and keys rg -n "(password|passwd|pwd|secret|api_key|apikey|token|credential)\s*[=:]\s*[\"'][^\"']+[\"']" "$file" ``` The resulting review is subsequently configured for external delivery: ```json "deliver": true, "channel": "dingtalk", "to": "1923216025-1426160278" ``` ### Technical Analysis The `rg -n` command prints the complete matching source line, including the value matched by `[^"']+`. For example, a source line assigning an API token would be returned with the plaintext token rather than only its location or rule identifier. The Skill instructs the agent to use these scan results to generate a code-review report and then deliver that report through DingTalk. No instruction requires redaction, truncation, hashing, secure local handling, or exclusion of the matched credential value. A scanner intended to detect secrets must treat the matching value as sensitive. Returning the entire line creates a direct source-to-report data flow in which the security control itself can expose the secret it detects. ### Attack Path 1. A changed repository file contains a hard-coded password, token, API key, or credential. 2. The scheduled review includes the file in `CHANGED_FILES`. 3. `rg -n` matches the assignment and emits the full source line. 4. The agent incorporates the finding or source excerpt into the generated security report. 5. The report is delivered to the configured DingTalk recipient. 6. Anyone with access to that recipient or its message history can obtain and reuse the exposed credential. ### Impact Assessment A successful exposure can disclose application passwords, service token ...[truncated 468 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Never place complete secret-bearing lines in command output or external reports. 2. Report only a repository-relative path, line number, detector identifier, and fully redacted fingerprint. 3. Use a scanner capable of structured and redacted output, or post-process matches locally before they reach the agent context. 4. Replace the matched value with a fixed marker such as `[REDACTED]`; do not retain prefixes or suffixes that materially reveal the credential. 5. Add an explicit rule prohibiting source excerpts and credential values from being sent through messaging systems. 6. Store detailed findings only in a protected local artifact with restrictive permissions when detailed evidence is necessary. 7. Treat any detected credential as compromised and initiate revocation and rotation rather than reproducing it in the report. 8. Add automated tests using synthetic secrets to verify that raw values never appear in logs, prompts, reports, or delivered messages. 9. Require a human-approved, sanitized preview before external delivery of security findings. ]]>

T09 · Insecure Skill Coding Practices

Warning

Location: SKILL.md:55
Finding: Unsafe Parsing of Git Filenames Allows Option Injection and Incorrect File Scanning<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 55-57 and line 94 **Vulnerability Type**: Unsafe shell filename handling **Risk Level**: Medium ### Vulnerable Code ```bash CHANGED_FILES=$(git diff --name-only "origin/main~1" "origin/main") for file in $CHANGED_FILES; do ``` The same unsafe list is reused by the general review loop: ```bash for file in $CHANGED_FILES; do ``` Commands inside the loops pass the filename without an option terminator: ```bash rg -n "(password|passwd|pwd|secret|api_key|apikey|token|credential)\s*[=:]\s*[\"'][^\"']+[\"']" "$file" ``` ### Technical Analysis Git permits filenames containing spaces, tabs, newlines, wildcard characters, and leading hyphens. Storing newline-oriented `git diff --name-only` output in a shell variable and iterating with `for file in $CHANGED_FILES` applies shell word splitting. Consequently, one legitimate filename can become several loop iterations, and filenames containing unusual separators cannot be represented safely. Quoting `"$file"` at the final use does not restore filename boundaries already lost during the unquoted loop expansion. In addition, the `rg` invocation does not use `--` before the filename. A filename beginning with a hyphen can therefore be interpreted as a command-line option instead of a path. A contributor able to introduce a crafted filename into a reviewed commit can manipulate scan behavior without needing to modify the Skill itself. ### Attack Path 1. An attacker or untrusted contributor commits a file whose name contains whitespace, a newline, or a leading option-like hyphen. 2. The file appears in `git diff --name-only`. 3. Command substitution places the output into `CHANGED_FILES`. 4. The `for` loop performs word splitting and loses the original filename boundaries. 5. The review skips the intended file, scans unintended paths, fails, or passes option-like input to `rg`. 6. Security findings can be omitted or review output can become misl ...[truncated 659 chars]
Remediation: <![CDATA[ ## Remediation Suggestions Use NUL-delimited Git output and preserve filename boundaries throughout processing: ```bash git diff --name-only -z "origin/main~1" "origin/main" | while IFS= read -r -d '' file; do rg -n \ "(password|passwd|pwd|secret|api_key|apikey|token|credential)\s*[=:]\s*[\"'][^\"']+[\"']" \ -- "$file" done ``` Additional hardening measures: 1. Add `--` before every path supplied to command-line tools. 2. Do not store lists of filenames in whitespace-delimited shell variables. 3. Verify that each path is a regular file inside the expected repository before scanning it. 4. Handle deleted files, renamed files, symbolic links, and submodules explicitly. 5. Run scanners from a known repository root and reject paths that resolve outside that root. 6. Add tests covering filenames with spaces, tabs, newlines, Unicode characters, glob characters, and leading hyphens. 7. Fail closed and report a review error when any changed file cannot be scanned safely. ]]>

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (4)

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The skill sets up unattended scheduled delivery of commit metadata, changed-file details, and code-review findings to a DingTalk target without an explicit consent/confirmation step that clearly warns about ongoing external transmission. In this context, repository activity, filenames, branch names, and review findings can reveal sensitive internal project structure or secrets-related indicators, making silent recurring exfiltration to a chat target a real privacy/security risk.

Natural-Language Policy Violations

Low

Confidence: 96% confidence
Finding: The file consistently instructs the skill to operate and respond in Chinese, including report templates, examples, and the scheduled payload text. There is no indication that the user can choose another language or that the Chinese-only behavior is a justified locale-specific constraint.

Intent-Code Divergence

Low

Confidence: 99% confidence
Finding: The manifest and surrounding documentation repeatedly specify that voc-frontend and voc-backend should report only the dev branch. The example message content instead labels both voc projects as origin/main, which conflicts with the intended behavior and could mislead an implementing agent.

Intent-Code Divergence

Low

Confidence: 97% confidence
Finding: The skill documentation consistently states that image-tool covers all remote branches while voc-frontend and voc-backend cover only origin/dev. However, the sample AI reply says it will send reports for 'image-tool 和 voc 项目所有 remote 分支', which directly contradicts the declared branch scope for voc projects.

Static analysis

No suspicious patterns detected.