neon-postgres

MEDIUM W011: Third-party content exposure detected (indirect prompt injection risk).

• Third-party content exposure detected (medium risk: 0.65). The required runtime workflow can fetch Neon documentation pages via curl https://neon.com/docs/<path> (public web content), which is outsider-authored free text that may be ingested into the agent’s LLM context.

MEDIUM W012: Unverifiable external dependency detected (runtime URL that controls agent).

• Potentially malicious external URL detected (high risk: 0.90). The skill explicitly instructs the agent to fetch documentation at runtime (e.g., curl https://neon.com/llms.txt and curl -H "Accept: text/markdown" https://neon.com/docs/) and treats those fetched docs as the "source of truth" to drive responses, so these runtime URL fetches directly control the agent's prompts/context.

HIGH W008: Secret detected in skill content (API keys, tokens, passwords).

• Secret detected (high risk: 1.00). I scanned the entire skill documentation for literal, high-entropy credentials that would be usable if copied. I ignored placeholder names and environment variable names (e.g., NEON_API_KEY, NEXT_PUBLIC_NEON_AUTH_URL) because those are not secret values.

I found multiple high-entropy secret-like values embedded verbatim in example responses / code samples (not placeholders or truncated). Examples include:

• An API key-like token in references/neon-rest-api/keys.md example response:
• "napi_9tlr13774gizljemrr133j5koy3bmsphj8iu38mh0yjl9q4r1b0jy2wuhhuxouzr" This is a long, random-looking token (API-key style) shown as a created key.
• Several database passwords / connection URIs in example JSON responses (neon-rest-api and projects/branches examples):
• "postgresql://neondb_owner:npg_EwcS9IOgFfb7@ep-raspy-glade-ad8e3gvy.c-2.us-east-1.aws.neon.tech/neondb?sslmode=require" (contains password "npg_EwcS9IOgFfb7")
• "postgresql://neondb_owner:npg_N67FDMtGvJke@ep-round-unit-afbn7qv4.c-2.us-west-2.aws.neon.tech/neondb?sslmode=require" (contains password "npg_N67FDMtGvJke")
• "postgresql://neondb_owner:npg_IDNnorOST71P@ep-shiny-morning-a1bfdvjs-pooler.ap-southeast-1.aws.neon.tech/neondb?channel_binding=require&sslmode=require" (contains password "npg_IDNnorOST71P")
• The roles section in one example also includes a clear-text role password: "password": "npg_N67FDMtGvJke"

These values are neither placeholders nor truncated, and they appear to be real, high-entropy secrets (API key and DB passwords/connection strings) that would grant access if valid. Therefore they meet the definition of a secret and should be flagged.

I did NOT flag environment variable names or endpoints like ep-xxx hostnames by themselves, nor generic example emails, because those are not secrets per the rules.