Back to skill

Security audit

slideshow

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly a coherent slideshow-authoring helper, but it asks users to run mutable unpinned HyperFrames commands that can update the reviewed skill and pull live catalog code into projects.

Install only if you are comfortable reviewing and approving HyperFrames CLI actions. Prefer a pinned local HyperFrames version, review any skill update before accepting it, inspect catalog components before adding them to a deck, avoid putting sensitive presenter notes on shared machines unless you can clear localStorage, and vendor optional third-party browser modules for public or sensitive presentations.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • 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
Findings (3)

T08 · Insecure Dependencies

Error
Location
SKILL.md:12
Finding
Unpinned HyperFrames Package Execution and Mutable Catalog Dependencies## Vulnerability Details **File Location**: `SKILL.md:12`, `SKILL.md:167`, `SKILL.md:489-518` **Vulnerability Type**: Unpinned third-party package execution and mutable supply-chain content **Risk Level**: High ### Vulnerable Code ```text > **First, keep this skill fresh — confirm with the user before running:** `npx hyperframes skills update slideshow`. A fast no-op when everything is current; otherwise it refreshes this skill plus the core domain skills it depends on before you rely on them. ``` ```text - **Search the live catalog before hand-building any named visual.** For every look, effect, chart, treatment or transition a slide needs — "CRT scanlines", "glitch", "bar chart race", "shimmer sweep", "terminal window" — run `npx hyperframes catalog --query "<the visual, in plain English>" --json` and read the top results before you author the slide's clips. The search needs **nothing installed**: no project, no prior `add`, no account. It ranks the whole hosted registry (~400 blocks and components) from any directory. `npx hyperframes add <name>` drops the block's source into the deck, where you customize it in place. ``` ```bash npx hyperframes present <project-dir> npx hyperframes lint npx hyperframes check ``` ### Technical Analysis The Skill repeatedly invokes `npx hyperframes` without specifying an audited package version, lockfile, package digest, or requirement to use an already-installed binary. Depending on the local npm configuration and package availability, `npx` can resolve and execute package code obtained from the configured registry. The mandatory update instruction is particularly sensitive because it asks the Agent to replace the currently reviewed Skill and related domain Skills before relying on them. Consequently, the effective instructions and executable dependency content can differ from the content that underwent this audit. The catalog workflow also retrieves mutable host ...[truncated 1835 chars]
Remediation
## Remediation Suggestions 1. Pin `hyperframes` to a reviewed exact version, for example through a locked project dependency rather than an unqualified `npx` resolution. 2. Use `npx --no-install hyperframes ...` or invoke a verified local binary so the command fails rather than downloading an unexpected package. 3. Commit and enforce an npm lockfile with integrity hashes. 4. Verify package provenance, signatures, and registry integrity before installation or execution. 5. Do not automatically update the Skill before use. Present the proposed version and changes for review, then require explicit approval before replacement. 6. Pin catalog components to immutable versions or content hashes. 7. Review downloaded catalog source before incorporating it into a deliverable. 8. Run package and catalog operations in a sandbox with restricted filesystem access, minimal environment variables, and constrained network access. 9. Separate validation from mutation: lint and check commands should not update Skills, install dependencies, or alter unrelated project files.

T03 · Remote Payload Retrieval and Execution

