LightRAG Search Skill

• Outcome: Review
• Latest audit: Sep 10, 2026 · 7:12 AM UTC
• Version: 1.0.1

Overview

This LightRAG skill matches its stated purpose, but it handles API keys and network queries in ways that can expose credentials or sensitive query content.

Review before installing. Use this only with trusted LightRAG endpoints, avoid configuring API keys for HTTP URLs, and treat ~/.lightrag_config.json as sensitive. The publisher should re-enable normal TLS verification and store API keys with restrictive permissions or a credential store before this is suitable for broader use.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/query_lightrag.py:77
• Finding: TLS Certificate and Hostname Verification Disabled## Vulnerability Details **File Location**: `scripts/query_lightrag.py`, lines 77–80 **Vulnerability Type**: Improper certificate validation **Risk Level**: High **Vulnerable Code**: ```python # Create unverified context to bypass SSL issues ctx = ssl.create_default_context() ctx.check_hostname = False ctx.verify_mode = ssl.CERT_NONE ``` ### Technical Analysis The script explicitly disables both TLS certificate-chain validation and hostname verification for every HTTPS request. Consequently, it cannot verify that the remote endpoint is the configured LightRAG server. An attacker capable of intercepting network traffic can present an arbitrary certificate without causing the connection to fail. Because requests may contain an `X-API-Key` header and sensitive query text, this flaw compromises both request confidentiality and response integrity. ### Attack Path 1. A user configures an HTTPS LightRAG endpoint and an API key. 2. The user invokes the `query` command. 3. An attacker with a network interception position redirects or intercepts the connection. 4. The attacker presents an untrusted or hostname-mismatched certificate. 5. The script accepts the certificate because certificate and hostname verification are disabled. 6. The attacker captures the API key and query body. 7. The attacker may return a manipulated JSON response containing malicious or misleading context. 8. That content is printed directly or supplied to a downstream writing workflow. ### Impact Assessment A network-positioned attacker may obtain LightRAG API credentials, read potentially sensitive knowledge-base queries, modify server responses, and inject attacker-controlled material into downstream agent tasks. The vulnerability does not directly grant local operating-system privileges, but it can provide access equivalent to the compromised API key and undermine the integrity of generated output.
• Remediation: ## Remediation Suggestions - Remove the assignments to `check_hostname` and `verify_mode`. - Use Python's default verified TLS context: ```python ctx = ssl.create_default_context() ``` - For private certificate authorities, accept an explicitly configured CA bundle and load it with `ssl.create_default_context(cafile=...)`. - Do not provide a global “disable verification” option. If an exceptional development-only override is unavoidable, require an explicit flag, emit a prominent warning, and prohibit its use when an API key is configured. - Add tests confirming that self-signed, expired, and hostname-mismatched certificates are rejected.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/query_lightrag.py:17
• Finding: API Keys Stored Without Enforced Restrictive File Permissions## Vulnerability Details **File Location**: `scripts/query_lightrag.py`, lines 17–19 and 45–49 **Vulnerability Type**: Insecure plaintext credential storage **Risk Level**: Medium **Vulnerable Code**: ```python def save_config(config): with open(CONFIG_PATH, "w") as f: json.dump(config, f, indent=2) ``` The configuration written by this function includes the API key: ```python config["servers"][args.alias] = { "url": args.url, "api_key": args.key, "mode": args.mode } ``` ### Technical Analysis LightRAG API keys are persisted in plaintext in `~/.lightrag_config.json`. The file is created using the process's default permission behavior, with no explicit restrictive mode and no validation or correction of an existing file's permissions. On a system with a permissive umask, or where an existing configuration file has broad permissions, other local users may be able to read the stored credentials. Rewriting an existing file does not necessarily correct its mode. ### Attack Path 1. A user runs the `config` command with `--key`. 2. The API key is inserted into the configuration object. 3. `save_config` writes the key in plaintext to `~/.lightrag_config.json`. 4. The file is created or retained with permissions that allow another local account to read it. 5. The local attacker reads the configuration and extracts the API key. 6. The attacker reuses the key against the configured LightRAG server. ### Impact Assessment Exploitation requires local file-system access under another account or process with permission to read the configuration. A successful attacker obtains the authority granted by the exposed LightRAG API key, potentially including access to sensitive query functionality or other server operations permitted by that credential. This issue does not itself escalate operating-system privileges.
• Remediation: ## Remediation Suggestions - Create the configuration atomically with owner-only permissions (`0600`). - Open a temporary file using `os.open` with `O_CREAT | O_EXCL` and mode `0o600`, write and flush the data, then atomically replace the destination. - Apply `os.chmod(CONFIG_PATH, 0o600)` to existing configuration files after validating ownership. - Reject configuration files owned by another user or writable by group/others. - Prefer retrieving API keys from environment variables, an operating-system credential store, or a dedicated secrets manager. - Avoid retaining keys in configuration when a credential-reference mechanism is available.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:16
• Finding: Plaintext HTTP Configuration Exposes API Keys and Query Data## Vulnerability Details **File Location**: `SKILL.md`, lines 16–21 **Vulnerability Type**: Transmission of sensitive information over an unencrypted channel **Risk Level**: Medium **Vulnerable Configuration Example**: ```json { "servers": { "alias1": { "url": "http://server1:9621", "api_key": "optional_key" }, ``` ### Technical Analysis The documented configuration pairs a plaintext HTTP endpoint with an API key. The implementation accepts the configured URL without enforcing HTTPS and sends the key in the `X-API-Key` header, while query text is placed in the request body. When this example is used for a non-loopback endpoint, neither credentials nor request and response data receive transport confidentiality or integrity protection. ### Attack Path 1. A user follows the documented example and configures an `http://` LightRAG server with an API key. 2. The script sends a query and the `X-API-Key` header over plaintext HTTP. 3. An attacker able to observe or alter traffic captures the API key and query. 4. The attacker may modify the response to provide fabricated or attacker-controlled context. 5. The stolen credential can be replayed against the LightRAG server within its granted authorization scope. ### Impact Assessment A network-positioned attacker can disclose API credentials and sensitive query data, impersonate the client within the API key's authorization scope, and modify retrieved content. No direct local privilege escalation is provided, but the confidentiality and integrity of LightRAG interactions are lost.
• Remediation: ## Remediation Suggestions - Change documentation examples to use `https://`. - Reject non-HTTPS server URLs by default in the `config` and `query` workflows. - If local development requires HTTP, permit it only for loopback addresses such as `127.0.0.1`, `::1`, or `localhost`. - Require an explicit, clearly warned opt-in before allowing plaintext HTTP for any other destination. - Never transmit an API key over HTTP. - Combine HTTPS enforcement with normal certificate and hostname validation.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (5)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The finding indicates behavior beyond the declared purpose, including disabled SSL certificate verification and local storage of API keys in a home-directory config file. Disabling TLS verification enables man-in-the-middle interception of queries and credentials, while unclear behavior and under-disclosed sensitive storage increase the risk that users or operators trust the skill with insufficient awareness of its actual security posture.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The script transmits user queries and optionally an API key over HTTPS while TLS verification is disabled, so the confidentiality and authenticity of the connection cannot be trusted. In a knowledge-base skill, queries may contain proprietary or sensitive context, and a network attacker could read, steal, or tamper with both requests and responses.

Intent-Code Divergence

High

• Confidence: 99% confidence
• Finding: The code explicitly disables both certificate validation and hostname verification for every HTTPS request, which removes TLS's protection against man-in-the-middle attacks. In this skill, requests may carry both sensitive user queries and an API key, so an attacker on the network path could intercept or modify traffic and impersonate the LightRAG server.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 87% confidence
• Finding: The skill declares capabilities that imply file access, file modification, and network communication, but it does not declare any explicit tool scope or permission boundaries. In an agent setting, this increases the chance of overbroad execution and makes it harder to constrain what the skill can access, especially because it reads configuration from the user's home directory and contacts remote servers.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The script stores the API key in a JSON config file under the user's home directory with no permission hardening, encryption, or warning that a secret is being persisted. This increases the chance of credential exposure through overly broad file permissions, backups, shared accounts, or accidental disclosure of the config file.

Static analysis

No suspicious patterns detected.