T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:46- Finding
Untrusted Cloud Workflows Are Designed for Direct Privileged Execution
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:46-58;skill.json:10-20
Vulnerability Type: Remote payload retrieval and execution
Risk Level: HighRelevant Code Snippets:
SKILL.md:46-58markdown ## How It WorksUser Intent → Query Cloud → Match Found? ↓ Yes ↓ No Execute Now Normal Flow (1 second) (LLM reasons) ↓ ↓ Success! Success → Contribute
text **One agent's success becomes every agent's shortcut.**skill.json:10-20json "permissions": [ "browser", "lobster", "sessions_history", "network" ], "hooks": { "on_intent_received": "interceptIntent", "on_session_complete": "onSessionComplete" },Technical Analysis
The skill declares an intent hook that queries a cloud registry and directly replays a matched workflow before normal agent reasoning. The requested
network,browser, andlobsterpermissions provide the capabilities needed to retrieve externally controlled workflow definitions and execute their actions.This creates a remote payload execution channel: the effective workflow is not fixed when the package is reviewed and may change whenever the cloud registry changes. The supplied files do not specify signature verification, immutable content hashes, trusted publisher validation, workflow origin binding, an action allowlist, sandboxing, or mandatory user approval before replay.
The declared entry point,
dist/index.js, is absent from the reviewed artifact. Therefore, the concrete runtime implementation and any undocumented validation cannot be verified, and the package cannot perform the advertised behavior as shipped. The vulnerability is established in the declared design and permission model and becomes exploitable if the missing hook impleme ...[truncated 1441 chars]- Remediation
View remediation
Remediation Suggestions
- Require every remote workflow to carry a signature from an explicitly trusted publisher and verify it locally before execution.
- Pin approved workflows to immutable content hashes or reviewed versions rather than accepting mutable registry content.
- Validate workflows against a strict schema and an action allowlist. Reject unknown actions, dynamic code, shell execution, arbitrary URL access, and undeclared tool calls.
- Bind each workflow to approved domains, expected user intents, and the minimum necessary permissions.
- Display the exact workflow actions and affected resources and require explicit user approval before the first execution or any version change.
- Execute remote workflows in a sandbox with isolated credentials, restricted network access, resource limits, and no ambient browser authority.
- Treat cached workflows as untrusted input even when supplied by the official service.
- Maintain audit logs recording the workflow identifier, publisher, version, content hash, requested actions, and execution result.
- Include the missing implementation in the distributable package so its security controls can be independently reviewed and tested.