Security audit

Llmwiki

Security checks for vulnerabilities and agentic risk

Overview

This appears to be a legitimate personal knowledge-base tool, but it deserves review because its optional server can allow unauthenticated persistent writes and its install command pulls unpinned external code.

Install only in an isolated environment, pin the package version yourself, and treat the web/API server as unsafe for shared networks unless you bind it to localhost or put it behind authentication and rate limits. Assume documents sent for compilation or asking may be transmitted to the configured LLM API.

A.I.G

Vulnerability Patterns

Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Insecure DependenciesIntroduces malicious components through unsafe dependency sources
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

Findings (2)

T08 · Insecure Dependencies

Warning

Location: SKILL.md:22
Finding: Unpinned Third-Party Package Installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 22 and 52-60 **Vulnerability Type**: Unpinned dependency installation and unverifiable supply-chain behavior **Risk Level**: Medium ### Evidence ```yaml install: "pip install llmwiki" ``` ```markdown - **PyPI**: `pip install llmwiki` ## Setup ```bash pip install llmwiki ``` ``` ### Technical Analysis The documented installation command retrieves the latest package published under the `llmwiki` name rather than the specific version declared by the Skill metadata. It also provides no package hash or signed artifact verification. The audited project contains only `SKILL.md`; the source code of the installed Python package is not included. Consequently, the package behavior—including its handling of API credentials, local documents, network requests, SSRF protection, server authentication, and telemetry—cannot be verified from this artifact. Python package installation can execute packaging hooks, and the installed application will subsequently run with the user's filesystem and network permissions. A compromised publisher account, malicious replacement release, or unexpected upstream update could therefore alter the effective behavior after this Skill has been reviewed. ### Attack Path 1. An attacker compromises the upstream package publisher account or package-distribution process. 2. The attacker publishes a malicious or backdoored release under the expected `llmwiki` package name. 3. A user follows the Skill instructions and executes `pip install llmwiki`. 4. The package manager retrieves the latest available release rather than the Skill's declared version `0.8.0`. 5. Malicious installation or runtime code executes with the installing user's privileges. 6. The code may access the configured `LLMBASE_API_KEY`, local knowledge-base documents, and any other files available to that user, then transmit data using the application's network privileges. ### Impact Assessment Successful ...[truncated 682 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin the dependency to the reviewed version, such as: ```bash pip install llmwiki==0.8.0 ``` 2. Distribute a lock file or requirements file containing cryptographic hashes, and install with hash enforcement: ```bash pip install --require-hashes -r requirements.txt ``` 3. Include or vendor the exact executable source corresponding to the declared Skill version so its network, filesystem, authentication, and credential-handling behavior can be audited. 4. Build and publish reproducible artifacts, and document how users can verify package signatures or hashes. 5. Install the package in an isolated virtual environment or container with access limited to the required knowledge-base directory. 6. Avoid exposing unrelated environment variables and filesystem locations to the package. 7. Establish a controlled dependency-update process that requires review and testing before changing the pinned version. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

Location: SKILL.md:205
Finding: Unauthenticated Persistent Write Operation on a Network-Exposed Service<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 205-206 **Vulnerability Type**: Network-accessible unauthenticated mutation and unsafe default binding **Risk Level**: High ### Evidence ```markdown - **Web server** — optional; binds `0.0.0.0` so LAN-accessible by default — front with a reverse proxy or bind override for public exposure - **API secret** — cloud deployments (with `PORT` env) gate most mutating endpoints behind `LLMBASE_API_SECRET` (auto-generated if unset). Note: `/api/ask` is open by default and writes Q&A back via `file_back`; only promotion to concepts requires the secret ``` ### Technical Analysis The documented web server binds to `0.0.0.0`, making it reachable through every available network interface unless an external firewall or binding override restricts it. At the same time, `/api/ask` is explicitly open by default and can persist generated question-and-answer content through `file_back`. Although promotion to compiled concepts requires a secret, writing attacker-influenced data into the persistent wiki still crosses an access-control boundary. Authentication of only “most” mutating endpoints does not protect this write-capable operation. This behavior exceeds minimum privilege for an anonymous query endpoint: an unauthenticated caller should not receive persistent filesystem-write capability. The operation may also invoke the configured LLM service, allowing an attacker to consume paid tokens and server resources. The underlying implementation was not included in the audited artifact, so input validation, request limits, output sanitization, CSRF controls, and rate limiting could not be verified. ### Attack Path 1. An administrator starts the optional web server without overriding its default `0.0.0.0` binding. 2. The service becomes reachable by other hosts on the local network or, if routing and firewall rules permit, from the public Internet. 3. An unauthenticated attacker discovers the service and se ...[truncated 1215 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Bind the service to loopback by default: ```text 127.0.0.1 ``` Require an explicit configuration change before accepting connections from other hosts. 2. Require authentication and authorization for every endpoint capable of writing files, invoking paid services, changing state, or triggering compilation. 3. Disable `file_back` for anonymous requests. If public question answering is required, return results without persisting them. 4. Use a deny-by-default authorization policy rather than maintaining exceptions for selected mutating routes. 5. Add per-user and per-IP rate limits, request-size limits, concurrency controls, token budgets, and storage quotas. 6. Apply CSRF protection when browser credentials or cookie-based sessions are used. 7. Validate and sanitize all persisted fields, and mark externally supplied content with provenance metadata. 8. Place public deployments behind a properly configured reverse proxy with TLS, authentication, firewall restrictions, and logging. 9. Separate public read/query functionality from privileged ingestion, persistence, compilation, and healing operations. 10. Add automated security tests confirming that unauthenticated callers cannot cause filesystem changes or paid LLM requests beyond explicitly configured limits. ]]>

SkillSpector

Vulnerability Patterns

Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Credential Access

High

Category: Privilege Escalation
Content: mkdir my-kb && cd my-kb cat > .env << 'EOF' LLMBASE_API_KEY=sk-your-key LLMBASE_BASE_URL=https://your-endpoint/v1 LLMBASE_MODEL=your-model
Confidence: 60% confidence
Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Natural-Language Policy Violations

Medium

Confidence: 89% confidence
Finding: The description states that the LLM writes trilingual articles in EN / 中文 / 日本語 by default. This is a language/locale constraint presented as a default behavior rather than an explicit user-selected option, which can violate organizational policies requiring user choice for language preferences.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The security section makes an overbroad assurance that 'nothing is sent anywhere except the configured LLM API,' but the same skill explicitly supports fetching arbitrary URLs and corpus sources over the network. This is a security/privacy documentation flaw: users may underestimate outbound connections and data exposure paths, which can lead to unsafe deployment decisions or privacy misunderstandings.

Static analysis

No suspicious patterns detected.