Skillv1.0.0

ClawScan security

Package Detection Skill | 包裹检测技能 · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousApr 16, 2026, 6:04 AM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The package-detection skill appears to implement remote API calls for package detection, but there are several incoherences and unexplained behaviors (copied health/face-analysis content, broad common/shared modules, implicit local config/DB access, and file-saving instructions) that warrant caution before installing or using it.
Guidance: Key things to consider before installing or using this skill: - Incoherent documentation: The SKILL.md mixes package-detection text with unrelated health/face-analysis content — this indicates copy-paste reuse and increases the code footprint. Treat that as a sign to inspect the code before trusting it. - Network behavior: The scripts call remote APIs (default base URLs in skills/smyx_common config point to lifeemergence.com domains). If you plan to use this, verify the API endpoints, who operates them, and whether you trust them. Do not supply sensitive credentials or an open-id until you confirm the endpoint and operator. - Local persistence and file saving: The skill will accept uploads and the documentation instructs saving attachments to disk. The included DAO can create SQLite files under the workspace 'data' directory. If you have privacy concerns, run it in an isolated/sandbox environment and review where files are written. - Environment/credential mismatch: Although the registry claims no required env vars, the code reads several environment variables and configuration files. Check skills/smyx_common/scripts/config.yaml and the workspace config path(s) that the SKILL.md references. The open-id acquisition rules are strict; ensure you understand what identifier the skill expects and why. - Review RequestUtil / network code: The shared util module likely implements HTTP calls and auth headers. Inspect skills/smyx_common/scripts/util.py to confirm what information is sent to remote servers (file contents, headers, tokens) before providing real data. - Minimize risk: If you need this capability, run the skill in a controlled environment (isolated container or VM), avoid passing real credentials/open-ids until you verify endpoints, and confirm attachments are deleted after processing if required. If you want, I can: - Summarize exactly which files/functions perform network calls and where they send data (I can scan util.py, api_service classes, and the package_detection flow). - Highlight where files are written on disk and list the exact paths constructed by the code. - Suggest a minimal sandboxed test procedure to validate behavior safely.

Review Dimensions

Purpose & Capability: concernThe declared purpose (detect delivery packages) matches the presence of scripts that call a remote AI analysis API and formatting/report logic. However the SKILL.md contains large, unrelated paragraphs about Parkinson's/face-based health monitoring and the package skill reuses a full face_analysis and smyx_common codebase—this looks like copy-paste reuse, increasing the footprint beyond what a simple package-detector needs. The included modules (face_analysis, smyx_common) contain many features (DAO, DB, many config options) that are not justified by the one-line description.
Instruction Scope: concernRuntime instructions mandate strict behaviors (never read local memory files, must fetch historical reports only from cloud via a specific CLI invocation, must save uploaded attachments to an attachments folder). The code requires an --open-id and loads configuration from skills/smyx_common/scripts/config.yaml or workspace config, so it expects local file reads and environment access despite the SKILL.md forbidding local memory access by the agent. The SKILL.md also instructs to save user-uploaded files to disk — that is normal for processing but broadens data persistence surface and contradicts other rules in the doc.
Install Mechanism: okNo install spec (instruction-only at platform level) and code is included directly. That is lower risk than an installer that downloads arbitrary binaries; however, many Python modules are bundled (skills/smyx_common) and the requirements files reference numerous third-party packages, increasing attack surface if dependencies are later installed.
Credentials: noteThe registry metadata declares no required environment variables or credentials, but the code reads several environment variables (e.g., OPENCLAW_SENDER_OPEN_ID, OPENCLAW_SENDER_USERNAME, FEISHU_OPEN_ID) inside ConstantEnum.init and relies on config files for API endpoints and api-key. The SKILL.md enforces an open-id lookup procedure that reads local config files under the skill and workspace. The skill can accept an optional API key and will call external API endpoints; requesting an open-id and optionally an api-key is plausible for a cloud API integration, but the presence of many unrelated config options and a local SQLite DAO (which writes under workspace/data) is disproportionate for a small package-detection utility.
Persistence & Privilege: concernThe codebase includes a local DAO (SQLite + SQLAlchemy) and logic that constructs a workspace data path (based on OPENCLAW_WORKSPACE), so the skill can create and read local DB files under the workspace. SKILL.md also mandates saving uploaded attachments into the skill directory. While 'always' is false (not force-installed) and autonomous invocation is allowed (default), the combination of local persistence, automatic file saving, and broad common modules increases the blast radius if misused.