Neon Database Complete Documentation

Security checks across malware telemetry and agentic risk

Overview

This is a documentation-only Neon/Postgres skill with some risky examples users should review before copying, but I found no hidden execution, persistence, exfiltration, or deceptive behavior in the skill itself.

Install only if you want a broad local Neon documentation corpus. Do not let an agent auto-run commands from it; review npx, MCP setup, API-key, database-migration, deletion, and cloud-permission examples yourself. Treat connection strings and Neon API keys as secrets, prefer read-only or least-privilege MCP/API access, and double-check copied code for SQL injection or overly broad permissions.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access

Findings (211)

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The documentation says it is using Azure OpenAI, but the sample config points to the public OpenAI endpoint (`https://api.openai.com`). This can cause developers to send data, prompts, or credentials to the wrong provider, creating a real security and compliance risk in environments where Azure-specific tenancy, regional controls, or contractual safeguards are required.

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The chat completion example repeats the same provider mismatch by labeling the code as Azure OpenAI while targeting the public OpenAI endpoint. In practice, this can misroute sensitive prompts and application data, undermine expected Azure security boundaries, and lead to deployment failures or accidental use of the wrong service.

Intent-Code Divergence

Medium

Confidence: 97% confidence
Finding: The document explicitly states that `cron.schedule_in_database()` is not supported in Neon, but then immediately gives instructions and a runnable example for using it. This contradictory guidance can mislead users into implementing unsupported behavior, causing failed automation, confusion during incident response, and potentially unsafe assumptions about cross-database job execution.

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The documentation incorrectly claims that a column default of `now` is evaluated once at table creation and then reused for future rows. In PostgreSQL, `now` in this context is not a one-time frozen table-creation value, so this guidance can cause readers to form an incorrect mental model of timestamp behavior and make bad schema or auditing decisions.

Context-Inappropriate Capability

Medium

Confidence: 97% confidence
Finding: The guide explicitly instructs users to attach the managed policy `AmazonS3FullAccess` to an IAM user created for this integration, which grants far broader permissions than are needed for presigned uploads and metadata tracking. If those credentials are exposed or misused, an attacker could list, read, overwrite, or delete objects and potentially alter bucket configuration across S3 resources available to that principal.

Intent-Code Divergence

Medium

Confidence: 92% confidence
Finding: The guide includes an example connection URI containing what appears to be an actual username, password, and host, rather than clearly redacted placeholders. Even in documentation, publishing credential-shaped values can normalize unsafe handling of secrets, mislead users into copying sensitive patterns, and, if the values are real or reused, expose access to a database endpoint.

Intent-Code Divergence

Medium

Confidence: 91% confidence
Finding: The guide defines the connection string under `TodoDbConnection` but the code reads `DefaultConnection`, which will cause the application to fail to connect or fall back to an unintended configuration if one exists. This is primarily a security-relevant misconfiguration risk rather than a direct exploit primitive, but in real deployments configuration confusion can lead to accidental use of the wrong database or unsafe troubleshooting workarounds.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The guide includes example JDBC URLs and Flyway configuration that contain plaintext usernames and passwords formatted like usable credentials rather than clearly redacted placeholders. Even if illustrative, publishing secrets-looking values normalizes insecure secret handling and risks accidental reuse, credential harvesting, or confusion about whether the credentials are real.

Context-Inappropriate Capability

High

Confidence: 99% confidence
Finding: This is a true vulnerability. The documentation explicitly recommends replacing parameterized queries with manual string interpolation before passing them to `client.raw(...)`, which removes SQL query/data separation and can allow attacker-controlled input to alter query structure. In a database connection guide for Knex, readers are likely to copy this pattern directly into production code, making the context more dangerous rather than less dangerous.

Intent-Code Divergence

Medium

Confidence: 97% confidence
Finding: The guide explicitly instructs users to disable publication auto-creation, but the sample connector JSON sets `publication.autocreate.mode` to `all_tables`. This contradiction can cause readers to deploy a broader publication scope than intended, potentially replicating additional tables and exposing more data into Kafka than expected.

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The guide explicitly frames the setup as a secure server-side database access pattern, but the sample service methods build SQL with a template string using a table name directly. If that value ever becomes user-controlled in real applications, it enables SQL injection or unauthorized table access; even though the controller passes a constant string here, documentation examples are commonly reused and adapted unsafely.

Intent-Code Divergence

Medium

