Chaos Test Designer

• Outcome: Review
• Latest audit: Sep 16, 2026 · 7:29 AM UTC
• Version: 1.0.1

Overview

This chaos-engineering skill is purpose-aligned, but it includes production-targeted failure examples and broad Kubernetes discovery without enough scoping or confirmation safeguards.

Review carefully before installing or using. Treat generated commands as design drafts only, and require explicit non-production defaults, Kubernetes context and namespace, dry runs, replica and health checks, rollback readiness, and human approval before any failure injection. Avoid letting this skill inspect all namespaces unless that scope is intentional and authorized.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• 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

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:158

Finding

Destructive Kubernetes Pod Deletion Without Adequate Safety Controls

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 158-159
Vulnerability Type: Unsafe destructive operation against the active Kubernetes environment
Risk Level: High

Vulnerable Code:

bash

POD=$(kubectl get pods -l app=payment-service -o jsonpath='{.items[0].metadata.name}')
kubectl delete pod "$POD" --grace-period=0

Technical Analysis

The example script selects the first pod matching app=payment-service and immediately deletes it with a zero-second grace period. It operates against the user's active Kubernetes context and default namespace without requiring an explicit cluster, context, namespace, or approved environment.

The script does not verify that the target belongs to a test environment, confirm that sufficient healthy replicas remain, perform a dry run, request operator approval, or enforce the abort conditions shown in the preceding declarative example. The zero-second grace period can prevent orderly shutdown behavior and increase the likelihood of interrupted requests or incomplete application-level operations.

Attack Path

1. A user or Agent has Kubernetes credentials and an active context.
2. The active context points to a production or otherwise sensitive cluster.
3. The default namespace contains one or more pods with the label app=payment-service.
4. The generated script retrieves the first matching pod without validating its ownership, environment, health, or replica availability.
5. The script force-deletes that pod with no grace period.
6. If redundancy, rescheduling, disruption controls, or application shutdown handling are inadequate, the deletion causes degraded service, interrupted processing, or an outage.

Impact Assessment

The operation uses the Kubernetes deletion privileges of the invoking identity. It does not independently escalate privileges, but it can exercise already granted pod-deletion permissions against an unintended cluster or name ...[truncated 363 chars]

Remediation

View remediation

Remediation Suggestions

• Require explicit cluster context, namespace, workload label, and environment parameters.
• Reject production targets by default and require a separate, explicit production authorization workflow.
• Validate the active context and namespace against an allowlist before performing any mutation.
• Confirm that the target is controlled by an appropriate workload controller and that enough healthy replicas will remain.
• Add a dry-run mode and display the exact target before requesting interactive operator approval.
• Use a nonzero grace period unless abrupt termination is an explicitly approved property of the experiment.
• Enforce PodDisruptionBudgets and experiment-specific least-privilege RBAC.
• Implement executable abort monitoring, maximum experiment duration, and a tested rollback procedure rather than documenting those controls only in a separate example.
• Record the selected resource UID, cluster, namespace, start time, and operator authorization for auditability.

T05 · Unauthorized Access and Privilege Escalation

Note

• Location: SKILL.md:18

Finding

Cluster-Wide Kubernetes Workload Enumeration Exceeds Least-Privilege Discovery

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 18-23
Vulnerability Type: Excessive infrastructure discovery scope
Risk Level: Low

Vulnerable Code:

bash

# Discover services and dependencies
kubectl get deployments -A 2>/dev/null | grep -v kube-system
docker compose config --services 2>/dev/null
# Or read architecture docs
find . -maxdepth 3 -name "*.md" | xargs grep -li "architecture\|topology\|dependency" 2>/dev/null

Technical Analysis

The Kubernetes discovery command uses -A, causing it to enumerate deployments across every namespace accessible to the current identity. Excluding kube-system only filters displayed output after Kubernetes has already returned cluster-wide deployment metadata; it does not constrain authorization scope or prevent access to unrelated namespaces.

The command therefore gathers more infrastructure metadata than is normally required to design an experiment for a specific service. Redirecting standard error to /dev/null also hides permission, context, and configuration failures that operators may need to recognize before proceeding.

The local Docker Compose and documentation discovery commands are consistent with service discovery, but they similarly suppress errors. The confirmed access-control concern is the cluster-wide Kubernetes enumeration.

Attack Path

1. The Agent runs the documented discovery command using an identity with access to multiple Kubernetes namespaces.
2. kubectl get deployments -A requests deployment metadata from all accessible namespaces.
3. Names, namespaces, replica information, and workload topology for unrelated applications are returned.
4. The output is placed into the Agent's working context and may influence later experiment generation.
5. Sensitive internal service names or topology information can consequently be exposed beyond the intended experiment scope.

Impact Assessment

This behavior does no ...[truncated 482 chars]

Remediation

View remediation

Remediation Suggestions

• Require the operator to specify an approved Kubernetes context and namespace.
• Replace kubectl get deployments -A with namespace-scoped discovery, such as kubectl --context "$CONTEXT" -n "$NAMESPACE" get deployments.
• Use an allowlist if an experiment legitimately spans multiple namespaces.
• Request only the metadata fields necessary to map the target service.
• Run discovery with a read-only, namespace-scoped service account.
• Do not suppress permission or context errors by default; present them to the operator and stop safely.
• Add a preflight check that prints and validates the current context, namespace, and authenticated identity before discovery.
• Document a minimal RBAC policy for discovery and separate it from the permissions used to inject failures.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• 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
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Missing User Warnings

High

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

Finding

The skill includes destructive production-oriented chaos actions such as killing pods in a production namespace and reducing service availability, but it does not place a clear upfront safety warning or mandatory safeguards before presenting runnable examples. In the wrong hands or via accidental invocation, this materially lowers the barrier to disruptive actions against live systems and may normalize unsafe experimentation in production.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium

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

Finding

The trigger phrases are broad and overlap with common operational or planning requests like testing resilience or game day planning. This can cause the skill to activate in situations where the user did not explicitly intend chaos-engineering guidance, increasing the chance that destructive experiment design or production-targeted commands are suggested in the wrong context.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.