T09 · Insecure Skill Coding Practices
- Location
src/repro_pack/pipeline.py:60- Finding
Raw sensitive input is propagated into unredacted derived output files
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is meant to sanitize support cases, but its pipeline can still place sensitive raw details into generated files that users may share.
Review before installing and avoid using it on real customer tickets, logs, screenshots, or credentials until the raw-derived output paths are redacted and a final whole-pack scan blocks leaks. Use private per-run temp/output directories, inspect every generated file and ZIP before sharing, and pin dependencies for reproducible installs.
src/repro_pack/pipeline.py:60Raw sensitive input is propagated into unredacted derived output files
SKILL.md:45Predictable shared temporary files permit symlink clobbering and cross-run data exposure
Mixing characters from multiple Unicode scripts in a single identifier is a common technique to create visually ambiguous tool names.
Mixing characters from multiple Unicode scripts in a single identifier is a common technique to create visually ambiguous tool names.
Mixing characters from multiple Unicode scripts in a single identifier is a common technique to create visually ambiguous tool names.
The declared description says the skill converts support tickets, logs, and screenshots into sanitized engineering issue packs with repro steps and summaries. However, the supplied code is an evaluator/comparator module. compare_facts scores how well an already-produced actual fact set matches an expected one. compare_redaction scans original/sanitized text for PII and scores recall of redaction. check_completeness checks whether specific output files already exist in an output directory. These behaviors are consistent with a testing or grading harness for such a skill, not the skill itself. There are no triggers implemented, no parsing of screenshots, no generation of issue packs, no creation of summaries, and no actual sanitization logic beyond checking whether sanitization succeeded. Therefore the code’s primary purpose materially differs from the declared purpose.
The declared description focuses on processing customer bug reports, sanitizing logs, producing reproduction steps, and packaging issues for engineering handoff. The supplied code does none of that. It does not parse tickets, logs, or screenshots; it does not sanitize data; it does not generate repro steps or support escalation summaries. Instead, its sole purpose is to render evaluation/scoring results into markdown and JSON reports. This is a materially different primary purpose, so the description does not accurately represent the code.
The declared purpose describes a production-facing transformation utility for support artifacts into sanitized reproducible engineering issue packs. The supplied code does not implement that workflow directly. Instead, it is an evaluation script for testing another pipeline (run_pipeline) across example cases, comparing outputs to expected results, checking completeness, and writing evaluation reports. While it references artifacts like tickets and logs and indirectly invokes a pipeline that may do the declared task, this code chunk’s primary purpose is benchmarking/scoring, which is materially different from the declared user-facing behavior. No suspicious extra permissions are evident, but the behavior is still mismatched because the main capability is evaluation, not issue-pack generation.
There is a clear mismatch. The declared purpose centers on transforming customer support artifacts into sanitized engineering issue packs with repro steps and summaries. The supplied code does none of that: it only models scoring data structures and computes percentages/aggregates for evaluation results. It does not ingest tickets, logs, or screenshots, perform sanitization, generate repro steps, or create issue handoff packs. The code’s primary purpose is unrelated evaluation/scoring logic, so the description does not accurately represent the actual behavior.
The log line exposes a bearer token in plaintext alongside an IP address and stack-trace context, which is sensitive authentication material that could be reused by anyone with log access. In this skill’s context, the danger is increased because the stated purpose is to sanitize logs and convert them into issue packs; if secrets are not reliably redacted before sharing, the skill could propagate credentials to broader engineering or support audiences.
The ticket contains multiple categories of highly sensitive data in plain text, including a phone number, email address, tenant identifier, national ID number, an apparent password, and an API token. In the context of a skill whose purpose is to sanitize tickets and generate engineering issue packs, retaining this raw data creates a strong risk of credential misuse, privacy violations, cross-system correlation, and accidental propagation of secrets into downstream issue trackers, logs, or model prompts.
The README promotes ingestion of customer tickets, logs, chat records, and screenshots containing potentially sensitive data, but it does not prominently warn users about privacy limitations, retention, or the risks of sending raw material to the skill before sanitization is complete. Because the skill handles high-sensitivity support artifacts, missing upfront privacy guidance increases the chance of accidental exposure of PII, credentials, or internal data during use.
The README suggests triggering the skill with broad natural-language phrases like '帮我整理这个客户 bug' and 'turn this ticket into an engineering issue'. In an agent environment, such generic phrases can cause unintended invocation during ordinary support conversations, leading the skill to process sensitive tickets, logs, or screenshots without the user clearly intending to start the workflow.
The skill instructs the agent to read user-supplied files, write temporary/output files, and run external commands, but it declares no explicit tool scope or permission boundaries. That creates an overprivileged and ambiguous execution surface where the runtime may grant broader file or network access than users expect, increasing the chance of data exposure when processing sensitive tickets and logs.
Several triggers such as 'sanitize these logs' and 'generate a repro pack' are broad enough to match routine requests outside a tightly controlled support-escalation workflow. Overbroad activation can cause the skill to ingest sensitive files, perform redaction/writing actions, or produce customer-facing outputs in contexts where the user did not intend this higher-risk processing.
The instruction to generate a complete engineering issue 'without asking any questions' pushes the agent toward autonomous judgment despite potentially missing or contradictory data. In a workflow handling sensitive support artifacts, this can lead to fabricated details, incorrect severity, misdirected escalations, or unsafe customer communications presented as authoritative.
Using the templates in `templates/`, generate three documents:
1. **Engineering Issue** (`templates/engineering_issue.md`): Fill in ALL fields. Replace every `[NEEDS_AI_REVIEW]` placeholder with your analysis. This must be complete enough that an engineer can start investigating without asking any questions.
2. **Internal Escalation** (`templates/internal_escalation.md`): Write a concise summary for support leads and PMs. Include severity, impact scope, and recommended actions.
The pipeline opens support tickets and log files, reads their full contents, and aggregates them for parsing and redaction. Although the module docstring describes the pipeline generally, there is no confirmation prompt, user-facing log/print, or inline warning near these operations that the skill will ingest potentially sensitive ticket and log data.
The human-readable report includes m.original_snippet, which appears to be the original matched PII value. That defeats the purpose of sanitization by re-exposing sensitive data in the generated issue pack or summary, which may then be shared with engineers, support, or third parties who should only receive redacted content.
This code file performs a file write by saving eval_report.json, but the only surrounding language is an implementation comment and a completion message after the fact. There is no prior confirmation, cautionary note, or docstring disclosure that running the CLI will create or overwrite a report file outside the examples directory.
The file includes locale-specific personal and organizational identifiers such as a Chinese personal name and .cn email domain, which may indicate an implicit region/language assumption in skill-related content. However, there is no explicit instruction or policy text forcing a language or locale, so this is only a weak natural-language policy concern.
Wheel is also left unpinned in the build-system requirements, creating uncertainty about whether vulnerable versions may be selected during packaging. Although the exposure is primarily in build/release environments rather than end-user runtime, build-time path traversal or similar flaws can still affect CI integrity and artifact safety.
Wheel is also left unpinned in the build-system requirements, creating uncertainty about whether vulnerable versions may be selected during packaging. Although the exposure is primarily in build/release environments rather than end-user runtime, build-time path traversal or similar flaws can still affect CI integrity and artifact safety.
The manifest specifies click with a lower-bound range (>=8.1) rather than pinning or constraining to a known-safe version, so dependency resolution could install a vulnerable release covered by an advisory. In a skill that processes support tickets, logs, and screenshots and likely exposes CLI-driven workflows, a vulnerable command-handling library can increase risk because untrusted user-derived content may flow into command interfaces or plugin behavior.
Jinja2 is included with only a minimum version (>=3.1), leaving room for installation of versions affected by known sandbox escape and template-related vulnerabilities. This skill's purpose—transforming potentially sensitive support artifacts into issue packs—makes templating more security-relevant because attacker-controlled ticket text, logs, or metadata could be rendered into templates, amplifying the impact of a vulnerable templating engine.
Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
Detected: suspicious.exposed_secret_literal