Fix security issues in documentation examples - #2
Conversation
- Replace hardcoded API key placeholders with env var references in config.yaml examples (part9) - Standardize placeholder keys to use obvious non-secret patterns (<your-key-here>) - Add security warning for unauthenticated LightRAG REST API (bind to 127.0.0.1) - Add proper cryptographic secret generation for Telegram webhook secret - Add chmod 600 guidance for .env files containing API keys - Add curl-pipe-to-bash inspection tip for install command - Replace realistic-looking Telegram bot token examples with safe placeholders Co-Authored-By: Rob <onerobby@gmail.com>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| - **Web UI** at `http://localhost:9623/webui` for browsing the knowledge graph | ||
| - **Health check** at `http://localhost:9623/health` | ||
|
|
||
| > **Security warning:** The LightRAG REST API has **no built-in authentication**. Always bind to `127.0.0.1` (localhost only) — never `0.0.0.0`. If you need remote access, put it behind a reverse proxy (nginx, Caddy) with authentication, or use SSH tunneling. Anyone who can reach this port can query, ingest, or delete your knowledge graph data. |
There was a problem hiding this comment.
🔴 Incomplete security fix: background service commands still missing --host 127.0.0.1
The PR adds --host 127.0.0.1 to the primary lightrag-server start command at README.md:674 and adds a security warning at README.md:682 stating "Always bind to 127.0.0.1 (localhost only) — never 0.0.0.0." However, the same file provides three other lightrag-server commands that were not updated with --host 127.0.0.1: the nohup command at README.md:688, the hermes background command at README.md:691, and the troubleshooting command at README.md:963. Users following the "Run as a Background Service" instructions (the most common production usage) will start the server without the host binding restriction, potentially exposing the unauthenticated LightRAG REST API to the network — the exact scenario the new security warning is meant to prevent.
Prompt for agents
The PR added --host 127.0.0.1 to the foreground lightrag-server command and a security warning about always binding to localhost, but did not apply the same --host 127.0.0.1 flag to the other lightrag-server invocations in the same file. The following commands in README.md need --host 127.0.0.1 added:
1. Line 688: nohup lightrag-server --port 9623 → nohup lightrag-server --host 127.0.0.1 --port 9623
2. Line 691: hermes background "cd ~/.hermes/lightrag/LightRAG && lightrag-server --port 9623" → add --host 127.0.0.1
3. Line 963: cd ~/.hermes/lightrag/LightRAG && lightrag-server --port 9623 → add --host 127.0.0.1
The same issue also exists in part3-lightrag-setup.md at lines 117, 120, and 386.
Was this helpful? React with 👍 or 👎 to provide feedback.
| - **Web UI** at `http://localhost:9623/webui` for browsing the knowledge graph | ||
| - **Health check** at `http://localhost:9623/health` | ||
|
|
||
| > **Security warning:** The LightRAG REST API has **no built-in authentication**. Always bind to `127.0.0.1` (localhost only) — never `0.0.0.0`. If you need remote access, put it behind a reverse proxy (nginx, Caddy) with authentication, or use SSH tunneling. Anyone who can reach this port can query, ingest, or delete your knowledge graph data. |
There was a problem hiding this comment.
🔴 Incomplete security fix: background service commands in part3 also missing --host 127.0.0.1
Same issue as in README.md but in the standalone guide file. The PR adds --host 127.0.0.1 to the primary start command at part3-lightrag-setup.md:103 and a security warning at part3-lightrag-setup.md:111, but the nohup command at part3-lightrag-setup.md:117, the hermes background command at part3-lightrag-setup.md:120, and the troubleshooting command at part3-lightrag-setup.md:386 all still lack --host 127.0.0.1. Users following these instructions will inadvertently expose the unauthenticated API.
Prompt for agents
The PR added --host 127.0.0.1 to the foreground lightrag-server command and a security warning about always binding to localhost, but did not apply the same --host 127.0.0.1 flag to the other lightrag-server invocations in part3-lightrag-setup.md. The following commands need --host 127.0.0.1 added:
1. Line 117: nohup lightrag-server --port 9623 → nohup lightrag-server --host 127.0.0.1 --port 9623
2. Line 120: hermes background "cd ~/.hermes/lightrag/LightRAG && lightrag-server --port 9623" → add --host 127.0.0.1
3. Line 386: cd ~/.hermes/lightrag/LightRAG && lightrag-server --port 9623 → add --host 127.0.0.1
Was this helpful? React with 👍 or 👎 to provide feedback.
- Replace hardcoded API key placeholders with env var references in config.yaml examples (part9) - Standardize placeholder keys to use obvious non-secret patterns (<your-key-here>) - Add security warning for unauthenticated LightRAG REST API (bind to 127.0.0.1) - Add proper cryptographic secret generation for Telegram webhook secret - Add chmod 600 guidance for .env files containing API keys - Add curl-pipe-to-bash inspection tip for install command - Replace realistic-looking Telegram bot token examples with safe placeholders Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
1 participant
Summary
Security audit of the documentation found that several code examples and configuration snippets could lead readers into insecure practices. This PR updates examples across 5 files to follow security best practices:
part9-custom-models.md): Config YAML examples now use${ANTHROPIC_API_KEY}syntax instead ofsk-ant-.../csk-.../fw_..., with a warning to never put real keys in config.yaml.part3-lightrag-setup.md,part1-setup.md,README.md): Replacesk-...,fw_...,***with obvious<your-key-here>patterns that won't trip secret scanners.part3-lightrag-setup.md,README.md): The REST API has no built-in auth — added explicit--host 127.0.0.1to the start command and a warning about network exposure.part4-telegram-setup.md,README.md): Replaceyour-random-secret-herewith anopenssl rand -hex 32generation command and a forgery warning.chmod 600guidance for.envfiles (multiple files): Secrets files should not be world-readable.part1-setup.md,README.md): Show how to download-then-inspect before executing.<your-bot-token-from-botfather>.Review & Testing Checklist for Human
${ENV_VAR}interpolation works in Hermesconfig.yaml—part9-custom-models.mdnow recommendsapi_key: ${ANTHROPIC_API_KEY}. If Hermes doesn't support env var expansion in YAML, this will break users' setups. Confirm this syntax is valid before merging.--host 127.0.0.1is a validlightrag-serverflag — added to the start command inpart3-lightrag-setup.mdandREADME.md. If LightRAG's CLI doesn't support this flag, the example will error.123456789:ABCdefGHIjklMNOpqrSTUvwxYZ) in Step 1 was intentionally left as-is since it's illustrating the format, not a config value. Confirm this is the right call vs. also changing it.Notes
security-findings.md.Link to Devin session: https://app.devin.ai/sessions/c45e3eb8a2eb4d80a2f9b8c514ae9025
Requested by: @OnlyTerp