Warning
Location
references/standalone-harness.md:898
Finding
Executable Three.js Module Loaded from a Third-Party CDN Without Integrity Verification## Vulnerability Details **File Location**: `references/standalone-harness.md:898` **Vulnerability Type**: Runtime retrieval and execution of externally hosted JavaScript **Risk Level**: Medium ### Vulnerable Code ```js import * as THREE from "https://cdn.jsdelivr.net/npm/three@0.160.0/build/three.module.js"; ``` ### Technical Analysis The standalone harness recommends importing an executable JavaScript module directly from a third-party CDN at runtime. Although the package version is fixed to `0.160.0`, the browser does not verify the response against an independently maintained expected digest. A versioned URL limits ordinary version drift but does not protect against compromise of the CDN, package source, account, DNS path, or serving infrastructure. If the response changes after the Skill is reviewed, the browser will execute the changed payload in the slideshow's JavaScript context. Native module imports do not provide a standard `integrity` attribute equivalent to a conventional module script element in this example. The safest approach is therefore to vendor the reviewed module locally and protect the deployment with immutable build artifacts. The runtime CDN dependency is optional and is not required for the core slideshow functionality. It therefore exceeds the minimum network privilege necessary for a standalone deck. ### Attack Path 1. An attacker compromises the upstream package, CDN account, CDN infrastructure, DNS resolution, or another part of the module-delivery chain. 2. The attacker causes the versioned URL to return modified JavaScript. 3. A user opens a slideshow generated from the documented harness. 4. The browser retrieves and executes the modified module. 5. The attacker-controlled module runs in the deck's origin and can interact with same-origin page state and APIs. ### Impact Assessment The malicious module would execute with the browser privileges granted to the slideshow origin. Depe ...[truncated 545 chars]
Remediation
## Remediation Suggestions 1. Download and audit the required Three.js release during a controlled build process. 2. Store the reviewed module in the project and import it through a relative local URL. 3. Record and verify a cryptographic digest of the vendored artifact. 4. Pin the dependency in a lockfile and use immutable release artifacts. 5. Apply a restrictive Content Security Policy, especially `script-src`, `connect-src`, and related directives. 6. Prohibit arbitrary remote module imports in generated decks. 7. If CDN delivery is unavoidable, use a deployment approach that supports integrity verification and fail closed when verification fails. 8. Document the external dependency and obtain explicit user approval before enabling optional network-loaded visual effects.

T09 · Insecure Skill Coding Practices

Note
Location
references/standalone-harness.md:699
Finding
Unauthenticated Cross-Window Messaging Permits Message Injection## Vulnerability Details **File Location**: `references/standalone-harness.md:699-708`, `references/standalone-harness.md:795`, `references/standalone-harness.md:865-875` **Vulnerability Type**: Wildcard `postMessage` destinations and missing sender validation **Risk Level**: Low ### Vulnerable Code ```js parent.postMessage( { source: "hf-preview", type: "timeline", durationInFrames: totalFrames, scenes: scenes, }, "*", ); ``` ```js function playSfx(name) { try { parent.postMessage({ type: "hf-sfx", name: name }, "*"); } catch (e) {} } ``` ```js window.addEventListener("message", function (e) { var d = e.data; if (!d || d.type !== "hf-sfx") return; // Gate on mute state — the component owns this. if (muted) return; var el = clips[d.name]; if (!el || !unlocked) return; try { el.currentTime = 0; el.play().catch(function () {}); } catch (err) {} }); ``` ### Technical Analysis The child frame sends timeline and SFX messages with `"*"` as the target origin. The parent SFX receiver accepts messages based only on the attacker-controllable `data.type` value and does not verify either: - `e.origin` against the expected composition origin; or - `e.source` against the expected iframe's `contentWindow`. The SFX name is constrained by lookup in the predefined `clips` object, and playback requires the wrapper to have been unlocked by a user gesture. These constraints limit the immediate impact, but they do not establish a valid cross-frame trust boundary. The timeline payload contains scene identifiers and timing metadata rather than credentials or presenter notes. Likewise, the SFX payload contains only a cue name. Therefore, the static pre-scan warning about sensitive information being sent over the network is not confirmed by the reviewed code. `postMessage` is cross-window browser messaging, not inherently an Internet transmiss ...[truncated 1667 chars]
Remediation
## Remediation Suggestions 1. Replace wildcard target origins with the exact expected parent origin: ```js parent.postMessage(message, expectedParentOrigin); ``` 2. Retain a reference to the expected iframe and validate both origin and source: ```js window.addEventListener("message", function (e) { if (e.origin !== expectedCompositionOrigin) return; if (e.source !== expectedFrame.contentWindow) return; // Validate and process the message. }); ``` 3. Define strict schemas for every message type, including allowed properties, primitive types, ranges, and enumerated SFX names. 4. Reject unknown properties and message types. 5. Avoid using URL query parameters or other attacker-controlled strings as trusted origin values without validation. 6. Where feasible, establish a per-instance random channel identifier during trusted initialization and require it on subsequent messages. 7. Keep presenter notes, credentials, tokens, and other sensitive content out of cross-frame and `BroadcastChannel` payloads. 8. Add tests proving that messages from an unexpected origin or window are rejected.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • 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
Findings (1)

Missing User Warnings

Low
Confidence
82% confidence
Finding
Presenter notes are stored in browser localStorage, which can persist sensitive internal talking points, customer names, or unreleased product details on shared or managed machines. While this is same-origin storage and not directly exposed cross-site, users may be unaware that edits remain on disk beyond the current session.

Static analysis

No suspicious patterns detected.