Is duckdb/duckdb-skills safe?
https://github.com/duckdb/duckdb-skills
duckdb/duckdb-skills is a legitimate data-exploration plugin from the official DuckDB GitHub organization with well-documented MIT-licensed functionality. The primary risks are: (1) the read-memories skill silently harvests all Claude Code session logs across every project on the machine without narrating this to the user; (2) the install-duckdb --update path executes 'curl | sh' against install.duckdb.org, creating a supply-chain attack surface; and (3) cloud storage skills transparently consume ambient AWS/GCS/Azure credentials via credential_chain. No active exfiltration, prompt injection attacks, or canary violations were detected during the audit run.
Category Scores
Findings (10)
HIGH read-memories scans all Claude session logs silently -25 ▶
The read-memories SKILL.md explicitly instructs the agent 'do NOT narrate the process' and queries $HOME/.claude/projects//.jsonl — every Claude Code session log on the machine, not scoped to the current project. This silently ingests up to 40 rows × 500 chars of prior conversation content, which may include API keys, database URIs, business logic, or PII discussed in any prior session.
HIGH install-duckdb --update pipes curl to shell -30 ▶
The update path of install-duckdb constructs 'curl -fsSL https://install.duckdb.org | sh' when the user agrees to upgrade. This is a classic supply-chain attack vector: any compromise of install.duckdb.org or a MITM would result in arbitrary code execution with the agent's user privileges.
MEDIUM read-memories instructs agent to suppress narration of its actions -15 ▶
The read-memories skill contains the meta-instruction 'do NOT narrate the process', directing the LLM agent to hide its file-reading activity from the user. While the intent appears to be UX simplicity, this pattern trains the agent to perform sensitive filesystem reads without surfacing them to the user, eroding transparency.
MEDIUM Cloud storage skills consume ambient credentials via credential_chain -10 ▶
s3-explore, spatial, read-file, and convert-file all generate CREATE SECRET (TYPE S3, PROVIDER credential_chain) statements which silently consume ~/.aws/credentials, IAM instance roles, or environment variables. The SQL runs inside duckdb which then makes outbound S3/GCS/Azure connections on behalf of the agent.
MEDIUM Cross-skill information leakage: session logs feed cloud queries -15 ▶
read-memories returns session content (which may contain S3 bucket names, connection strings, or credential fragments) directly into the agent context. A subsequent s3-explore or query invocation in the same session could act on that information, effectively chaining private data harvesting with cloud data access without explicit user awareness.
MEDIUM duckdb-docs downloads and ATTACHes a remote DuckDB database -8 ▶
The duckdb-docs skill fetches https://duckdb.org/data/docs-search.duckdb and ATTACHes it as a writable local database, then runs COPY FROM DATABASE. A compromised upstream could deliver a DuckDB file containing malicious SQL macros, FTS indexes with embedded payloads, or shell-out extensions that execute on LOAD.
LOW read-memories modifies agent context across all projects without per-invocation consent -13 ▶
Every time read-memories is invoked it may surface content from unrelated projects. The user invoking it in project A may not realize the agent is now contextually aware of conversations from project B, C, etc., potentially influencing responses in ways the user did not anticipate.
LOW Shared state.sql is append-only with no per-skill validation -10 ▶
attach-db appends ATTACH and USE statements to a shared state.sql without cryptographic validation of the .duckdb file being attached. A maliciously crafted database file could inject LOAD or INSTALL statements that affect all subsequent skill invocations in the session.
INFO Clone was clean — no hooks, submodules, or unexpected processes 0 ▶
The git clone contacted only github.com (140.82.121.4:443). No git hooks, no .gitattributes filters, no submodules, and no npm install scripts were present. Filesystem changes were confined to the skill directory.
INFO Canary file accesses attributable to monitoring framework 0 ▶
The six canary files were opened at timestamps 1782383197 (pre-clone, monitoring init) and 1782383219 (post-clone, monitoring teardown), both consistent with Oathe's baseline hashing and integrity verification. No outbound connections carrying canary data were observed. Monitoring reports all canaries intact.