Back to skill

Security audit

Convex Deploy Env Doctor

Security checks for vulnerabilities and agentic risk

Overview

This skill is a small Convex configuration troubleshooting guide with disclosed env-file and connectivity checks, and no bundled executable code or persistence.

Install only for Convex projects. When using it, ask the agent to inspect only needed Convex-related env keys, redact values, and avoid contacting any backend URL you do not recognize or control.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:10
Finding

Overbroad Access to Sensitive Environment Files

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 10-12
Vulnerability Type: Sensitive-data exposure through excessive file access
Risk Level: Medium

Vulnerable Code:

markdown
1. Detect project config surface
- Check `.env`, `.env.example`, runtime defaults in source, README/SKILL docs.
- Extract all Convex URLs and callback URLs.

Technical Analysis

The workflow instructs the agent to inspect .env files in their entirety. Such files commonly contain API keys, access tokens, passwords, and credentials unrelated to Convex. Although the guardrail at SKILL.md:41 states, “Never print secrets,” it does not prevent secrets from being loaded into the agent context, retained in execution traces, or exposed to associated tooling.

The instruction does not enforce key allowlisting, local parsing, value redaction, or least-privilege access. The task only requires Convex URLs and callback settings, so reading all environment-file content exceeds the access necessary to complete the stated purpose.

Attack Path

  1. A project contains unrelated credentials or tokens in its .env file.
  2. A user invokes the skill to diagnose Convex deployment configuration.
  3. The workflow causes the agent to inspect the complete .env file.
  4. Unrelated secrets enter the agent's processing context or tool execution records.
  5. Those values may consequently become accessible through logs, traces, accidental output, or downstream processing, even if the final response attempts not to print them.

Impact Assessment

The issue may expose any credentials stored in project environment files to the agent and its supporting infrastructure. The potential scope includes third-party services, databases, cloud platforms, deployment systems, or production resources associated with those credentials.

This instruction does not itself grant additional operating-system privileges or prove that secrets are exfiltrated ...[truncated 123 chars]

Remediation
View remediation

Remediation Suggestions

  1. Replace whole-file inspection with local parsing of an explicit allowlist of required variables, such as CONVEX_URL and specifically documented callback URL keys.
  2. Return only variable names, presence status, validation results, and redacted URL metadata to the agent.
  3. Never place complete .env contents or secret values into model context, command output, reports, logs, or traces.
  4. Redact URL credentials, sensitive query parameters, fragments, tokens, and user information before analysis or display.
  5. Document the exact environment keys the skill is permitted to inspect.
  6. Require explicit user approval before examining any additional key not included in the allowlist.
  7. Add a guardrail stating that secret-bearing files must be parsed with a secret-safe local mechanism rather than read directly.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:23
Finding

Configuration-Controlled HTTP Reachability Checks Lack Destination Restrictions

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 23-25
Vulnerability Type: Unrestricted outbound request and SSRF-like behavior
Risk Level: Medium

Vulnerable Code:

markdown
4. Connectivity sanity check
- Run lightweight checks (lint/build and safe HTTP reachability if possible).
- Confirm configured backend is HTTPS and syntactically valid.

Technical Analysis

The skill permits HTTP reachability checks against URLs obtained from project configuration but does not define what makes such a request safe. Requiring HTTPS and syntactic validity does not establish destination trust. HTTPS URLs may still resolve to loopback, private-network, link-local, cloud metadata, internal service, or attacker-controlled addresses.

The workflow also does not prohibit redirects, DNS rebinding, nonstandard ports, credential forwarding, sensitive query parameters, or request bodies. Consequently, a malicious or compromised project can influence the destination contacted by the agent environment and cause blind server-side request forgery-like behavior.

Attack Path

  1. An attacker places a crafted HTTPS backend URL in project configuration or documentation.
  2. A user invokes the skill to validate the deployment configuration.
  3. The skill extracts the attacker-controlled URL.
  4. Following the connectivity-check instruction, the agent sends a reachability request to that destination.
  5. The destination may be an internal service, loopback listener, private-network host, link-local endpoint, metadata service exposed through an HTTPS-capable proxy, or attacker-operated server.
  6. The attacker may infer reachability from timing or reported status, or receive request metadata if the destination is attacker-controlled.

Impact Assessment

An attacker may induce outbound requests from the environment running the skill, enabling limited internal-network probing, service discovery, or interaction with en ...[truncated 459 chars]

Remediation
View remediation

Remediation Suggestions

  1. Restrict connectivity checks to an explicit allowlist of approved Convex hostnames and expected domain suffixes.
  2. Canonicalize and validate the URL before making a request, including its scheme, hostname, resolved addresses, port, user-information component, query, and fragment.
  3. Reject loopback, private, link-local, multicast, reserved, and cloud metadata address ranges for both IPv4 and IPv6.
  4. Resolve the hostname and verify every resulting address immediately before connection to mitigate DNS rebinding and time-of-check/time-of-use issues.
  5. Disable redirects, or revalidate every redirect destination using the same restrictions.
  6. Permit only HTTPS on the expected port and use a lightweight request with strict time and response-size limits.
  7. Send no credentials, cookies, authorization headers, secret query parameters, request bodies, or project data.
  8. Require explicit user confirmation before contacting a destination outside the documented Convex domain allowlist.
  9. Record only redacted destination and status information in the data-routing disclosure.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.