Confidence: 99% confidence
Finding: All three driver examples use unsafe dynamic SQL (`SELECT * FROM ${name}`), which normalizes insecure query construction in a security-oriented database guide. This is dangerous because readers may generalize the pattern to request parameters or route inputs, creating exploitable SQL injection paths across NestJS applications.

Intent-Code Divergence

Medium

Confidence: 93% confidence
Finding: The documentation includes a full realistic-looking PostgreSQL connection string with an inline username and password and explicitly tells readers to copy and use it. Even if the credential is illustrative, presenting secrets in plaintext without clear placeholder notation normalizes unsafe handling and creates risk if the example is ever mistaken for a live credential or copied into logs, screenshots, or repos.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The import script does not flush the final batch after the loop, so any remaining records fewer than 20 are never inserted. This creates silent data loss during migration, which can undermine integrity checks and cause incomplete or inconsistent application state after cutover.

Context-Inappropriate Capability

Medium

Confidence: 96% confidence
Finding: The documentation embeds full PostgreSQL connection strings containing plaintext usernames and passwords directly in command examples. Even if these appear to be sample credentials, this normalizes unsafe secret handling and encourages users to paste real credentials into shell commands, logs, screenshots, and shell history.

Context-Inappropriate Capability

Medium

Confidence: 97% confidence
Finding: The worked example repeats multiple full source and destination connection strings with embedded credentials, increasing exposure and reinforcing the idea that secrets should be written inline. This raises the risk of credential leakage through copy/paste, terminal history, recordings, and documentation reuse.

Description-Behavior Mismatch

Medium

Confidence: 92% confidence
Finding: This file is materially out of scope for the declared Neon Database skill and instead promotes a separate AI agent platform that provisions infrastructure, authentication, CI/CD, and deployment. In an agent skill context, scope drift is dangerous because a consuming agent may surface or act on these instructions under the assumption they are trusted Neon documentation, leading to unintended use of external services or execution of higher-risk workflows.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The page consistently describes this feature as static anonymization, but this line says `masking_function` is used 'for dynamic masking'. That contradiction can mislead users about how masking rules behave and may cause them to assume data is protected at query time rather than permanently transformed during branch anonymization, leading to privacy and compliance mistakes.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: The README includes a PowerShell example that invokes an elevated shell and executes a remotely downloaded script via `iex (iwr ...)` with `-ExecutionPolicy Bypass`. Even though it appears in documentation as an example, this pattern is dangerous because readers may copy-paste it verbatim, granting admin privileges to unverified remote code without any warning or integrity verification.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The documentation tells users to paste a full PostgreSQL connection URI containing username and password directly into notebook source code. In notebook environments, code cells are commonly saved to disk, versioned, shared, synced, or displayed in screenshots, which makes accidental credential disclosure much more likely. In this context, the skill is more dangerous because it targets an interactive notebook workflow where secret-handling mistakes are common and persisted artifacts are easy to leak.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: This documentation explicitly states that the plugin can create or delete branches and databases, run SQL queries, and perform migrations, but it does not warn users that these are state-changing and potentially destructive operations. In an agent/plugin context, omission of confirmation, least-privilege guidance, or human-approval warnings increases the risk that users enable powerful automation without understanding the blast radius.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The document instructs users to paste a full PostgreSQL connection string, including credentials, directly into a Google Colab notebook cell. In a shared or publicly accessible Colab environment, this increases the risk of accidental credential exposure through notebook sharing, saved outputs, revision history, screenshots, or reuse of the notebook by others.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The documentation instructs users to place a Neon API key directly into client config and command examples, which can lead to accidental secret exposure through committed config files, shell history, screen sharing, or logs. In this context the risk is amplified because several examples write project-level configuration files that may persist and be shared with other tools or collaborators.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The troubleshooting section recommends a recursive deletion command without clearly warning users about its destructive nature or advising them to verify the exact path. Although the target is intended to be a specific cache directory, commands using rm -rf are high-risk because path typos, environment expansion issues, or careless copying can cause unintended data loss.

Missing User Warnings

Medium

Confidence: 85% confidence
Finding: The documentation explicitly shows sending `message`/prompt content to an external LLM provider via `step.ai.infer()` but does not warn readers that user inputs may be transmitted to a third party and subject to provider retention, logging, or policy controls. In documentation for AI workflows, this omission can lead developers to unknowingly process sensitive user or database-derived content in ways that create privacy, compliance, and data-governance risk.

VirusTotal

60/60 vendors flagged this skill as clean.

View on VirusTotal