Back to skill

Security audit

teamwork

Security checks for vulnerabilities and agentic risk

Overview

The skill is a disclosed teamwork automation guide, but it gives agents broad unattended authority to modify files, reassign work, notify external services, and push repository-wide changes.

Install only in a repository where you are comfortable with agents making unattended workflow changes and pushing commits. Before use, remove or override the automatic git add -A/git push rule, require review before external notifications, and explicitly approve any cron scheduling, cleanup/archive operations, and audit-role reassignment authority.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • 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
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Findings (5)

T01 · Skill Instruction Hijacking

Error
Location
SKILL.md:91
Finding

Global Instructions Authorize Destructive Actions Outside Task Scope

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 91-97
Vulnerability Type: Global instruction hijacking and unauthorized file manipulation
Risk Level: High

Relevant Skill Text

The following is a faithful English translation of the relevant source excerpt:

text
All agents, teams, and sub-agents must comply:

1. Audit means cleanup: During every audit, statistics operation, or optimization,
   simultaneously clean expired, invalid, or disproven content and move it into
   the dedicated research archive. Do not accumulate garbage data.
2. Normalize deduplication: After new collection, deduplicate by filename and
   title, retain the newest duplicate, and archive older versions.
3. Archive error and temporary files: Temporary files must not remain in
   production directories and must be archived.
4. Archive research results: Move completed research results into the
   corresponding product archive.

Technical Analysis

The Skill declares that these rules apply to all agents, teams, and sub-agents, rather than limiting them to an explicitly assigned coordination task. It also changes the meaning of read-oriented operations such as auditing or collecting statistics by requiring those operations to move or clean files.

The criteria for deciding that content is expired, invalid, disproven, temporary, or duplicated are not defined. There is also no dry-run requirement, path allowlist, backup requirement, or human confirmation boundary. Consequently, loading this Skill can cause an agent performing an otherwise non-destructive audit to alter unrelated project data.

Attack Path

  1. An agent loads the Skill to perform an audit or statistics task.
  2. The global mandate is interpreted as applying to the agent and all accessible project content.
  3. The agent classifies files as old, duplicated, invalid, temporary, or disproven using unspecified criteria.
  4. The agent moves those fil ...[truncated 685 chars]
Remediation
View remediation

Remediation Suggestions

  • Replace the global mandate with rules explicitly scoped to the current assigned task and approved workspace.
  • Make audit and statistics operations read-only by default.
  • Require explicit human confirmation before deleting, moving, or archiving files.
  • Define objective retention and deduplication criteria.
  • Restrict file operations to an allowlisted directory supplied in the task.
  • Produce a dry-run manifest showing every proposed source and destination path.
  • Preserve recoverable backups and record an audit log for every approved modification.
  • Prohibit child agents from inheriting destructive authority unless the user expressly delegates it.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:51
Finding

Repository-Wide Staging Can Push Unrelated Sensitive Data to Gitee

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 51-54, 101-105, and 183-186
Vulnerability Type: Overbroad repository staging and automatic external transmission
Risk Level: High

Relevant Skill Text

The following is a faithful English translation of the relevant source excerpts:

sh
# After completion, write the result, set status to completed, and independently run:
git add -A && git commit -m "<agent name> <product>: <output summary>" && git push
text
Immediate push: Michael checks Gitee rather than local files.
Not pushed means not completed.
text
Verify that the sub-agent output has been staged, committed, and pushed with:
git add -A && git commit -m '<agent> <product>: <output>' && git push

Technical Analysis

git add -A stages all tracked modifications, deletions, and untracked files throughout the repository. It does not limit the commit to files produced by the current task. The mandatory git push then transmits the resulting commit to the configured remote repository.

The Skill provides no staged-diff review, task-output allowlist, secret scanning, remote validation, branch protection check, or human approval step. A sensitive or unrelated file already present in the working tree can therefore be included even when the agent never intentionally selected that file.

The behavior is particularly dangerous when combined with automated agents and cleanup instructions: unrelated local changes, credentials, generated artifacts, and destructive file moves can all be committed and pushed as part of an otherwise legitimate task.

