Security audit
Security checks for vulnerabilities and agentic risk
The skill is a small markdown guide for exe.dev VM management; its sharing commands carry real exposure risk, but they are disclosed and aligned with the stated purpose.
Install only if you intend to let your agent help manage exe.dev VMs. Before using share commands, verify the VM, exposed port, reachable app data, and intended recipients; revoke public access or links when no longer needed. Treat X-ExeDev-UserID and X-ExeDev-Email as sensitive identity data in app logs and authorization logic.
The skill presents commands to make a VM public, add users, and generate share links as quick actions without any nearby warning about exposing services or changing access control. In infrastructure-management context, this can lead users to unintentionally publish internal apps or grant access broadly, increasing risk of data exposure or unauthorized access.
The markdown documents commands to make a VM public and generate share links, but it does not warn that these actions can expose services or data to unauthenticated or broader external access. For a skill description covering internet-accessible VMs and sharing, this is a user-impacting behavior that should be explicitly disclosed.
The skill documents forwarding user identifiers and email addresses in HTTP headers without warning about privacy handling or trust boundaries. Applications may log, store, or misuse these headers, and developers may incorrectly trust them without validating they originate from the exe.dev proxy path, leading to privacy exposure or authorization mistakes.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
ssh exe.dev ls --json # List VMs
ssh exe.dev new # Create VM
ssh exe.dev share set-public <vm> # Make public
ssh exe.dev share port <vm> <port> # Change proxy port
ssh exe.dev share add <vm> <email> # Add user
The example injects the header value 'user@example.com' as a fixed identity in natural-language guidance. While likely illustrative, it can be read as prescribing a specific identity format without explicitly telling users to replace it with their own value or choose an appropriate one.
No suspicious patterns detected.