Security audit

NeoDB

Security checks for vulnerabilities and agentic risk

Overview

This NeoDB skill is purpose-aligned, but its setup script exposes and stores account credentials in ways users should review before installing.

Install only if you are comfortable granting read/write access to your NeoDB account. If you run the setup script, treat the displayed token and scripts/.credentials.json as secrets, delete or lock down that file after configuring NEODB_TOKEN, and review every write request carefully, especially visibility and any post_to_fediverse setting.

SkillSpector

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 (5)

Description-Behavior Mismatch

Medium

Confidence: 90% confidence
Finding: The script requests broad "read write" OAuth scopes for a helper that is described as a NeoDB assistant, without any evidence of scope minimization or per-operation consent. Excessive scopes increase blast radius: if the token is exposed, an attacker can perform any API actions allowed by both read and write access rather than only the minimum needed for the intended workflows.

Context-Inappropriate Capability

Medium

Confidence: 97% confidence
Finding: The script persists client_id, client_secret, and access_token in a local JSON file inside the repository tree, creating a durable credential target for accidental commits, local compromise, backups, or other tools that can read the workspace. For a skill setup helper, this materially increases credential exposure because the stored secrets can be reused later without re-authentication.

Intent-Code Divergence

Low

Confidence: 95% confidence
Finding: The script prints the full bearer token to stdout, which can leak into terminal scrollback, shell logging, screen recordings, CI logs, remote session transcripts, or copy/paste history. A bearer token grants immediate API access to whoever obtains it, so displaying it in full unnecessarily exposes a sensitive credential.

Missing User Warnings

Medium

Confidence: 98% confidence
Finding: Exposing the access token in full on stdout is a direct secret-handling flaw because bearer tokens are sufficient for API use without additional authentication. In the context of a setup script, users may run it in shared terminals or captured sessions, making inadvertent disclosure realistic.

Missing User Warnings

Medium

Confidence: 97% confidence
Finding: Writing sensitive credentials to a local file without prominent warning or secure handling guidance creates a predictable plaintext secret store. Because the file includes both client and user credentials, compromise of that file can enable persistent unauthorized access and make revocation harder to manage.

Static analysis

No suspicious patterns detected.