Attack Path

  1. A credential, private document, unrelated source modification, or generated secret exists in the working tree.
  2. A sub-agent completes an unrelated assigned task.
  3. The sub-agent executes git add -A as required by the Skill.
  4. Git stag ...[truncated 789 chars]
Remediation
View remediation

Remediation Suggestions

  • Replace git add -A with explicit, task-specific path staging, such as git add -- path/to/expected-output.
  • Resolve and validate each staged path against an approved repository root.
  • Display and review git status --short and git diff --cached before committing.
  • Run secret and sensitive-data scanning against staged content.
  • Reject unexpected files, symbolic links, large binaries, credential formats, and changes outside the task allowlist.
  • Require explicit human approval before pushing.
  • Validate the remote URL, target repository, target branch, and authenticated identity.
  • Use a dedicated least-privilege branch or pull-request workflow instead of direct pushes.
  • Do not define task completion as dependent on an unconditional network push.

T06 · System Persistence

Error
Location
SKILL.md:113
Finding

Recurring Cron-Oriented Operation Creates Cross-Session Persistence

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 44-47 and 113-123
Vulnerability Type: Persistent scheduled agent execution
Risk Level: High

Relevant Skill Text

The following is a faithful English translation of the relevant source excerpts:

text
Trigger method: repeatedly triggered by cron or manually advanced by the
project owner.
text
Cron scheduling architecture:

side-research phase0 push:
  Main coordinator that processes pending tasks and dispatches sub-agents.
  Schedule: every five hours at 03:00, 08:00, 13:00, 18:00, and 23:00.

Team automatic advancement:
  Team broadcast once per day.

side_research_runner:
  Generate daily side-research collection reports every two hours.

audit_wind_daily.sh:
  Audit the entire vault at 03:00.

daily_pipeline_06.sh:
  Run the daily pipeline and push at 06:00.

daily_policy_fetch.sh:
  Fetch and interpret external policy information at 23:00.

Technical Analysis

The Skill explicitly defines repeated cron-driven execution across several workflows. This is not limited to the lifetime of a single user invocation. Once operationalized in an OpenClaw environment, the schedule can repeatedly scan task files, dispatch agents, modify local data, access external sources, send notifications, and push repository changes.

The file does not itself contain an installation command, so the audit does not claim that this package directly installs a cron entry. However, it instructs operators and agents to use persistent scheduled triggering and defines concrete schedules. No expiry, execution-count limit, user-presence check, global disable control, or per-run confirmation is specified.

Attack Path

  1. An operator or agent adopts the documented cron architecture.
  2. The coordinator is scheduled at the specified recurring times.
  3. A task is added to or altered in the coordination directory.
  4. A later unattended cr ...[truncated 732 chars]
Remediation
View remediation

Remediation Suggestions

  • Remove recurring scheduling from the default Skill behavior.
  • Require separate, explicit, informed user consent before creating or enabling any scheduled task.
  • Document the exact schedule, executable, identity, permissions, data access, and network destinations before activation.
  • Add an expiration time, maximum run count, and easily discoverable disable and removal procedure.
  • Run scheduled jobs under a dedicated least-privilege account.
  • Require per-run task validation and restrict operations to approved directories and remotes.
  • Prevent unattended pushes or external notifications unless separately authorized.
  • Log every invocation and expose its status to the user.

other

Warning
Location
SKILL.md:29
Finding

DingTalk Notifications Can Disclose Internal Task Metadata

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 29-36, 128-130, and 167-170
Vulnerability Type: External disclosure of project and task information
Risk Level: Medium

Relevant Skill Text

The following is a faithful English translation of the relevant source excerpts:

text
Each task file must contain an optional notify.dingtalk_id or notify.user_id
for notifying the responsible human of execution results.

Match the responsible person's dingtalk_id from team-directory.json using
the en or name field.

When a sub-agent completes or is blocked, the coordinator triggers a
DingTalk notification containing task_id, title, status, and output summary.
text
Notify Michael through DingTalk with a short status after each task completes.
text
Notification channel: dingtalk:<dingtalk_id>

Notification content: task_id, title, current status, required decision or
input, and deadline.

Do not expose keys or tokens in notifications.

Technical Analysis

