Consensus Publish Guard

• Outcome: Review
• Latest audit: Sep 11, 2026 · 12:56 AM UTC
• Version: 1.1.17

Overview

This publishing guard looks purpose-aligned and not malicious, but it needs review because its dependency/version posture is inaccurately documented and one mode can rely entirely on caller-supplied votes.

Review before installing in production. Pin dependencies exactly, reconcile package/SKILL/lockfile versions, update vulnerable transitive dependencies, and document or enforce that external_agent mode cannot bypass hard-block checks for sensitive or legally risky content. Run it with a scoped consensus state path because it intentionally writes persistent decision artifacts.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T08 · Insecure Dependencies

Warning

• Location: package.json:9
• Finding: Mutable Security-Critical Runtime Dependencies## Vulnerability Details **File Location**: `package.json`, lines 9–10 **Vulnerability Type**: Supply-chain risk caused by non-exact dependency constraints **Risk Level**: Medium ```json "dependencies": { "consensus-guard-core": "^1.1.15", "tsx": "^4.20.3" } ``` The documented dependency trust model also incorrectly claims exact pinning in `SKILL.md`, lines 67–68: ```markdown - `consensus-guard-core` is the first-party consensus package used in guard execution - versions are semver-pinned in `package.json` for reproducible installs ``` ### Technical Analysis The package manifest uses caret version ranges rather than exact versions. A caret permits npm to install newer semver-compatible releases. This is especially significant for `consensus-guard-core`, which supplies security-sensitive operations such as input validation, policy-flag detection, vote aggregation, state-path resolution, decision lookup, and artifact writing. The declared trust model states that versions are pinned for reproducible installation, but the manifest does not provide that guarantee. The existing lock file illustrates dependency drift: `package.json` permits `tsx` from version 4.20.3 onward within the compatible range, while `package-lock.json` resolves version 4.21.0. The project version is also inconsistent between `package.json` version 1.1.17 and `package-lock.json` version 1.1.16. Integrity hashes in the lock file protect installations that strictly honor that lock file, but they do not eliminate the risk when consumers install the published package without the repository lock file, regenerate the lock, or run installation workflows that update compatible dependencies. ### Attack Path 1. An attacker compromises the npm account, release process, or source repository of a direct or transitive dependency. 2. The attacker publishes a malicious release that remains compatible with the caret range. 3. A user installs the skill through a workflow that does not strictly prese ...[truncated 1148 chars]
• Remediation: ## Remediation Suggestions 1. Replace caret ranges with reviewed exact versions: ```json "dependencies": { "consensus-guard-core": "1.1.15", "tsx": "4.20.3" } ``` 2. Regenerate `package-lock.json` so its root package version and dependency resolutions match `package.json`. 3. Use `npm ci` rather than `npm install` in CI, deployment, and documented repository installation procedures. 4. Commit and protect the lock file, and fail builds when the manifest and lock file are inconsistent. 5. Review direct and transitive dependencies before upgrades, including package ownership, lifecycle scripts, provenance, and unexpected dependency changes. 6. Enable automated dependency scanning and lock-file integrity checks. 7. Run installation and execution under a minimally privileged, sandboxed account with restricted filesystem and network access. 8. Correct `SKILL.md` so its trust-model statement accurately reflects the implemented dependency policy.

SkillSpector

Vulnerability Patterns

• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (6)

Natural-Language Policy Violations

High

• Confidence: 99% confidence
• Finding: The draft body explicitly tells users to share confidential account numbers and pairs that with a certainty-style guarantee, which is unsafe and directly conflicts with the declared constraints. In a publishing-governance skill, unsafe sample content is especially risky because it can normalize, test, or accidentally propagate prohibited public messaging about sensitive data and legal certainty.

Ssd 3

High

• Confidence: 99% confidence
• Finding: The example content instructs disclosure of confidential account numbers even though the input constraints explicitly set no_sensitive_data=true, demonstrating a direct policy violation. Because this skill is meant to guard outbound publishing, including a contradictory example weakens trust in the control flow and could lead operators or downstream systems to accept dangerous content as valid input.

Known Vulnerable Dependency: fast-uri==3.1.0 — 7 advisory(ies): CVE-2026-13676 (fast-uri vulnerable to host confusion via failed IDN canonicalization); CVE-2026-18446 (fast-uri vulnerable to host confusion via backslash authority introducer); CVE-2026-75975 (fast-uri vulnerable to server-side request forgery via malformed IPv6 normalizat) +4 more

High

• Category: Supply Chain
• Confidence: 93% confidence
• Finding: The lockfile includes fast-uri 3.1.0, which is associated with multiple URI parsing and canonicalization issues including host confusion and potential SSRF bypasses. If any part of this skill or its dependencies uses fast-uri for security-relevant URL validation, allowlisting, or routing decisions, an attacker could bypass hostname restrictions and reach unintended resources.

Known Vulnerable Dependency: esbuild==0.27.3 — 1 advisory(ies): GHSA-g7r4-m6w7-qqqr (esbuild allows arbitrary file read when running the development server on Window)

Low

• Category: Supply Chain
• Confidence: 88% confidence
• Finding: The lockfile pins esbuild 0.27.3, and the cited advisory affects esbuild's development server on Windows by permitting arbitrary file reads under the vulnerable usage mode. This is a real supply-chain risk, but in this skill context it appears to be a transitive build/runtime tool dependency rather than evidence of malicious behavior, and the impact is limited unless the package actually starts the vulnerable dev server on Windows.

Unpinned Dependencies

Low

• Category: Supply Chain

Content

"demo": "node --import tsx run.js --input ./examples/input.json"
  },
  "dependencies": {
    "consensus-guard-core": "^1.1.15",
    "tsx": "^4.20.3"
  },
  "license": "MIT",

• Confidence: 93% confidence
• Finding: The dependency uses a caret range, which permits automatic installation of newer compatible versions rather than a single exact artifact. This can increase supply-chain risk because a compromised or breaking upstream release could be pulled into future installs, though this package.json alone does not indicate active exploitation or malicious behavior.

Unpinned Dependencies

Low

• Category: Supply Chain

Content

},
  "dependencies": {
    "consensus-guard-core": "^1.1.15",
    "tsx": "^4.20.3"
  },
  "license": "MIT",
  "engines": {

• Confidence: 93% confidence
• Finding: The tsx dependency is specified with a caret range, allowing version drift across installs. In the event of an upstream compromise or malicious publish, consumers could resolve a newer package than originally reviewed, creating a supply-chain exposure.

Static analysis

No suspicious patterns detected.