T08 · Insecure Dependencies
- Location
scripts/setup_runner.sh:44- Finding
Unpinned Third-Party Package Is Downloaded and Executed
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill mostly matches its Naver Blog publishing purpose, but it asks users to run unpinned remote runner code and includes privileged admin fallback paths that should be reviewed before installation.
Install only if you trust the publisher and the npm runner package, understand that setup may run externally fetched code locally, and can ensure `OPENCLAW_OFFERING_EXECUTE_URL`, setup URLs, and any API keys point only to trusted HTTPS services. Avoid using or exposing the admin fallback in normal publishing flows.
scripts/setup_runner.sh:44Unpinned Third-Party Package Is Downloaded and Executed
scripts/publish.sh:145Sensitive Requests Can Be Sent to Unvalidated Environment-Controlled Destinations
The skill documents shell command execution but does not declare any explicit tool scope or allowed-tools boundary. That increases the chance an agent will invoke shell capabilities unexpectedly or more broadly than intended, which is risky in a skill that handles local daemons, tokens, and publishing actions.
The activation description is broad enough to match common requests like writing or publishing a post, setup recovery, or login help without tightly constraining when this commerce-connected skill should run. In context, that matters because the skill can trigger local shell actions, onboarding flows, and paid execution paths, increasing the chance of unintended invocation.
Using npx @y80163442/naver-thin-runner login without a pinned version allows the latest package version to be fetched at execution time, creating a supply-chain risk. If the package is compromised or a breaking/malicious update is published, the skill could execute untrusted code on the buyer's local machine.
The documentation describes a fallback to direct /v2/jobs/dispatch-and-wait even though the skill is presented as a marketplace-mediated paid publishing flow. This creates a scope-expansion path that could bypass normal offering controls, billing, policy enforcement, or approval boundaries if an agent or operator uses the fallback.
Mentioning ACP_ADMIN_API_KEY for internal debugging exposes the existence of privileged administrative capability in a user-facing skill context unrelated to ordinary Naver publishing. Even without the key value present, this can encourage misuse, increase attack surface, and blur separation between customer and admin operations.
The markdown exposes an internal fallback path that uses ACP_ADMIN_API_KEY but does not prominently warn that this is a highly sensitive administrative credential. In a skill meant for publication workflows, casually documenting an admin key increases the chance of misuse, unsafe storage, leakage into logs/shell history, or accidental use of a privileged path outside intended ops contexts.
The setup instructs users to run npx @y80163442/naver-thin-runner without pinning an exact package version. This creates a supply-chain risk: a later malicious or compromised package release could be fetched and executed automatically in a workflow that appears to handle login and publishing, likely with access to tokens and browser/session state.
The script constructs a JSON payload containing PROOF_TOKEN and DEVICE_FINGERPRINT and sends it via curl to SETUP_ISSUE_URL. There is no confirmation prompt, visible log/print statement, or explanatory comment/docstring disclosing that potentially sensitive identifiers are being transmitted.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
local code
code="$({
curl -sS -o "$tmp_body" -w '%{http_code}' \
-X POST \
-H 'content-type: application/json' \
-d "$payload" \
The script collects blog content, runner attestation, sealed payload metadata, and idempotency data, then transmits them to local and remote services without any explicit disclosure or consent mechanism in the script. In this skill context, the transmission is expected for publishing, but the lack of clear trust-boundary signaling increases the risk of unintended data handling and makes misuse harder for operators to detect.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
)"
seal_code="$({
curl -sS -o "$seal_tmp" -w '%{http_code}' \
-X POST \
-H 'content-type: application/json' \
-H "x-local-token: ${X_LOCAL_TOKEN}" \
This code transmits execution requirements, including attestation and sealed payload data, to a remote endpoint with an API key, but performs no validation of the destination URL or enforcement of HTTPS. If the endpoint is misconfigured or attacker-controlled via environment variables, sensitive job metadata could be sent to an untrusted service.
if [[ -n "$OFFERING_API_KEY" ]]; then
execute_code="$({
curl -sS -o "$exec_tmp" -w '%{http_code}' \
-X POST \
-H 'content-type: application/json' \
-H "${OFFERING_API_KEY_HEADER}: ${OFFERING_API_KEY}" \
This branch sends the same execution payload to a remote endpoint without any authentication header when OFFERING_API_KEY is absent. That increases the chance of accidental disclosure to an unintended service and could allow unauthenticated submission to any endpoint supplied through configuration.
} || true)"
else
execute_code="$({
curl -sS -o "$exec_tmp" -w '%{http_code}' \
-X POST \
-H 'content-type: application/json' \
-d "$execute_body" \
The script contains a fallback path that bypasses the stated marketplace/offering execute flow and instead submits jobs directly to the control plane using an admin API key. That creates a privilege-boundary violation: anyone able to run this script with those environment variables can dispatch jobs with elevated authority, increasing the blast radius of misconfiguration, abuse, or secret leakage.
This POST sends job requirements to the control plane using an admin API key, which is a highly privileged credential. If the URL or environment is compromised, the script could disclose a powerful secret and allow unauthorized job dispatches or broader administrative abuse.
fi
dispatch_code="$({
curl -sS -o "$exec_tmp" -w '%{http_code}' \
-X POST \
-H 'content-type: application/json' \
-H "x-api-key: ${ADMIN_KEY}" \
The script invokes npx @y80163442/naver-thin-runner setup without pinning an exact package version, so execution depends on whatever version is currently resolved from the registry. In a setup flow that handles onboarding and credential-adjacent operations, this creates a supply-chain risk: a compromised publisher account, malicious update, or dependency takeover could cause arbitrary code execution on the user's machine.
The script executes externally fetched package code via npx during a setup path without any confirmation, trust prompt, or safety warning. Because this skill is specifically designed to bootstrap a local runner for paid-service execution and onboarding recovery, the command is likely to be run on an end-user machine with meaningful local access, making silent remote code execution through package resolution especially dangerous.
The script forwards PROOF_TOKEN, SETUP_ISSUE_URL, and DEVICE_FINGERPRINT to an external package command with no user-facing disclosure or consent checkpoint in the file. In this skill's context, those values are part of an onboarding and device-binding flow, so silently transmitting them to remotely sourced code increases privacy, tracking, and token-misuse risk if the package or its telemetry behavior is compromised.
The echoed next-step guidance tells the user to run npx @y80163442/naver-thin-runner login without a pinned version, extending the same unpinned supply-chain risk into the manual login step. Even though this line is not immediate execution by the script, it operationalizes insecure instructions that may lead users to run arbitrary updated code later.
This markdown file includes operational guidance such as 'Internal fallback only' and 'Use only for debugging/ops' but does not clearly define when this path should be used versus avoided beyond a brief note. Because SQP-1 applies to markdown files, this ambiguous activation condition can lead to unintended use of the fallback path.