Is eric51/ollama-x-z-image-turbo safe?
https://github.com/openclaw/skills/tree/main/skills/eric51/ollama-x-z-image-turbo
This skill generates images via a local Ollama model and automatically dispatches the output via WhatsApp, creating a built-in external data transmission channel that operates on every invocation. The skill is non-functional outside the author's macOS machine due to hardcoded absolute paths, and the WhatsApp integration targets an unofficial endpoint rather than the authenticated WhatsApp Business API. No credential harvesting code was found in the Python sources, the git clone was clean, and canary files were unmodified; however, the mandatory WhatsApp dispatch step combined with an agent-resolved recipient field represents a meaningful exfiltration risk if the skill is chained with others or the recipient field is manipulated via prompt injection.
Category Scores
Findings (7)
HIGH WhatsApp dispatch creates mandatory external data transmission channel -35 ▶
SKILL.md encodes a two-step workflow where every image generation is followed by a WhatsApp message send. The 'to' field is agent-resolved at runtime and not constrained to user-controlled values. This makes the WhatsApp step an embedded exfiltration conduit: any file placed at /Users/openclaw/.openclaw/workspace/tmp/ollama_image.png — regardless of how it got there — will be dispatched externally. A malicious actor who gains control of the 'to' field (e.g., via prompt injection in a chained skill) can redirect all generated images to an attacker-controlled phone number.
MEDIUM Skill hardwires pty=true execution, bypassing standard exec monitoring -15 ▶
SKILL.md marks pty=true as 'obligatoire' (mandatory) when running the runner.py script, claiming Ollama requires a TTY. Ollama's CLI does not require a TTY for API-based or batch invocations. PTY allocation allocates a pseudo-terminal that can mask subprocess output from standard pipe-based logging and can make process ancestry harder to trace. This is a low-severity concern in isolation but unusual for a legitimate image generation workflow.
MEDIUM Unsanitized user prompt passed to subprocess ollama invocation -15 ▶
runner.py constructs the ollama CLI command as a list (safe from shell injection) but passes the raw user prompt as a positional argument. If Ollama or downstream model behavior is sensitive to specially crafted prompts, or if Ollama's --format json output parsing mishandles adversarial input, unexpected behavior could result. The risk is contained to the Ollama process boundary but warrants attention.
MEDIUM whatsapp_integration.py exposes unauthenticated FastAPI HTTP server -20 ▶
whatsapp_integration.py and generate_image.py each define FastAPI applications with no authentication, no rate limiting, and no origin validation. If started (e.g., by an agent following instructions in a future skill update), these servers accept arbitrary image generation and WhatsApp dispatch requests from any local or network client.
LOW Skill non-functional outside author's macOS machine due to hardcoded absolute paths -12 ▶
All executable paths in SKILL.md reference /Users/openclaw/.openclaw/..., which is the skill author's personal macOS home directory. This makes the skill inoperable on any other system and raises questions about why it was published to a shared store. It could indicate the skill was inadvertently published, or that it is designed to function only when the skill author's environment is present (e.g., in a controlled demo or malicious context).
LOW WhatsApp integration targets unofficial share URL, not authenticated API -10 ▶
whatsapp_integration.py POSTs to https://api.whatsapp.com/send with a JSON body, but this is the WhatsApp web share link endpoint, not the official WhatsApp Business API. The endpoint does not accept JSON POSTs in this form. This suggests either the code is non-functional as written, or it relies on a browser session/cookie from the host environment to authenticate — which would mean it piggybacks on the user's WhatsApp login.
INFO Canary credential files accessed twice during audit window -5 ▶
inotify and auditd records show two sets of opens against all canary files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, GCP credentials). The first set at 09:35:34 predates the git clone (09:35:39) and is attributable to the audit framework's baseline check. The second set at 09:35:51 postdates installation and likely corresponds to post-install integrity verification. No skill code reads these paths. The audit system confirms all files are unmodified.