GHSA-4hf8-5mjm-rfgq
Fix: dtwang/line-desktop-mcp@6806178GHSA-4hf8-5mjm-rfgq is a Missing Authentication vulnerability in line-desktop-mcp. O3 Security confirms whether GHSA-4hf8-5mjm-rfgq is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Streamable HTTP mode exposes LINE Desktop read/send tools without MCP authentication
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
line-desktop-mcpnpmDescription
Streamable HTTP mode exposes LINE Desktop read/send tools without MCP authentication
Summary
line-desktop-mcp supports a --http-mode Streamable HTTP transport for use with clients such as n8n. In this mode the server binds to 0.0.0.0 and exposes the MCP /mcp endpoint without an MCP-layer authentication check. Any network client that can reach the port can initialize a session, list tools, and call tools that read LINE Desktop chat history or send LINE messages through the already logged-in desktop application.
This is High for deployments where the HTTP port is reachable beyond the local host, because the server acts with the user authority of the logged-in LINE Desktop session. It is lower if the listener is strictly firewalled to trusted local clients.
Affected version
Repository: dtwang/line-desktop-mcp
Current source checked: fbed0d2d3048e63f48a356a1267ed8ec5e78f3ae on main, committed 2026-05-14.
Published npm package checked: [email protected].
Source evidence
README.md documents Streamable HTTP mode:
npx line-desktop-mcp@latest --http-mode --port 3000
The same README documents MCP endpoints at /mcp and explains that this mode is intended for clients such as n8n.
src/server.js registers LINE Desktop tools including:
get_line_chatroom_history_defaultget_line_chatroom_history_longget_line_chatroom_history_shortsend_message_manualsend_message_auto
Those tool handlers call into the desktop automation layer: getChatHistory(...) and sendChatMessage(...).
In HTTP mode, src/server.js creates an Express app and Streamable HTTP transport, accepts POSTs to /mcp, creates sessions, connects the transport to the MCP server, and calls transport.handleRequest(...). I did not find an authentication or bearer-token check before session creation or tool invocation.
The listener is explicitly network-bound:
app.listen(port, 0.0.0.0, () => {
console.error(`LINE Desktop MCP Server running on Streamable HTTP mode`);
console.error(` Local: http://127.0.0.1:${port}${endpoint}`);
console.error(` Network: http://0.0.0.0:${port}${endpoint}`);
});
Vulnerability chain
- A user starts the server with
--http-mode --port 3000. - The server binds on
0.0.0.0:3000, not only loopback. - A network client reaches
/mcpand sends the normal MCP initialize request. - The server creates a Streamable HTTP session without authenticating the caller.
- The caller can list and invoke LINE Desktop tools.
- Tool calls execute through the logged-in LINE Desktop application on the user workstation.
Impact
An unauthenticated network client can read LINE chat history through the MCP history tools and can send LINE messages through the send-message tools, including send_message_auto when the tool call requests immediate sending. The attacker does not need LINE credentials or a LINE API token; they only need network reachability to the MCP HTTP port.
The practical impact is disclosure of private LINE conversations and unauthorized messages sent as the logged-in desktop user.
Suggested fix
Require authentication before accepting Streamable HTTP MCP sessions or tool calls. For example:
- require a bearer token or local secret when
--http-modeis used; - bind HTTP mode to
127.0.0.1by default unless the operator explicitly opts into network exposure; - refuse to start
0.0.0.0HTTP mode without authentication; - document that
host.docker.internal/ n8n setups must still authenticate to the MCP server.
A defense-in-depth improvement would also keep send_message_auto disabled unless explicitly enabled by a server-side flag, because it converts MCP tool access into immediate message sending as the desktop user.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | line-desktop-mcp | all versions | 1.1.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for line-desktop-mcp. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update line-desktop-mcp to 1.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4hf8-5mjm-rfgq is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-4hf8-5mjm-rfgq is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-4hf8-5mjm-rfgq. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-4hf8-5mjm-rfgq in your dependencies?
O3 detects GHSA-4hf8-5mjm-rfgq across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.