Adds new integration [wizz666/homeassistant-openrouter-bridge]#6479
Adds new integration [wizz666/homeassistant-openrouter-bridge]#6479wizz666 wants to merge 4 commits into
Conversation
|
Thank you for submitting your repository to HACS (Home Assistant Community Store). Your submission is in the review queue: You can view the current queue here. Pull requests are processed in the order they were created, oldest first. What to avoid during review:
If you need to make changes: About draft pull requests: What happens next:
|
frenck
left a comment
There was a problem hiding this comment.
Hi @wizz666, thanks for the submission and for the careful documentation. 👋
Before this can go into the HACS default catalog, the integration has some serious security issues that need to be addressed.
Every HomeAssistantView registered by the integration sets requires_auth = False. That includes:
/api/openrouter_bridge/v1/messages(api.pyline 430) — proxies to OpenRouter with the user's API key/api/openrouter_bridge/v1/models(api.pyline 589)/api/openrouter_bridge(api.pyline 639)/api/openrouter_bridge/terminal(terminal.pyline 126)/api/openrouter_bridge/terminal/ws(terminal.pyline 143)
The terminal WebSocket is the most serious one. It opens a PTY backed by subprocess.Popen([_CLAUDE_BIN]) (terminal.py lines 209-215) and forwards bytes from the WebSocket straight into the PTY via os.write(master_fd, data) (lines 240-247). Combined with requires_auth = False, this means anyone who can reach the Home Assistant HTTP server can open that WebSocket and get an interactive Claude CLI session running as the HA user, with HOME=/root and cwd=/config/claude_workspace. That's effectively unauthenticated remote command execution. "Trusted local network" is not a safe assumption here. HA instances are routinely reachable from the public internet through Nabu Casa, reverse proxies, or port forwarding, and the rest of HA's HTTP surface is auth-protected for exactly this reason.
The proxy endpoints have the same problem on a smaller scale: anyone on the network can hit /v1/messages and burn the user's OpenRouter credits.
Please remove requires_auth = False from every view, or replace it with HA's existing per-view auth mechanisms (long-lived access tokens, the auth_required flow, or scoped tokens). The terminal feature specifically also needs a hard look at whether exposing a PTY-backed CLI process inside HA at all is appropriate, even with auth on the endpoint, since it sidesteps HA's regular service/script model and gives the connected client far more capability than a typical integration.
I'll close this review for now. Once the authentication is in place and the terminal surface has been reconsidered, feel free to re-request review (or open a fresh PR if this one ends up closed).
../Frenck
Blogging my personal ramblings at frenck.dev|
Hi @frenck, thank you for the thorough security review! All issues have been addressed in v1.0.2:
Release: https://github.com/wizz666/homeassistant-openrouter-bridge/releases/tag/v1.0.2 Requesting re-review. 🙏 |
|
Hi @frenck — both security issues from your review are fixed in v1.0.2 (released 2026-05-16).
Links:
Re-requesting your review — thank you! |
Checklist
Links
Link to current release: https://github.com/wizz666/homeassistant-openrouter-bridge/releases/tag/v1.0.1
Link to successful HACS action (without the
ignorekey): https://github.com/wizz666/homeassistant-openrouter-bridge/actions/runs/23425220322/job/68138501515Link to successful hassfest action (if integration): https://github.com/wizz666/homeassistant-openrouter-bridge/actions/runs/23425220322/job/68138501506