Back to skill

Security audit

DIBP Topic 聚类

Security checks for vulnerabilities and agentic risk

Overview

The skill is a disclosed manual clustering workflow with some supply-chain and dependency-workaround risks, but no hidden execution, persistence, or exfiltration behavior in the artifact.

Before installing, be comfortable that this skill can guide an agent to run clustering scripts, update local cluster outputs, and, with your explicit approval, overwrite shared backend cluster data for a chosen date. Pin or verify the model source where possible, and do not accept an unreviewed sharp stub from chat or an unknown source.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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 (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:20
Finding
Unverified model retrieval through a third-party mirror## Vulnerability Details **File Location**: `SKILL.md`, line 20 **Vulnerability Type**: Supply-chain exposure through an unverified external model source **Risk Level**: Medium ### Vulnerable Documentation Snippet The following is an English translation of the complete relevant instruction, preserving all technical identifiers: ```text The semantic steps initially download Xenova/bge-small-zh-v1.5 and require access to https://hf-mirror.com. The standard huggingface.co endpoint is unavailable in this environment. scripts/cluster-99-run-pipeline.mjs automatically injects HF_ENDPOINT when it is not already set. ``` ### Technical Analysis The Skill directs the pipeline to retrieve the `Xenova/bge-small-zh-v1.5` model through `https://hf-mirror.com`, a mirror rather than the standard upstream service. It also states that `scripts/cluster-99-run-pipeline.mjs` automatically injects the `HF_ENDPOINT` configuration. No requirement is specified to pin an immutable model revision or verify the downloaded files using cryptographic hashes or signatures. Consequently, the effective model artifacts and associated metadata can change after the Skill has been reviewed. Trust is placed in the current content delivered by the mirror and the integrity of the network retrieval process. This is a supply-chain risk rather than proof that the current mirror content is malicious. Exploitation requires compromise of the mirror, its distribution infrastructure, or the artifact publication process. Depending on the model loader and artifact format, substituted content could manipulate clustering results or attempt to exploit a vulnerability in the component parsing the downloaded files. ### Attack Path 1. An attacker compromises the mirror, its artifact storage, or the publication path for `Xenova/bge-small-zh-v1.5`. 2. The attacker replaces a model or associated file while retaining identifiers expected by the pipeline. 3. A user invokes `pn ...[truncated 1081 chars]
Remediation
## Remediation Suggestions 1. Pin `Xenova/bge-small-zh-v1.5` to an immutable, reviewed revision rather than relying only on a mutable model name. 2. Record cryptographic hashes for every required model artifact and verify them before loading. 3. Prefer an organization-approved registry or an internally controlled artifact repository. 4. Do not silently inject an alternate model endpoint. Require explicit configuration or clearly display the selected source before downloading. 5. Cache verified artifacts in a read-only location and prevent automatic replacement without review. 6. Run model retrieval and parsing with restricted filesystem and network permissions. 7. Maintain an inventory of downloaded model files, versions, hashes, and provenance so changes can be audited.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:21
Finding
Manual modification of installed dependency code bypasses package integrity## Vulnerability Details **File Location**: `SKILL.md`, line 21 **Vulnerability Type**: Unreviewed modification of an installed dependency entry point **Risk Level**: Medium ### Vulnerable Documentation Snippet The following is an English translation of the complete relevant instruction, preserving all technical identifiers: ```text The local Node.js runtime is embedded in Electron and has an incompatible ABI. The sharp transitive dependency of @xenova/transformers cannot install its native binary. If a semantic step reports a sharp-related error, manually stub node_modules/.../sharp/lib/index.js to bypass it. This must be repeated after every pnpm install. ``` ### Technical Analysis The Skill instructs the operator to modify `node_modules/.../sharp/lib/index.js` manually. This file is an executable JavaScript entry point loaded by the dependency graph. Direct modification bypasses package-manager integrity controls and makes the installed dependency tree differ from the reviewed lockfile and published package. The required stub is not supplied as a version-controlled, reviewable patch. Its exact source, contents, expected hash, and permitted behavior are therefore undefined. Repeating this procedure after every `pnpm install` further encourages an informal and non-reproducible modification process. JavaScript placed in the modified entry point executes when the affected dependency is loaded. A malicious or incorrectly sourced stub could therefore execute arbitrary JavaScript with the permissions of the pipeline process. Even a non-malicious but incomplete stub could silently disable image-processing behavior, change module exports, or cause misleading clustering results. ### Attack Path 1. The semantic pipeline fails because the installed `sharp` native binary is incompatible with the Electron-embedded Node.js ABI. 2. Following the Skill, the operator obtains or writes an unspecified replacement for `node_modules/. ...[truncated 1188 chars]
Remediation
## Remediation Suggestions 1. Do not instruct users to edit files directly under `node_modules`. 2. Replace the workaround with a reviewed, version-controlled patch using the package manager's supported patch mechanism. 3. Include the complete patch in the repository and require code review for changes. 4. Pin the affected package versions and verify the patch against expected source hashes. 5. Add an automated integrity check that fails if the installed module differs from the approved package and patch. 6. Prefer a compatible Node.js runtime or supported `sharp` build so the stub is unnecessary. 7. If image-processing behavior is not required, configure or replace the dependency through an officially supported interface rather than overriding its entry point. 8. Execute the clustering process with least privilege and without unrelated credentials in its environment.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • 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

Static analysis

No suspicious patterns detected.