Is dryoo/naver-shopping safe?
https://github.com/openclaw/skills/tree/main/skills/dryoo/naver-shopping
The dryoo/naver-shopping skill is a straightforward Naver Shopping search client that wraps the official Naver Search API. Its code surface is minimal and contains no prompt injection, no malicious exfiltration logic, and no install-time execution. The primary operational concern is a developer oversight: all SKILL.md usage examples reference the author's local machine path, which will cause agent invocations to fail on any other system. The skill is safe to install but requires users to fix the script path and configure Naver API credentials before it will function.
Category Scores
Findings (4)
LOW Hardcoded developer-local path in SKILL.md usage examples -8 ▶
All usage examples in SKILL.md reference an absolute path specific to the skill author's local machine (/Users/dryoo/.openclaw/workspace/skills/naver-shopping/scripts/search_shopping.py). An LLM agent following these instructions literally will invoke a path that does not exist on any other system, causing silent failures or prompting the agent to search for the script, potentially leading to unintended filesystem exploration. This appears to be a developer oversight from copying a local dev environment path rather than a relative or dynamically resolved path.
LOW API credentials transmitted to external Naver endpoint -12 ▶
The skill requires NAVER_Client_ID and NAVER_Client_Secret to be present in the process environment. These values are read via os.getenv() and sent as X-Naver-Client-Id and X-Naver-Client-Secret HTTP headers to openapi.naver.com on every search invocation. While this is the intended and declared behavior, it means any agent using this skill will transmit API credentials to an external Korean commercial API provider. Users should be aware that Naver receives both the credentials and all search queries.
INFO Python script included — benign -5 ▶
The skill ships a Python script (scripts/search_shopping.py) that executes when invoked. The script is well-contained: it imports only stdlib modules (os, sys, json, urllib.request, argparse), reads two environment variables, constructs a single HTTPS request to openapi.naver.com, and prints JSON to stdout. No dynamic code evaluation, no shell escapes, no subprocess calls.
INFO Canary credential files read during monitoring window — attributed to Oathe framework -10 ▶
The filesystem audit shows .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and GCP application_default_credentials.json were opened at 11:25:48 (before the git clone) and again at 11:26:11 (after install completion). No skill code had been installed at the first access time, and the files were all opened CLOSE_NOWRITE (read-only). The identical access pattern at both timestamps and the absence of any write or exfiltration syscalls is consistent with the Oathe monitoring framework scanning its canary files as part of pre/post-install integrity baseline checks. The canary integrity report confirms all files are intact.