https://db.gcve.eu/rss/recent/all/10 Most recent entries from all 2026-10-02T14:01:38.020600+00:00 Vulnerability-Lookup info@gcve.eu python-feedgen Contains only the most 10 recent entries. https://db.gcve.eu/vuln/cve-2026-54785 CVE-2026-54785 — gemini-bridge vulnerable to arbitrary local file read via consult_gemini_with_files inline mode 2026-10-02T14:01:38.047264+00:00

Affected: eLyiN gemini-bridge

gemini-bridge is a lightweight MCP server bridging AI agents to Google's Gemini AI via the official CLI. From 1.0.0 until 1.3.1, consult_gemini_with_files in inline mode read any file path supplied in the files argument without confining it to the working directory, then forwarded the contents to the Gemini CLI. Because the caller also controls query, the file contents are echoed back through the Gemini round-trip (and sent to Google), making this an arbitrary local file read. This issue is fixed in version 1.3.1.

 https://db.gcve.eu/vuln/ghsa-c5px-58j2-7fqp GHSA-c5px-58j2-7fqp — gemini-bridge vulnerable to arbitrary local file read via consult_gemini_with_files inline mode 2026-10-02T14:01:38.047366+00:00

Affected: PyPI: gemini-bridge

### Summary `consult_gemini_with_files` in **inline mode** read any file path supplied in the `files` argument without confining it to the working `directory`, then forwarded the contents to the Gemini CLI. Because the caller also controls `query`, the file contents are echoed back through the Gemini round-trip (and sent to Google), making this an arbitrary local file read.

### Impact An MCP client — or an LLM that has been prompt-injected into calling the tool — can read **any file the server process can access** (SSH keys, cloud credentials, `.env`, source) and have it disclosed via the tool response. No code execution by itself.

### Affected component - Tool: `consult_gemini_with_files(query, directory, files, …)`, `mode="inline"` - Sink: `_read_file_for_inline` via `_prepare_inline_payload` in `src/mcp_server.py` - The `at_command` mode already confined paths; inline mode did not.

### Root cause `_resolve_path` returned an out-of-root path while only nullifying the *display* name, and `_prepare_inline_payload` read the file regardless. Absolute paths, `..` traversal, and symlink escapes were all accepted.

### Patch Fixed in **1.3.1**. `_resolve_path` now resolves symlinks and confines via `Path.relative_to(root)`; inline mode skips any entry that resolves outside the working directory (the same guard `at_command` already enforced).

### Workarounds Upgrade to 1.3.1. Before upgrading, avoid `mode="inline"` with untrusted `files` input, or run the server with a restric…