Performance Tester

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 6:21 AM UTC
• Version: 1.0.0

Overview

This is a disclosed performance-testing helper whose examples can generate real traffic, but the behavior matches its stated purpose and is user-controlled.

Install only if you need performance-test generation. Run generated tests only against systems you own or are explicitly authorized to test, prefer staging or isolated environments, use short-lived test credentials, pin or vendor dependencies where possible, and keep load levels conservative until capacity and approvals are clear.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:206

Finding

Unpinned Locust Dependency Installation

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, line 206
Vulnerability Type: Unpinned third-party package installation
Risk Level: Medium

Vulnerable Code

bash

# Install: pip install locust

Technical Analysis

The documented installation command installs Locust without specifying a reviewed version or validating package integrity. Consequently, package resolution depends on the mutable state of the configured Python package index at installation time.

Although there is no evidence that the legitimate Locust package is malicious, an unpinned installation can expose users to compromised future releases, compromised transitive dependencies, or unsafe package-index configuration. Python package installation may execute package-controlled build or installation logic, while the installed package later executes with the privileges of the user running the load test.

Attack Path

1. An attacker compromises a future Locust release, one of its transitive dependencies, or a package source configured by the user.
2. A user follows the documented pip install locust instruction.
3. pip resolves and downloads the attacker-controlled package version.
4. Malicious code executes during installation, import, or subsequent Locust invocation.
5. The code operates with the privileges and environment access of the installing or testing user.

Impact Assessment

Successful exploitation could permit arbitrary code execution under the affected user's account. Depending on the execution environment, the compromised dependency could access load-test scripts, environment variables, API credentials, result files, and network-accessible systems. The issue does not independently provide elevated operating-system privileges, but its scope includes resources available to the invoking user or CI worker.

Remediation

View remediation

Remediation Suggestions

• Pin Locust to a reviewed, exact version rather than relying on unconstrained resolution.

• Lock all transitive dependencies and verify them with cryptographic hashes, such as through a hash-validated requirements file.

• Install dependencies inside an isolated virtual environment or disposable container.

• Configure pip to use an approved package index and disallow unexpected secondary indexes.

• Periodically review and intentionally update the locked dependency set after security testing.

• Prefer a documented command similar to:

  bash

  python -m venv .venv
  . .venv/bin/activate
  pip install --require-hashes -r requirements.lock
  

T03 · Remote Payload Retrieval and Execution

Warning

• Location: references/k6-patterns.md:6

Finding

Runtime Retrieval and Execution of Remote JavaScript

Content

View full analysis

Vulnerability Details

File Location: references/k6-patterns.md, line 6
Vulnerability Type: Remote executable module import without local integrity verification
Risk Level: Medium

Vulnerable Code

javascript

import papaparse from 'https://jslib.k6.io/papaparse/5.1.1/index.js';

Technical Analysis

The k6 example imports executable JavaScript directly from an external HTTPS URL. The path includes a version number, but the project does not provide a cryptographic digest, vendored copy, or other mechanism that ensures the retrieved bytes are identical to the version reviewed by the Skill author.

This creates a remote code execution channel whose effective payload is controlled outside the audited repository. HTTPS protects transport confidentiality and integrity under normal conditions, but it does not make remote content immutable or protect against compromise of the hosting infrastructure, publication process, or relevant trust chain.

Attack Path

1. An attacker compromises the remote module, its hosting infrastructure, delivery process, or an applicable trust component.
2. The user generates or copies the documented k6 test pattern.
3. k6 retrieves the altered JavaScript module from the external URL.
4. The imported module executes in the k6 test context.
5. Malicious module behavior can interact with data and capabilities exposed to the test runtime, including supplied test records and requests made with test credentials.

Impact Assessment

Exploitation could modify test behavior, falsify performance results, disclose test data, or abuse authorization tokens and network access available to the k6 process. The resulting privileges are limited to those of the k6 execution environment, but CI workers or developer systems may expose sensitive environment variables and privileged access to staging services.

