Security audit

Vvvv Node Libraries

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly coherent guidance for vvvv gamma library development, but its publishing template could expose a NuGet publishing secret through mutable GitHub Actions references.

Install only if you are working on vvvv gamma node libraries. Before using the generated publishing workflow, pin GitHub Actions to reviewed commit SHAs, restrict workflow permissions, protect the publishing environment, and scope or rotate the NuGet key. Prefer exact NuGet versions or lock files instead of wildcard package versions.

A.I.G

Vulnerability Patterns

Insecure DependenciesIntroduces malicious components through unsafe dependency sources
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
Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally

Findings (2)

T08 · Insecure Dependencies

Warning

Location: SKILL.md:186
Finding: Wildcard NuGet Versions Permit Unreviewed Dependency Changes<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 186-189 **Vulnerability Type**: Supply-chain dependency instability **Risk Level**: Medium ### Vulnerable Code ```xml <PackageReference Include="VL.Core" Version="2025.7.*" /> <PackageReference Include="VL.Core.Import" Version="2025.7.*" />  <PackageReference Include="VL.Stride.Runtime" Version="2025.7.*" /> ``` ### Technical Analysis The recommended project configuration uses floating NuGet package versions. The `2025.7.*` pattern allows package restoration to select a future matching release without a corresponding source-code change or explicit review. This weakens build reproducibility and creates a supply-chain exposure. If a publisher account or upstream package is compromised, a malicious matching version could automatically enter subsequent builds. Package installation and build assets can execute logic in a developer environment or CI runner, depending on package contents and build configuration. The finding does not establish that the named packages are malicious. The vulnerability is the unsafe dependency-selection practice presented as the standard project template. ### Attack Path 1. A user applies the `.csproj` template generated from the Skill documentation. 2. The project retains the wildcard package versions. 3. An attacker compromises an upstream publisher or causes a malicious matching package version to be released. 4. A developer or CI runner performs a fresh NuGet restore. 5. NuGet resolves the wildcard to the attacker-controlled release without requiring a repository change. 6. Malicious package or build logic executes in the context of the developer account or build runner. 7. The attacker may tamper with compiled artifacts or access credentials and files available to that build context. ### Impact Assessment Successful exploitation could execute code with the permissions of the developer or CI build account. The accessible ...[truncated 239 chars]
Remediation: <![CDATA[ ## Remediation Suggestions - Replace wildcard package versions with exact, reviewed versions. - Generate and commit `packages.lock.json`. - Enable locked restore in CI with `dotnet restore --locked-mode`. - Configure dependency-update automation to submit reviewed pull requests rather than silently selecting new releases. - Use trusted package sources and package-source mapping where practical. - Review package signatures, ownership changes, release notes, and transitive dependency changes before upgrades. - Rebuild release artifacts only from a clean, isolated runner with minimum required permissions. ]]>

T08 · Insecure Dependencies

Warning

Location: publishing.md:96
Finding: Mutable GitHub Action References Expose NuGet Publishing Credentials<![CDATA[ ## Vulnerability Details **File Location**: `publishing.md`, lines 96-105 **Vulnerability Type**: Mutable CI/CD dependencies with access to a publishing secret **Risk Level**: Medium ### Vulnerable Code ```yaml - uses: actions/checkout@master - uses: microsoft/setup-msbuild@v2 - uses: nuget/setup-nuget@v2.0.0 - uses: vvvv/PublishVLNuget@1.0.43 with: csproj: src\VL.MyLib.csproj nuspec: deployment\VL.MyLib.nuspec icon-src: https://example.com/nugeticon.png icon-dst: ./nugeticon.png nuget-key: ${{ secrets.NUGET_KEY }} ``` ### Technical Analysis The publishing workflow references third-party GitHub Actions through mutable branches or tags instead of verified full commit SHAs. `actions/checkout@master` is explicitly branch-based, while version tags such as `@v2`, `@v2.0.0`, and `@1.0.43` can be moved or replaced by maintainers or by an attacker who compromises the corresponding repository. The `vvvv/PublishVLNuget` action is particularly sensitive because it receives `secrets.NUGET_KEY`. If its referenced tag is maliciously changed, attacker-controlled action code could read and exfiltrate the publishing key or use it directly to publish unauthorized packages. Other compromised actions in the same job may also tamper with the workspace or artifacts before publication. The audit found no evidence that the referenced actions are currently malicious. The vulnerability arises from trusting mutable action references in a credential-bearing release workflow. ### Attack Path 1. A user copies the documented workflow into a repository. 2. The workflow continues to reference actions by mutable branch or tag. 3. An attacker compromises an action maintainer account or obtains permission to modify a referenced tag or branch. 4. The attacker changes the referenced action code to include credential theft or artifact tampering. 5. A push to `main` triggers the publishing workflow. 6. The runner downloads and executes the modified action. 7. ...[truncated 729 chars]
Remediation: <![CDATA[ ## Remediation Suggestions - Pin every GitHub Action to a reviewed full 40-character commit SHA. - Retain the release tag only as a comment for maintainability, for example: ```yaml - uses: actions/checkout@<verified-commit-sha> # v4.x ``` - Verify action ownership, release provenance, and commit signatures before selecting a SHA. - Place publication behind a protected GitHub environment with required reviewer approval. - Restrict `NUGET_KEY` to the minimum package scope and rotate it periodically. - Prefer trusted publishing or short-lived credentials if supported instead of a long-lived API key. - Set explicit minimal workflow permissions, such as `contents: read`, unless additional access is required. - Separate building and publishing into distinct jobs; publish only immutable, verified artifacts. - Avoid exposing publishing credentials to pull-request workflows or untrusted code. - Use dependency-update tooling to propose reviewed SHA updates. ]]>

SkillSpector

Vulnerability Patterns

Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
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

Findings (1)

Vague Triggers

Medium

Confidence: 92% confidence
Finding: The trigger phrases are broad and include common requests like creating a package or making a library, which can cause this skill to activate in conversations that are not specifically about vvvv gamma. Unintended invocation can misroute the agent, produce irrelevant guidance, and increase the chance that a user receives incorrect project setup instructions in the wrong context.

Static analysis

No suspicious patterns detected.