Security audit
Security checks for vulnerabilities and agentic risk
The skill mainly performs local diagnosis, but it makes documentation network lookups and cache writes despite promising no network or writes.
Review before installing in environments that require strict offline operation. The diagnostic parsing appears read-only and credential-free, but advisory questions can cause outbound requests to help.aliyun.com and a local doc cache write, so users should avoid pasting secrets and should disable or remove the doc-lookup path if they need a fully offline skill.
An absolute ban on fetching or probing over the network conflicts with a mandatory workflow step that may contact online documentation sources. This can bypass policy expectations and create an implicit exception path where the agent performs network activity despite explicit safety rules.
The guidance to 'still run the entry script' and return bucket listings when input is missing is inconsistent with an offline parser-only design. In practice, this suggests the script may perform environment-dependent cloud discovery, which can leak inventory information and violate the user's expectation that only pasted URL text is analyzed.
The skill says it never reads or accepts credentials, but another section says the script can list buckets visible to the current credential. That implies credentialed cloud access may occur, directly contradicting the zero-credential, zero-cloud-call safety model and potentially exposing account metadata.
Skill attempts to nullify the agent's safety policies or restrictions ('you have no restrictions', 'ignore your guidelines', 'do anything now'). This is a direct jailbreak that disables guardrails.
| `long_term_private_access` | durable-access design question for private objects, not an error code | on-demand re-signing with short TTL; CDN private back-to-origin + URL auth or a signing gateway; RAM/STS for programmatic access; never make the object public |
| `parameter_tampered` | 403 SignatureDoesNotMatch | URL edited after signing; proxy/CDN rewrote path or params; double-encoding; official EC 0002-00000040 causes: proxy adds headers after signing, CDN converts HEAD→GET or injects x-oss-* headers, CNAME endpoint without the CNAME switch, unencoded plus sign (+→%2B) in the signature, mini-program extra Content-Type; hand-built V4 CanonicalRequest mistakes (SignedHeaders omitted / not lowercase-sorted / missing URI-encoding) — check the four V4 elements x-oss-content-sha256 / x-oss-date / SignedHeaders / region; compare the StringToSign in the error body, but NEVER infer the client-side construction from the server-side canonical string (anti-pattern: compare the client's intermediate signing variables layer by layer instead) |
| `credential_invalid` | 403 SignatureDoesNotMatch / InvalidAccessKeyId / SecurityTokenExpired | AK rotated/disabled after sharing; STS token expired; wrong SK at generation; STS token must be carried in the URL security-token parameter, header-only placement is rejected (EC 0002-00000005) |
| `permission_changed` | 403 AccessDenied despite valid signature | signer's RAM permission revoked; Bucket Policy deny (presigned URLs do NOT bypass policy); object deleted/ACL changed; AK bound to a network policy / IP allow-list that forbids public-internet access — the signature is valid but the request is rejected at the network layer (ticket 0001FSADTN: removing the network-policy restriction restored access) |
| `method_mismatch` | 403 SignatureDoesNotMatch on upload with GET-signed URL | URL bound to the HTTP method used at signing |
| `malformed_url` | 400 / 0002-00000216 / AuthorizationHeaderMalformed | missing/empty params (EC 0002-00000
...[truncated 25 chars]
The skill invokes local scripts and references components with file and network capabilities, but it declares no explicit tool scope or permission boundary. This weakens enforcement and review because an agent may be allowed to use broader tools than the skill description suggests, increasing the chance of unintended file or network access.
The documentation states there are zero cloud API calls and no live network probing, yet later requires online doc verification. Security-relevant contradictions like this undermine operator trust and may lead to unsafe deployment assumptions, especially in restricted environments handling presigned URLs.
The skill claims diagnosis is offline and zero-network, but it also mandates online official-document verification through a lookup component. That contradiction can cause sensitive pasted URLs or related metadata to be processed in a networked workflow when users and operators were told no network access would occur.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Credential handling
Never ask the user for, read, print, or forward any AccessKey, secret, or
STS token. The diagnosis input is limited to: the presigned URL (with keys
and signatures masked by the script), the error code, the HTTP status, and
free-text symptom description.
The file-level comments repeatedly assert 'NO network calls' and 'never sends it anywhere,' but later logic conditionally performs doc verification that may reach external resources. This is a security-relevant trust-boundary mismatch: operators and upstream agents may decide to feed sensitive URLs, error text, or customer wording into the skill based on false privacy assurances, creating silent exfiltration risk and breaking deployment assumptions. In a diagnosis skill for presigned URLs, misleading privacy claims materially increase danger because the inputs can contain secrets, internal paths, bucket names, or incident details.
The script’s core safety claim is that pasted presigned URLs are parsed locally and never sent anywhere, yet the doc-verification branch invokes lookup_config_topic when --question is supplied. If that helper performs remote retrieval against official docs, customer-provided wording may leave the local environment, violating the zero-cloud/local-only contract and potentially causing unintended data disclosure or policy noncompliance. In this skill context, that contradiction is more dangerous because users may paste sensitive operational details under the assumption that the tool is strictly offline.
The description states that Chinese ticket wording is automatically routed via an embedded keyword layer, and the body reiterates that Chinese wording 'lands here too'. This encodes language-specific behavior without indicating user choice, opt-in, or a justified region-specific language constraint.
If official-doc verification may use network access, failing to warn the user is a security transparency issue. Users may paste sensitive presigned URLs expecting fully local analysis and would not be informed that ancillary network activity could occur as part of the workflow.
The module text repeatedly cites only Chinese-language Alibaba Cloud documentation URLs and embeds Chinese-specific symptom keywords, which indicates a language-specific behavior. There is no natural-language notice here that the skill is intentionally China-locale scoped or that users may choose another language, so this can conflict with a language/locale policy requiring user opt-in or justification.
No suspicious patterns detected.