Remediation

View remediation

Remediation Suggestions

• Vendor the reviewed JavaScript dependency into the project and import it from a local path.
• Record the expected cryptographic checksum of the vendored artifact and verify it during dependency updates.
• If remote retrieval is unavoidable, download the artifact in a controlled preparation step, validate it against an approved digest, and execute only the validated local copy.
• Restrict outbound network access from load-test workers to required target services.
• Provide test credentials with minimal scope, short lifetimes, and access only to isolated non-production environments.
• Establish a controlled dependency-update process that reviews changes before updating the stored artifact or checksum.

T08 · Insecure Dependencies

Warning

• Location: references/locust-distributed.md:36

Finding

Mutable Locust Container Image Used Without a Tag or Digest

Content

View full analysis

Vulnerability Details

File Location: references/locust-distributed.md, lines 36-44
Vulnerability Type: Unpinned container dependency
Risk Level: Medium

Vulnerable Code

yaml

services:
  master:
    image: locustio/locust
    ports:
      - "8089:8089"
    volumes:
      - ./:/mnt/locust

  worker:
    image: locustio/locust

Technical Analysis

Both services reference locustio/locust without an explicit immutable digest. Docker therefore resolves a mutable default tag, normally latest, whose contents can change after this Skill has been reviewed. The container also receives the current project directory as a mounted volume in the master service.

There is no evidence that the current official image is malicious. The risk arises because future execution can retrieve different image contents under the same Compose configuration. A registry compromise, publisher-account compromise, or unsafe image update could introduce attacker-controlled code.

Attack Path

1. An attacker compromises the image publisher, container registry, mutable default tag, or an upstream image component.
2. A user runs the documented Docker Compose configuration.
3. Docker pulls or uses the altered image associated with the unpinned reference.
4. Attacker-controlled container entry-point code executes.
5. The malicious process accesses resources granted to the container, including the mounted project directory and reachable network services.

Impact Assessment

Exploitation could expose or modify files under the mounted project directory, manipulate test scripts or results, access environment-provided credentials, and send traffic to systems reachable from the container network. The container does not inherently gain host-root access from the shown configuration, but the practical scope depends on Docker configuration, volume permissions, supplied secrets, and network reachability.

Remediation

View remediation

Remediation Suggestions

• Pin the container image to a reviewed immutable digest, for example locustio/locust@sha256:<approved-digest>.

• Verify image provenance and signatures before deployment.

• Update pinned digests only through a documented review and vulnerability-scanning process.

• Mount only the files required by Locust rather than the entire current directory.

• Make script mounts read-only where modification is unnecessary:

  yaml

  volumes:
    - ./test_perf.py:/mnt/locust/test_perf.py:ro
  

• Run the container as a non-root user, drop unnecessary Linux capabilities, enable a read-only root filesystem where practical, and avoid exposing credentials not required by the test.

• Restrict the container's network access to authorized test targets.

SkillSpector

Vulnerability Patterns

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

Findings (3)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The skill provides explicit load, stress, spike, and soak testing procedures and runnable scripts without prominently warning that these techniques can disrupt production systems, violate acceptable-use rules, or resemble denial-of-service activity if aimed at real services. Because the skill is specifically designed to help users generate traffic at scale, omission of safety constraints materially increases the chance of harmful misuse or accidental service degradation.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 88% confidence

Finding

The examples show bearer tokens being passed to requests and command lines without user-facing cautions about credential exposure, shell history leakage, log capture, or use against non-TLS endpoints. While common in testing examples, this can normalize unsafe handling of secrets and lead users to paste real tokens into scripts, terminals, CI logs, or shared result files.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 87% confidence

Finding

This markdown file includes examples that submit usernames and passwords, add items to carts, execute checkout flows, and automate browser logins, but it provides no warning that running these snippets will send data to external services and may affect live systems or accounts. For markdown files, safety-relevant behavior that could impact user data or system integrity should be explicitly disclosed.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.