The Skill directs the coordinator to transmit task identifiers, titles, states, output summaries, decision requests, and deadlines to DingTalk. The prohibition on sending keys or tokens is useful but insufficient because the listed metadata itself may contain confidential project names, research results, incident details, customer information, or operational deadlines.

Recipient selection depends on team-directory.json and matching by name or English-name fields. The Skill does not require recipient integrity validation, duplicate-name handling, confirmation of the selected account, payload redaction, task classification, or user consent before transmission. A stale, incorrect, or manipulated directory entry could redirect notifications to the wrong recipient.

Attack Path

  1. A task contains confidential information in its title, result summary, decision request, or deadline fields.
  2. The coordinator res ...[truncated 796 chars]
Remediation
View remediation

Remediation Suggestions

  • Make external notifications opt-in for each project or task.
  • Use stable, unique recipient identifiers rather than ambiguous name matching.
  • Protect team-directory.json with appropriate ownership and write permissions.
  • Confirm the resolved recipient before the first transmission and after directory changes.
  • Define a minimal notification schema that excludes output summaries and sensitive titles by default.
  • Classify and redact task data before transmission.
  • Require human approval for confidential or regulated projects.
  • Maintain an auditable record of destination, timestamp, and fields sent without logging secrets.
  • Permit local-only notification as the secure default.

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
SKILL.md:57
Finding

Audit Role Can Reassign Tasks and Alter Dependencies Without Authorization Checks

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 57-60 and 155-162
Vulnerability Type: Excessive audit-role privileges over task execution
Risk Level: Medium

Relevant Skill Text

The following is a faithful English translation of the relevant source excerpts:

text
Project audit scans the coordination task directory and identifies tasks
that have remained pending for a long time.

If the originally assigned agent cannot accept the task or has timed out,
the audit role has authority to modify assigned_to, adjust dependencies,
split the task, and redistribute it.

When an anomaly is found, notify a human, but do not execute the task in
place of the agent.
text
Project audit process:
1. Scan tasks and identify overdue pending tasks or reviews older than 24 hours.
2. Check audit records and result errors.
3. Adjust assigned_to, deadline, and dependencies.
4. Record the reason for a known blockage and notify a human.
5. Update updated_at and append an audit record.
6. Redistribute during the next cron or manual trigger.

Technical Analysis

A role described as an auditor is granted write authority over assignment, deadlines, dependencies, and task decomposition. These controls directly determine which agent receives a task and when it becomes executable. No authenticated approval, role-based access control, integrity protection, permitted-agent allowlist, or separation of duties is specified.

Changing dependencies can bypass intended ordering or safety prerequisites. Changing assigned_to can redirect a sensitive task to an agent with different capabilities, credentials, or trust boundaries. Because recurring coordination later dispatches modified tasks, an unauthorized coordination-file change can become actual execution.

Attack Path

  1. An auditor or process with access to the coordination directory identifies or creates an apparently overdue task.
  2. It mo ...[truncated 904 chars]
Remediation
View remediation

Remediation Suggestions

  • Make the audit role read-only by default.
  • Require explicit human approval for reassignment, dependency changes, deadline changes, and task splitting.
  • Enforce role-based access control on coordination files.
  • Restrict reassignment to an allowlist of agents authorized for the task’s data classification and required tools.
  • Prevent removal of mandatory safety or approval dependencies.
  • Require signed or integrity-protected task updates with actor identity and reason.
  • Separate the roles that propose, approve, and execute workflow changes.
  • Have the coordinator reject unauthorized or structurally invalid modifications before dispatch.
  • Preserve immutable audit history for all assignment and dependency changes.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
88% confidence
Finding

The skill permits recurring cron-based execution and manual triggering with broad task scanning and redistribution behavior, but it does not define strong invocation constraints, authorization checks, or narrow scope boundaries. In an agentic environment, this can cause unintended task pickup, repeated autonomous actions, and unsafe execution of repository operations based on loosely controlled files under .agent-coordination/.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

The skill explicitly directs agents to run git add, commit, and push automatically, causing local changes to be persisted and transmitted to a remote repository without any user-facing confirmation or review gate. This is dangerous because task files and generated outputs are treated as executable workflow input, so a malformed or adversarial task could induce exfiltration of sensitive data, publication of incorrect changes, or irreversible repository modification.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.