Shadow Traffic Tester

• Outcome: Review
• Latest audit: Sep 16, 2026 · 7:50 AM UTC
• Version: 1.0.0

Overview

The skill is purpose-aligned for shadow traffic testing, but its instructions can mirror full production requests and clone production deployment privileges without enough safeguards.

Review before installing or using in production. Only use with explicit approval from the service owner and security/privacy stakeholders; restrict mirrored routes, sample traffic, strip credentials and cookies, isolate the shadow service with separate low-privilege credentials and read-only dependencies, and avoid storing raw production logs in shared temporary files.

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

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:121
• Finding: Shadow Deployment Inherits Production Credentials and Privileges<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 121-147 **Vulnerability Type**: Production privilege and secret inheritance **Risk Level**: High ### Vulnerable Code ```bash # Clone the production deployment with shadow labels kubectl get deployment "$SERVICE_NAME" -n "$NAMESPACE" -o json | python3 -c " import json, sys deploy = json.load(sys.stdin) # Modify for shadow deploy['metadata']['name'] += '-shadow' deploy['metadata'].pop('resourceVersion', None) deploy['metadata'].pop('uid', None) deploy['metadata'].pop('creationTimestamp', None) deploy['metadata']['labels']['version'] = 'shadow' deploy['metadata']['labels']['traffic-role'] = 'shadow' deploy['spec']['selector']['matchLabels']['version'] = 'shadow' deploy['spec']['template']['metadata']['labels']['version'] = 'shadow' deploy['spec']['template']['metadata']['labels']['traffic-role'] = 'shadow' # Set shadow image for c in deploy['spec']['template']['spec']['containers']: c['image'] = c['image'].rsplit(':', 1)[0] + ':shadow' # Reduce replicas for shadow (it only needs to handle, not serve) deploy['spec']['replicas'] = max(1, deploy['spec'].get('replicas', 1) // 2) print(json.dumps(deploy, indent=2)) " | kubectl apply -f - ``` ### Technical Analysis The procedure copies the complete production Deployment specification and changes only selected metadata, labels, image tags, and replica count. Security-sensitive pod settings are not removed or restricted. The resulting shadow pods can inherit: - The production Kubernetes service account and its RBAC permissions. - Secrets supplied through environment variables or `envFrom`. - Secret, projected-token, and persistent-volume mounts. - Cloud workload identity annotations or credentials. - Production network connectivity. - Privileged security contexts, Linux capabilities, or host resources. - Sidecars that possess credentials or administrative access. The container image is then changed to a `:shadow` tag without validating an i ...[truncated 1435 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Create a dedicated shadow Deployment instead of cloning the complete production pod template. - Assign a dedicated service account with no Kubernetes API permissions unless explicitly required. - Remove production `env`, `envFrom`, secret volumes, projected tokens, persistent volumes, and workload-identity annotations. - Set `automountServiceAccountToken: false` when Kubernetes API access is unnecessary. - Use a dedicated read-only or sanitized data source rather than production databases and queues. - Apply a restrictive NetworkPolicy that permits only the minimum required ingress and egress. - Enforce a hardened security context, including non-root execution, a read-only root filesystem, seccomp, and removal of unnecessary Linux capabilities. - Select the shadow image explicitly and pin it to a reviewed immutable digest rather than deriving a mutable `:shadow` tag. - Validate the generated manifest and require operator approval before applying it. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:66
• Finding: Unfiltered Production Requests Are Mirrored to a Less-Trusted Shadow Service<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 66-72 and 98-105 **Vulnerability Type**: Uncontrolled duplication of sensitive production traffic **Risk Level**: High ### Vulnerable Code Istio configuration: ```yaml mirror: host: {SERVICE_NAME} subset: shadow mirrorPercentage: value: 100.0 ``` Nginx configuration: ```nginx location / { proxy_pass http://production; mirror /mirror; mirror_request_body on; } location = /mirror { internal; proxy_pass http://shadow$request_uri; proxy_set_header X-Shadow-Request "true"; # Shadow responses are discarded } ``` ### Technical Analysis The configurations mirror 100% of production requests to the shadow service. The Nginx configuration explicitly enables request-body mirroring and does not remove sensitive headers. Neither configuration provides controls for: - Authorization, cookie, API-key, or session header removal. - Personal or regulated data redaction. - Exclusion of authentication, payment, administration, upload, or other sensitive routes. - Prevention of writes and downstream side effects. - Traffic sampling or explicit endpoint allowlisting. - Data retention and logging restrictions in the shadow environment. Discarding the shadow response prevents it from affecting the response returned to the user, but it does not make processing the mirrored request side-effect free. A shadow handler can still write to databases, publish events, send messages, invoke third-party APIs, or log sensitive content. ### Attack Path 1. A user sends a production request containing credentials, session tokens, personal information, uploaded content, or state-changing instructions. 2. Istio or Nginx duplicates the request and sends it to the shadow service. 3. The shadow service receives the request path, body, and any headers that the proxy has not explicitly removed. 4. Vulnerable or compromised shadow code records or discloses the sensitive data. 5. If the shadow se ...[truncated 793 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Use an explicit allowlist of safe, idempotent routes instead of mirroring all traffic. - Exclude authentication, payment, administration, file-upload, and state-changing endpoints. - Strip `Authorization`, `Cookie`, API-key, proxy-authorization, and other sensitive headers before forwarding requests. - Redact or tokenize sensitive body fields before traffic reaches the shadow service. - Begin with a minimal sampled percentage and increase it only after privacy and capacity validation. - Ensure the shadow service cannot write to production databases, queues, caches, object stores, or external APIs. - Provide read-only, sanitized, or disposable shadow dependencies. - Add an enforced shadow-mode control at the application layer to suppress writes and external side effects. - Isolate shadow workloads with NetworkPolicies and separate credentials. - Define retention limits and access controls for all shadow logs and captured response data. - Perform privacy, compliance, and data-classification review before enabling production traffic mirroring. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:178
• Finding: Production Logs Are Written to Predictable Shared Temporary Files<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 178-190 **Vulnerability Type**: Unsafe temporary-file handling and plaintext sensitive data **Risk Level**: Medium ### Vulnerable Code ```bash NAMESPACE="${1:-default}" SERVICE_NAME="${2:-my-service}" # Collect production access logs echo "=== Gathering production access logs ===" kubectl logs -l app="$SERVICE_NAME",version=v1 -n "$NAMESPACE" \ --tail=1000 --since=1h 2>/dev/null > /tmp/prod-access.log # Collect shadow access logs echo "=== Gathering shadow access logs ===" kubectl logs -l app="$SERVICE_NAME",traffic-role=shadow -n "$NAMESPACE" \ --tail=1000 --since=1h 2>/dev/null > /tmp/shadow-access.log echo "Production log lines: $(wc -l < /tmp/prod-access.log)" echo "Shadow log lines: $(wc -l < /tmp/shadow-access.log)" ``` ### Technical Analysis The procedure writes access logs to fixed filenames in the shared `/tmp` directory. It does not securely create the files, establish restrictive permissions, validate their ownership or file type, or delete them after analysis. Shell redirection follows symbolic links. On a system where another local user can create entries in `/tmp`, that user can pre-create `/tmp/prod-access.log` or `/tmp/shadow-access.log` as a symbolic link. When a more privileged operator runs the command, the shell opens and truncates the symlink target using the operator's permissions. The fixed paths can also cause separate audit runs or users to overwrite one another's data. Access logs may contain request paths, identifiers, IP addresses, error details, or application-specific sensitive information and can remain on disk after the analysis completes. ### Attack Path 1. A local attacker predicts the fixed temporary filename. 2. The attacker creates `/tmp/prod-access.log` or `/tmp/shadow-access.log` as a symbolic link to a file writable by the future operator, or waits for logs from another user's run. 3. A privileged operator executes the analysis commands. ...[truncated 783 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Create a private temporary directory with `mktemp -d`. - Set `umask 077` before creating files so only the invoking user can read them. - Store both log files inside the private directory and quote every generated path. - Register a cleanup trap to remove the directory on normal exit and interruption. - Verify that generated paths are regular files owned by the current user before processing them. - Avoid retaining raw logs when aggregate metrics are sufficient. - Redact sensitive values before writing logs to disk. - For example: ```bash umask 077 TMP_DIR="$(mktemp -d)" || exit 1 trap 'rm -rf -- "$TMP_DIR"' EXIT HUP INT TERM PROD_LOG="$TMP_DIR/prod-access.log" SHADOW_LOG="$TMP_DIR/shadow-access.log" kubectl logs -l app="$SERVICE_NAME",version=v1 -n "$NAMESPACE" \ --tail=1000 --since=1h >"$PROD_LOG" kubectl logs -l app="$SERVICE_NAME",traffic-role=shadow -n "$NAMESPACE" \ --tail=1000 --since=1h >"$SHADOW_LOG" ``` ]]>

SkillSpector

Vulnerability Patterns

• 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
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill explicitly saves recent production and shadow access logs to /tmp files for later analysis, but it provides no warning or safeguards for potentially sensitive contents such as user identifiers, URLs, tokens, cookies, headers, or internal error details. In a shadow-traffic context this is particularly risky because mirrored production requests often reflect real user traffic, so local log collection can create an unauthorized secondary store of sensitive data on the operator's machine or execution environment.

Static analysis

No suspicious patterns detected.