Back to skill

Security audit

Chaos Engineer

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent chaos-engineering guidance, but its copy-pastable examples can disrupt real infrastructure and include unsafe rollback, privilege, and scoping patterns that need human review before installation.

Install only if you want an agent to help draft chaos-engineering plans and code, and require users to review every generated command before use. Treat the examples as unsafe starting points: restrict them to approved non-production or tightly controlled game-day environments, add target allowlists, pin remote manifests and images, use least-privilege credentials, require manual approvals, and add tested rollback and cleanup before running anything.

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 (6)

T09 · Insecure Skill Coding Practices

Error
Location
references/infrastructure-chaos.md:236
Finding
Root Command Injection Through Unsanitized Domain Input<![CDATA[ ## Vulnerability Details **File Location**: `references/infrastructure-chaos.md:236-260` **Vulnerability Type**: OS command injection across a root privilege boundary **Risk Level**: High ### Vulnerable Code ```python class DNSChaos: @staticmethod @contextmanager def block_domain(domain: str, duration_seconds: int = 60): """Block DNS resolution for domain by pointing to localhost.""" try: # Add entry to /etc/hosts subprocess.run([ 'sudo', 'sh', '-c', f'echo "127.0.0.1 {domain}" >> /etc/hosts' ], check=True) print(f"Blocked DNS for {domain}") yield finally: # Wait for duration time.sleep(duration_seconds) # Remove entry from /etc/hosts subprocess.run([ 'sudo', 'sed', '-i', f'/127.0.0.1 {domain}/d', '/etc/hosts' ], check=True) print(f"Restored DNS for {domain}") ``` ### Technical Analysis The caller-controlled `domain` value is interpolated into a command passed to `sudo sh -c`. Because the shell interprets the resulting string, command substitutions and other shell syntax embedded in `domain` are evaluated with root privileges. Double quotation marks do not prevent command substitution. For example, a domain containing `$(command)` can cause `command` to execute before the generated text is appended to `/etc/hosts`. The cleanup operation also inserts the unescaped domain into a `sed` expression. Although that call does not use a shell, specially crafted regular-expression or delimiter content can alter which lines are removed. The root shell exceeds the minimum privilege necessary for generating chaos-test configuration and creates a direct privilege-escalation path when the domain is not fully trusted. ### Attack Path 1. An attacker influences the domain supplied to `DNSChaos.block_domain()`. 2 ...[truncated 635 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Do not invoke `sh -c` with caller-controlled content. - Validate domains with a strict parser and allow only valid DNS labels. - Reject whitespace, shell metacharacters, control characters, slashes, and newline characters. - Perform an atomic, direct file update rather than constructing a shell command. - Add a unique fixed marker to the inserted line and remove only that exact marker during cleanup. - Run the experiment inside an isolated container or network namespace instead of modifying the host-wide `/etc/hosts`. - If elevation is unavoidable, expose a narrowly scoped privileged helper that accepts validated structured input rather than granting general root-shell access. - Preserve the original file, restore it in a `finally` block, and verify the restored state. ]]>

T03 · Remote Payload Retrieval and Execution

Error
Location
references/chaos-tools.md:241
Finding
Unverified Remote Kubernetes Manifest Is Retrieved and Applied<![CDATA[ ## Vulnerability Details **File Location**: `references/chaos-tools.md:241-246` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High ### Vulnerable Code ```yaml - name: Install Litmus run: | kubectl apply -f https://litmuschaos.github.io/litmus/litmus-operator-v2.14.0.yaml kubectl wait --for=condition=Ready pods -l app.kubernetes.io/component=operator --timeout=300s ``` ### Technical Analysis The workflow instructs `kubectl` to retrieve a manifest from an external URL and immediately apply it to the connected Kubernetes cluster. The content is not stored in the audited project, and no cryptographic digest, signature, or provenance verification is performed. Even though the URL contains a version, the hosted resource can potentially change independently of this Skill. A compromise of the hosting account, DNS path, publication process, or upstream project could therefore change the effective payload after the Skill has been reviewed. Chaos operators commonly require substantial cluster permissions. Applying an altered operator manifest could create privileged workloads, cluster-wide RBAC bindings, admission hooks, or credential-reading pods. ### Attack Path 1. The remote manifest or its hosting infrastructure is compromised or replaced. 2. The CI workflow runs manually or according to its schedule. 3. `kubectl` downloads the changed manifest without verifying its digest or signature. 4. The manifest is applied using the workflow's Kubernetes credentials. 5. Attacker-controlled Kubernetes resources execute with the permissions granted to the operator. 6. The attacker may access workloads, secrets, service-account tokens, or cluster control functions. ### Impact Assessment Impact depends on the CI identity and manifest RBAC, but it can extend to cluster-wide code execution and control. A malicious operator deployment could disrupt workloads, extract Kubernetes secrets, create persistent resources, or piv ...[truncated 37 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Download and review the manifest during a controlled dependency-update process rather than during every workflow execution. - Store the approved manifest in the repository. - Verify the upstream artifact with a cryptographic digest and, where available, Sigstore or another trusted signature mechanism. - Pin all referenced container images in the manifest by immutable digest. - Review and minimize the operator's RBAC permissions. - Install the operator in a dedicated namespace with network policies and restricted service accounts. - Separate operator installation from routine experiment execution. - Require manual approval for dependency changes and for first-time cluster installation. ]]>

T08 · Insecure Dependencies

Warning
Location
references/kubernetes-chaos.md:317
Finding
Mutable Latest Container Image Used in Kubernetes Verification Pod<![CDATA[ ## Vulnerability Details **File Location**: `references/kubernetes-chaos.md:317-332` **Vulnerability Type**: Mutable and unverified runtime dependency **Risk Level**: Medium ### Vulnerable Code ```yaml apiVersion: v1 kind: Pod metadata: name: chaos-verification spec: containers: - name: verifier image: bitnami/kubectl:latest command: - /bin/bash - -c - | # Monitor HPA scaling while true; do echo "=== HPA Status ===" kubectl get hpa web-server -o json | \ jq '.status | {current: .currentReplicas, desired: .desiredReplicas, cpu: .currentCPUUtilizationPercentage}' ``` ### Technical Analysis The `latest` image tag is mutable and does not identify a reviewed image artifact. Recreating the pod at a later time can pull different code without any modification to the Skill or manifest. The container is intended to run `kubectl`, which means it may receive a Kubernetes service-account token and API access. A malicious or compromised replacement image could use those credentials for actions unrelated to verification. The pod also omits an explicit service account, disabled token mounting, security context, and resource constraints, leaving its effective privilege dependent on namespace defaults. ### Attack Path 1. The mutable `bitnami/kubectl:latest` image changes or its publication path is compromised. 2. A user creates or recreates the verification pod. 3. Kubernetes pulls the new image under the same manifest. 4. The image starts with the pod's network access and any mounted service-account credentials. 5. Malicious code queries the Kubernetes API, transmits cluster information, or modifies resources within its authorization scope. ### Impact Assessment The obtainable scope is determined by the pod's service account and namespace policy. Potential impact includes unauthorized Kubernetes API access, disclosure of workload metadata, modification of permitted resources, an ...[truncated 43 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Pin the image to an immutable digest, for example `image@sha256:...`. - Verify image signatures and provenance before deployment. - Use a dedicated service account with read-only access limited to the required HPA and pod resources. - Set `automountServiceAccountToken: false` if API credentials are not required; otherwise use a short-lived projected token. - Add a restrictive pod and container security context. - Enforce non-root execution, a read-only root filesystem, dropped capabilities, and seccomp. - Apply egress network restrictions and resource limits. - Replace the unbounded loop with a finite verification job and explicit timeout. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
references/infrastructure-chaos.md:92
Finding
AWS Availability-Zone Simulation Leaves AZ Rebalancing Suspended<![CDATA[ ## Vulnerability Details **File Location**: `references/infrastructure-chaos.md:92-128` **Vulnerability Type**: Destructive cloud operation with incomplete rollback **Risk Level**: High ### Vulnerable Code ```python def simulate_az_failure( self, availability_zone: str, asg_name: str, duration_minutes: int = 10 ): """ Simulate AZ failure by terminating instances in specific AZ. Auto Scaling Group will launch replacements in other AZs. """ # Find instances in target AZ instances = self.ec2.describe_instances(Filters=[ {'Name': 'tag:aws:autoscaling:groupName', 'Values': [asg_name]}, {'Name': 'availability-zone', 'Values': [availability_zone]}, {'Name': 'instance-state-name', 'Values': ['running']} ]) instance_ids = [ i['InstanceId'] for r in instances['Reservations'] for i in r['Instances'] ] if not instance_ids: return {"status": "no_instances", "instances": []} # Suspend AZ-specific scaling activities self.asg.suspend_processes( AutoScalingGroupName=asg_name, ScalingProcesses=['AZRebalance'] ) # Terminate instances to simulate AZ failure self.ec2.terminate_instances(InstanceIds=instance_ids) return { "status": "simulated", "availability_zone": availability_zone, "terminated_instances": instance_ids, "recovery_time": datetime.now() + timedelta(minutes=duration_minutes) } ``` ### Technical Analysis The method suspends the Auto Scaling Group's `AZRebalance` process and terminates every matching running instance in the selected availability zone. It never resumes `AZRebalance`. The returned `recovery_time` is only a timestamp in a Python dictionary. It does not schedule or execute recovery. There is also no `try/finally` block, previous-state capture, maximum target count, environment allowlist, approval gate, or post-experiment health verification. Consequen ...[truncated 1028 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Query and record the original suspended-process state before making changes. - Restore only the state changed by the experiment in a `finally` block. - Call `resume_processes` for `AZRebalance` after the experiment when it was previously active. - Implement an actual server-side or independently supervised rollback deadline. - Require explicit account, region, environment, Auto Scaling Group, and availability-zone allowlists. - Refuse production targets unless an approval token and tested rollback plan are present. - Limit the number or percentage of instances that may be terminated. - Verify remaining healthy capacity before termination. - Monitor recovery and fail closed if replacement capacity does not become healthy. - Use AWS Fault Injection Service with stop conditions and least-privilege IAM where appropriate. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
references/kubernetes-chaos.md:217
Finding
Node Drain Logic Can Evict Protected Workloads Across All Namespaces<![CDATA[ ## Vulnerability Details **File Location**: `references/kubernetes-chaos.md:217-251` **Vulnerability Type**: Excessively broad destructive operation and faulty workload exclusion **Risk Level**: High ### Vulnerable Code ```python # Get all pods on the node field_selector = f"spec.nodeName={node_name}" pods = self.core_v1.list_pod_for_all_namespaces( field_selector=field_selector ) # Evict each pod for pod in pods.items: # Skip DaemonSet pods and mirror pods if pod.metadata.owner_references: for owner in pod.metadata.owner_references: if owner.kind in ['DaemonSet', 'Node']: continue # Create eviction eviction = client.V1Eviction( metadata=client.V1ObjectMeta( name=pod.metadata.name, namespace=pod.metadata.namespace ), delete_options=client.V1DeleteOptions( grace_period_seconds=grace_period_seconds ) ) try: self.core_v1.create_namespaced_pod_eviction( name=pod.metadata.name, namespace=pod.metadata.namespace, body=eviction ) print(f"Evicted pod {pod.metadata.name}") ``` ### Technical Analysis The code states that DaemonSet and mirror pods should be skipped, but `continue` applies only to the inner owner-reference loop. After that loop finishes, execution proceeds to construct and submit an eviction for the same pod. The method lists pods across every namespace and contains no restriction for system namespaces, control-plane nodes, production workloads, protected labels, stateful services, or critical priority classes. It therefore requires broad cluster permissions and can affect workloads beyond the intended experiment. Pod disruption budgets may reject some evictions, but they are not a complete safety boundary and may be absent or permissive. The code also reports the node as drained even when individual evictions fail. ### Attack Path 1. An operator ...[truncated 759 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Correct the exclusion logic by skipping the outer pod loop: ```python owners = pod.metadata.owner_references or [] if any(owner.kind in {"DaemonSet", "Node"} for owner in owners): continue ``` - Restrict experiments to an explicit namespace and workload-label allowlist. - Deny `kube-system`, control-plane, storage, ingress, and other protected namespaces by default. - Reject control-plane nodes and nodes lacking an explicit chaos opt-in label. - Use a dedicated service account with the minimum list and eviction permissions. - Perform a dry run and show the exact eviction set for approval before execution. - Enforce pod disruption budgets and verify replacement capacity. - Track failed evictions and do not report the node as drained unless post-conditions are met. - Ensure uncordoning and recovery checks execute in a `finally` block. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
references/chaos-tools.md:486
Finding
Unauthenticated Chaos Dashboard Binds to All Network Interfaces<![CDATA[ ## Vulnerability Details **File Location**: `references/chaos-tools.md:486-499` **Vulnerability Type**: Unauthenticated network exposure of operational information **Risk Level**: Medium ### Vulnerable Code ```python @app.route('/api/chaos-summary') def chaos_summary(): dashboard = ChaosDashboard(prometheus_url="http://prometheus:9090") return jsonify({ "experiments": dashboard.get_experiment_metrics(hours=24), "mttr_trend": dashboard.get_mttr_trend(), "timestamp": datetime.now().isoformat() }) if __name__ == '__main__': app.run(host='0.0.0.0', port=5000) ``` ### Technical Analysis The Flask application exposes chaos experiment and recovery metrics without authentication or authorization. Binding to `0.0.0.0` makes the service listen on every available interface rather than only loopback. The example also uses Flask's development server directly and provides no TLS, reverse-proxy trust controls, request limits, or network restrictions. If deployed on a shared or externally reachable network, any reachable client can query the endpoint. The returned Prometheus-derived data may disclose experiment names, verdicts, reliability trends, timestamps, and operational weaknesses useful for reconnaissance. ### Attack Path 1. A user runs the dashboard on a host reachable by other network users. 2. Flask listens on every interface on TCP port 5000. 3. A remote client requests `/api/chaos-summary`. 4. No identity or authorization check is performed. 5. Internal reliability and experiment information is returned to the client. ### Impact Assessment The direct impact is unauthorized disclosure of internal operational information. Depending on the Prometheus response, exposed data could reveal failure patterns, experiment schedules, service names, or recovery limitations. The exposed development server also increases the application's attack surface. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions - Bind to `127.0.0.1` by default. - Require authenticated identities and role-based authorization for the API. - Deploy behind a production WSGI server and TLS-terminating reverse proxy. - Restrict access through firewall rules, Kubernetes network policies, or a private service mesh. - Minimize and aggregate returned operational data. - Add request timeouts, rate limits, security logging, and safe error handling. - Avoid exposing raw upstream Prometheus responses. - Document that the development server must not be used in production. ]]>
Vulnerability Patterns
  • 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
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Rogue AgentSelf-Modification, Session Persistence
Findings (27)

Ae1

High
Category
analysis-evasion
Content
| Kubernetes | `references/kubernetes-chaos.md` | Pod, node, Litmus, chaos mesh experiments |
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Credential Access

High
Category
Privilege Escalation
Content
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Update kubeconfig
        run: |
          aws eks update-kubeconfig --name staging-cluster --region us-east-1
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Update kubeconfig
        run: |
          aws eks update-kubeconfig --name staging-cluster --region us-east-1
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Missing User Warnings

High
Confidence
97% confidence
Finding
The document provides multiple destructive chaos-engineering procedures—instance termination, network degradation, resource exhaustion, DNS tampering, and container stoppage—without prominent guardrails, scope limits, rollback steps, or warnings about production impact. In a skill intended to guide users, omission of safety constraints materially increases the chance that users apply these actions against live systems and cause outages or data disruption.

Missing User Warnings

High
Confidence
99% confidence
Finding
The AWS AZ failure example actively terminates running EC2 instances and deregisters targets from a load balancer, but does not prominently warn that this can immediately remove capacity and disrupt production traffic. In this skill context, the code is operationally plausible and easy to adapt, so lack of safeguards makes accidental misuse especially dangerous.

Missing User Warnings

High
Confidence
98% confidence
Finding
The resource exhaustion commands can consume most CPU and memory, perform heavy disk writes, and saturate network bandwidth, which can freeze a host, affect colocated workloads, or trigger cascading service degradation. Because the snippet is copy-pastable and lacks warnings about shared infrastructure, it creates a real risk of unintended denial of service.

Vague Triggers

Medium
Confidence
92% confidence
Finding
The description uses broad activation terms such as 'designing chaos experiments' and 'game day exercises' without clear boundaries, which can cause the skill to be invoked during general DevOps or incident-planning conversations. Because this skill is capable of producing failure-injection and disruption guidance, accidental invocation increases the chance of unsafe or inappropriate operational recommendations in contexts that did not explicitly request chaos actions.

Vague Triggers

Medium
Confidence
95% confidence
Finding
The trigger list is expansive and includes common operational phrases like 'resilience testing,' 'blast radius,' and tool names that may appear in ordinary SRE, Kubernetes, or incident-management discussions. In this skill's context, overbroad triggers are more dangerous because the skill is designed to output implementation code for fault injection, which could lead to unintended disruptive guidance being surfaced too readily.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
This section documents automated instance termination in production-like environments without any explicit safety warning, guardrails, or scoping guidance. In a chaos-engineering skill, destructive examples are expected, but omitting cautions about blast radius, approvals, environment isolation, and rollback makes misuse and accidental disruption more likely.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The Gremlin examples directly launch CPU and network attacks against specified targets via API calls, yet the documentation does not warn about service degradation, dependency impact, or authorization requirements. Because the code is ready to operationalize disruptive actions, readers could apply it unsafely to live systems.

External Transmission

Medium
Category
Data Exfiltration
Content
def __init__(self, api_key: str, team_id: str):
        self.api_key = api_key
        self.team_id = team_id
        self.base_url = "https://api.gremlin.com/v1"
        self.headers = {
            "Authorization": f"Key {api_key}",
            "Content-Type": "application/json"
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
}
        }

        response = requests.post(
            f"{self.base_url}/attacks/new",
            headers=self.headers,
            json=payload
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
}
        }

        response = requests.post(
            f"{self.base_url}/attacks/new",
            headers=self.headers,
            json=payload
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
}
        }

        response = requests.post(
            f"{self.base_url}/scenarios",
            headers=self.headers,
            json=payload
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The scheduled GitHub Actions workflow installs chaos tooling, mutates cluster state, and runs pod-deletion experiments on a schedule, but it lacks an explicit warning about recurring disruption to staging infrastructure. Scheduled destructive automation increases the chance of unintended outages, noisy tests, and operational confusion if readers adopt it verbatim.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The Jenkins pipeline creates and applies chaos manifests dynamically and executes disruptive experiments, but the documentation does not explicitly warn about the operational impact or the fact that it writes files used to mutate cluster state. In this context, the missing cautions increase the risk of users running the pipeline in inappropriate environments or with unsafe parameters.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
raise ValueError("Production >10% requires feature flag AND auto-rollback")

        if self.max_duration_seconds > 600:
            raise ValueError("Max duration cannot exceed 10 minutes without approval")

# Progressive blast radius expansion
def progressive_rollout() -> list[BlastRadiusConfig]:
Confidence
75% confidence
Finding
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The runbook includes concrete failure-injection commands that reboot an RDS instance with failover, revoke database network access, and simulate a connection leak, but it does not place an explicit safety warning immediately around those steps requiring confirmation of a non-production target and authorization before execution. In a chaos-engineering skill, such commands are expected, but without strong guardrails they can be copied into the wrong environment and cause real service disruption, data-path outages, or unintended incident escalation.

External Transmission

Medium
Category
Data Exfiltration
Content
def create_proxy(self, name: str, listen: str, upstream: str):
        """Create proxy to inject failures."""
        response = requests.post(f"{self.base_url}/proxies", json={
            "name": name,
            "listen": listen,
            "upstream": upstream,
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
def add_latency(self, proxy: str, latency_ms: int, jitter_ms: int = 0):
        """Add latency toxic."""
        return requests.post(
            f"{self.base_url}/proxies/{proxy}/toxics",
            json={
                "name": "latency",
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
def add_latency(self, proxy: str, latency_ms: int, jitter_ms: int = 0):
        """Add latency toxic."""
        return requests.post(
            f"{self.base_url}/proxies/{proxy}/toxics",
            json={
                "name": "latency",
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
def add_latency(self, proxy: str, latency_ms: int, jitter_ms: int = 0):
        """Add latency toxic."""
        return requests.post(
            f"{self.base_url}/proxies/{proxy}/toxics",
            json={
                "name": "latency",
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
# CPU stress test using stress-ng

# Install stress-ng
sudo apt-get install -y stress-ng

# Stress CPU - use 80% of available cores for 5 minutes
stress-ng --cpu $(nproc --all) --cpu-load 80 --timeout 5m
Confidence
70% confidence
Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The DNS failure simulation modifies /etc/hosts with sudo and delays cleanup until after the context exits, which can break local name resolution for the host and any dependent processes if interrupted or misused. The absence of warnings and robust restoration logic makes this more dangerous than a purely illustrative example.

Session Persistence

Medium
Category
Rogue Agent
Content
def block_domain(domain: str, duration_seconds: int = 60):
        """Block DNS resolution for domain by pointing to localhost."""
        try:
            # Add entry to /etc/hosts
            subprocess.run([
                'sudo', 'sh', '-c',
                f'echo "127.0.0.1 {domain}" >> /etc/hosts'
Confidence
92% confidence
Finding
Appending entries to /etc/hosts creates system-wide state that persists beyond the immediate command and may remain if cleanup fails, the process is killed, or sed removal does not match exactly. In a chaos-testing skill, this persistent host modification is hazardous because it can silently redirect or break traffic after the experiment ends.

Static analysis

No suspicious patterns detected.