Cursor2api Skill Clawhub

• Outcome: Review
• Latest audit: May 29, 2026, 9:28 PM
• Version:
  1.0.2

Overview

This skill has a coherent proxy purpose, but it asks users to expose a sensitive Cursor session token to an unpinned third-party Docker service and documents unsafe token-handling patterns.

Install only after reading the docs carefully and only if you trust the third-party cursor-api container with your Cursor session cookie. Keep the proxy local when possible, do not send tokens over plain HTTP, avoid storing the token in shell startup files or command history, prefer a reviewed or pinned container image, and rotate/revoke the Cursor session token if it may have been exposed.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (7)

Intent-Code Divergence

Medium

• Confidence: 96% confidence
• Finding: The document warns against storing the session token in plaintext, but the provided workflow still passes the token directly as a shell argument and injects it into a container environment variable. That can expose the token through shell history, process listings, terminal logs, and container inspection, undermining the stated security guidance.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The documentation tells users to export a sensitive API/session token from shell startup files like ~/.zshrc or ~/.bashrc, which makes the secret persist across sessions and increases exposure through local file disclosure, backups, shell history mistakes, and accidental sharing of dotfiles. In a configuration guide, this is dangerous because it normalizes long-lived plaintext credential storage without any warning or safer alternative.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The remote-server example sends an authentication token to an http:// endpoint rather than HTTPS, exposing the credential to interception or modification by anyone with network visibility between client and server. Because this is a remote-access scenario, the lack of TLS materially increases risk of credential theft, session hijacking, and tampering with API traffic.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The example stores a sensitive token in a local rc file and sources it, but provides no guidance on file permissions, exclusion from version control, or secret lifecycle handling. This encourages plaintext secret storage in a reusable file that may be exposed through backups, multi-user systems, misconfigured permissions, or accidental publication.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The installation guide instructs users to supply a `WorkosCursorSessionToken` directly to Docker as an environment variable and provides no warning about secure storage, rotation, least-privilege handling, or the risk of exposing a session token in shell history, process listings, logs, or shared compose files. Because this is a session credential rather than a clearly scoped API key, mishandling could allow unauthorized use of the associated account or service session.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The instructions repeatedly show the sensitive session token embedded in shell commands and as a positional script argument. Command-line arguments and environment variables are commonly exposed via shell history, audit logs, crash reports, `/proc`, and process inspection tools, so this creates a realistic credential leakage path.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The script accepts a sensitive session token as a command-line argument and injects it into a container environment variable. Tokens passed this way can be exposed through shell history, process listings, Docker inspection, or logs, increasing the risk of credential disclosure to local users or administrators on the host.

VirusTotal

65/65 vendors flagged this skill as clean.