Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly coherent for fetching Bilibili creator metrics, but it under-warns about optional session cookies and uses broad install/update instructions for an external CLI.
Install only if you are comfortable using the qhkit CLI and Qinghu credits. Avoid providing Bilibili cookies unless strictly necessary, treat them as account secrets, and prefer a pinned or preinstalled qhkit version rather than ad hoc npx/latest installation.
The description says the skill 'must trigger' for broad classes of requests about Bilibili creator data, which can cause over-activation on ambiguous user prompts. In practice this increases the chance of unnecessary tool invocation, unintended data access, and avoidable paid API calls without sufficiently precise user intent.
The invocation examples are generic enough to overlap with many ordinary questions about Bilibili creators, making accidental triggering more likely. Because this skill can lead to external calls and billing, vague activation criteria create both privacy and cost-exposure risk.
The skill accepts an optional Bilibili cookie parameter but does not prominently warn that cookies are authentication/session secrets. Users may paste a live session cookie without understanding that it can expose or transfer account access, especially if echoed in logs, shell history, files, or downstream services.
The skill instructs use of npx @iqinghu/qhkit without pinning a version, which makes execution depend on whatever package version is current at runtime. That creates supply-chain and reproducibility risk: a future compromised or incompatible release could be fetched and executed automatically.
This repeated finding points to the same persistence behavior: installing Node under the user's home directory and instructing PATH modification for future command availability. In a skill context, self-bootstrap that alters the host environment is risky because it normalizes stateful changes unrelated to the immediate data lookup task.
cd /tmp && curl -fsSLO https://nodejs.org/dist/v22.22.3/node-v22.22.3-linux-x64.tar.xz cd /tmp && curl -fsSL https://nodejs.org/dist/v22.22.3/SHASUMS256.txt | grep ' node-v22.22.3-linux-x64.tar.xz$' | sha256sum -c - mkdir -p "$HOME/.local/lib" && tar -xJf /tmp/node-v22.22.3-linux-x64.tar.xz -C "$HOME/.local/lib" export PATH="$HOME/.local/lib/node-v22.22.3-linux-x64/bin:$PATH"
This repeated finding points to the same persistence behavior: installing Node under the user's home directory and instructing PATH modification for future command availability. In a skill context, self-bootstrap that alters the host environment is risky because it normalizes stateful changes unrelated to the immediate data lookup task.
cd /tmp && curl -fsSLO https://nodejs.org/dist/v22.22.3/node-v22.22.3-linux-x64.tar.xz cd /tmp && curl -fsSL https://nodejs.org/dist/v22.22.3/SHASUMS256.txt | grep ' node-v22.22.3-linux-x64.tar.xz$' | sha256sum -c - mkdir -p "$HOME/.local/lib" && tar -xJf /tmp/node-v22.22.3-linux-x64.tar.xz -C "$HOME/.local/lib" export PATH="$HOME/.local/lib/node-v22.22.3-linux-x64/bin:$PATH"
No suspicious patterns detected.