Pywayne Helper

• Outcome: Review
• Latest audit: Sep 10, 2026 · 7:51 PM UTC
• Version: 0.1.0

Overview

The skill is a coherent YAML configuration helper, but it encourages storing API tokens in a shared project file without enough warning or safeguards.

Install only if you are comfortable with the agent creating and changing a shared YAML file in your project root. Do not store API tokens, passwords, private keys, or other secrets in common_info.yaml; use environment variables or a proper secret store instead, and keep the YAML file out of source control if it may contain sensitive runtime data.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:74

Finding

Plaintext Storage of Sensitive Tokens in a Shared YAML Configuration

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:74 and SKILL.md:229
Vulnerability Type: Plaintext sensitive-data storage
Risk Level: Medium

The documentation explicitly demonstrates writing an API token into the shared configuration:

python

helper.set_module_value('api', 'token', value='abc123')

It also shows the resulting token stored in plaintext YAML:

yaml

api:
  token: abc123
  endpoint: https://api.example.com

Technical Analysis

The documented design stores configuration values in common_info.yaml, a centralized file shared across processes and modules. The examples encourage users to place API tokens in this file but do not require restrictive file permissions, encryption, secret-store integration, access controls, or redaction of sensitive values from debugging output.

Although abc123 is an illustrative placeholder rather than a confirmed live credential, users following this pattern with real credentials would persist those credentials as plaintext. Any local account, process, backup system, artifact collector, or source-control operation capable of reading the project directory could consequently expose them.

Attack Path

1. A user follows the documented example and passes a real API token to set_module_value.
2. The helper writes the token into the project-level common_info.yaml file.
3. The configuration file is created or retained with permissions that permit another local process or user to read it, or it is unintentionally committed, archived, or included in build artifacts.
4. The unauthorized party reads the plaintext token.
5. The token is used against the associated service with whatever privileges were granted to that credential.

Impact Assessment

Exploitation can disclose API credentials or other sensitive configuration values placed in the shared YAML file. The resulting privileges are limited to those granted to the exposed credentia ...[truncated 390 chars]

Remediation

View remediation

Remediation Suggestions

• Remove examples that store API tokens, passwords, private keys, or other credentials in the shared YAML file.
• Recommend a dedicated secret manager, operating-system credential store, or environment-based secret injection for sensitive values.
• If sensitive-file storage is unavoidable, create the file with owner-only permissions and verify permissions before every read or write.
• Separate non-sensitive shared configuration from secrets and clearly document that common_info.yaml must not contain credentials.
• Ensure configuration and backup files are excluded from source control, build artifacts, logs, and diagnostic bundles.
• Redact sensitive keys such as token, password, secret, and api_key from debug output.
• Use short-lived, narrowly scoped credentials and provide a documented rotation procedure for potentially exposed tokens.
• Add implementation-level tests that verify secure permissions, redaction, and protection against accidental secret serialization.

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

Natural-Language Policy Violations

Medium

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

Finding

The skill description and most instructional content are presented in Chinese, with no indication that users may choose another language or that the locale is intentionally limited. Under the policy, a language constraint should be optional or clearly justified.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The skill explicitly encourages cross-process sharing through a project-root YAML file and documents write/delete operations without a prominent warning that it modifies project files and may store sensitive runtime data such as tokens, temp IDs, and file paths. In this context, the danger is increased because the shared file is central, automatically created, and intended for inter-process coordination, which can lead to unintended persistence of secrets, accidental overwrites, or destructive deletion in a user's workspace.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.