Is adebayoabdushaheed-a11y/afame safe?

The skill's registry metadata declares slug 'afame', display name 'fame graphic', and owner 'adebayoabdushaheed-a11y', but the SKILL.md frontmatter declares name 'creative-illustration', and package.json uses name 'creative-illustration' with author 'jack happy'. Additionally, the _meta.json commit URL references the repository github.com/clawdbot/skills while the installation clone was performed from github.com/openclaw/skills.git. This three-way identity conflict is inconsistent with a legitimately published skill and is a common pattern in typosquatting or skill-hijacking scenarios where malicious content is inserted under a misleading identity.

The illustrate.py script determines the OpenAI API endpoint by reading OPENAI_BASE_URL or OPENAI_API_BASE environment variables before falling back to https://api.openai.com. If either variable is set to an attacker-controlled server — through a compromised .env file, a second malicious skill, or a poisoned environment — the OpenAI API key (passed via Authorization header) and all image generation prompts would be transparently forwarded to the attacker. The API key value and full prompt content would be exfiltrated without any error or user-visible indication.

Filesystem monitoring (inotifywait and auditd) recorded OPEN and ACCESS syscalls on six credential honeypot files: ~/.env, ~/.ssh/id_rsa, ~/.aws/credentials, ~/.npmrc, ~/.docker/config.json, and ~/.config/gcloud/application_default_credentials.json. These accesses occurred twice — once pre-install at epoch 1771651595 and once post-analysis at epoch 1771651617. The Python script (illustrate.py) contains no code paths that read these files. Timing and event sequencing is consistent with oathe's own canary baseline and post-install verification reads. Canary integrity monitoring confirms no data left the host. Filed as MEDIUM rather than CRITICAL solely because the monitoring system's own canary checks explain the access pattern.

Every shell command example in SKILL.md invokes the script at ~/Projects/agent-scripts/skills/creative-illustration/scripts/illustrate.py. This path will not exist after installation via the standard skills installer (which places files at a different location). When an agent follows these instructions, it will either receive a file-not-found error or may attempt to resolve the path by searching or creating directories. This degrades usability and could cause the agent to write files or create structures in ~/Projects/agent-scripts/ rather than the intended output directory.

The script accepts the OpenAI API key via the --api-key command-line argument. When an agent passes the key this way, it is visible in /proc//cmdline to any process with read access to the proc filesystem, and may be captured in shell history, audit logs, or container orchestration logs. The preferred approach — environment variable only — is supported but not enforced.

The --out-dir parameter is passed directly to os.makedirs(out_dir, exist_ok=True) and then used as the base path for all file writes (PNG images, prompts.json, index.html). No path sanitization or confinement is applied. If an agent is manipulated into passing an attacker-controlled out-dir value, the skill could write files to sensitive locations (e.g., ~/.ssh/, ~/.bashrc parent directories, web server roots).

The install process made exactly the expected network connections: a DNS lookup followed by a single HTTPS session to 140.82.121.4:443 (github.com) for a shallow sparse git clone of the skill subdirectory. The temporary clone directory (/tmp/monorepo-clone) was removed after copying. No new listening services, no persistent outbound connections, and no writes outside the installation target directory were detected.