Skip to content

openHAB's MCP Server Can Run Your House. 5.2.2 Is a Reminder to Patch It.

openHAB's MCP add-on lets Claude or ChatGPT control your home, with every risky capability off by default. Here are the flags I'd leave alone and the settings to recheck after the 5.2.2 security release.

Illustration of a glowing shield with a padlock between a robot figure and a smart door lock at night

openHAB's MCP Server Can Run Your House. 5.2.2 Is a Reminder to Patch It.

openHAB has the most complete documentation I've found for letting an AI agent operate a smart home platform that isn't Home Assistant. The MCP Server add-on isn't new; it arrived with openHAB 5.2, announced July 5, 2026. What pulled me back to it is openHAB 5.2.2, which shipped October 7 with fixes for five security advisories. One of the add-on fixes in that release is titled mcp: Fix local oAuth.

Here's what I found, and where I'd be careful.

What the add-on does

Per the docs, the add-on lets MCP clients, including Claude Desktop, Claude Code and ChatGPT, read and control your openHAB setup. The server lives at http://<host>:8080/mcp. Every connection needs an openHAB bearer token or OAuth, and the token inherits the permissions of the user it belongs to. The docs recommend a dedicated openHAB user with limited permissions for the assistant. If I were setting this up, that would be step one.

The assistant works from openHAB's semantic model plus fuzzy matching, so it can resolve names to real items. It can also create, update and delete rules, and the rules it creates are tagged "MCP". That tag is handy: you can find everything the agent wrote and review it.

openHAB 5.2 also added a chat interface to Main UI, with LLM-based interpreters starting with Google Gemini.

The flags I'd leave off

Everything powerful is opt-in. All of these default to false:

  • enableFullApiAccess: the docs say this includes destructive endpoints
  • enableScripting: JavaScript rules and execute_script
  • enableLoggingAccess
  • enableUiDesign: create Main UI pages and widgets; needs an ADMIN token
  • enableStaticAssets
  • registerCloudWebhook: reach the server through myopenhab.org

My read: start with plain item control and nothing else. Turn on one flag when you have a specific job for it. Scripting means an agent can write code that runs on your controller, and I'd want to read that code before it runs.

The docs are honest about limits. UI design uses "noticeably more" of an agent's context window than item control, so expect to start fresh chats more often. They recommend coding agents like Claude Code or Codex CLI over chat-only clients. And current MCP clients don't surface server-pushed notifications to the LLM yet, so the assistant only tells you about changes when you ask. If you pictured an agent that taps you on the shoulder, this isn't that.

What 5.2.2 changed

The release notes open with "Updating is strongly recommended." Five advisories:

  • Sitemap /proxy SSRF (GHSA-cwhr-cgmw-75gq). Proxy targets are now restricted to an allowlist. The new allowedHosts setting is empty by default, so proxied content like camera images or external widgets in sitemaps stops working until you add the hosts you need. The notes flag this as breaking.
  • Trusted-networks bypass via spoofed X-Forwarded-For (GHSA-v5qh-w8c6-7727). trustedNetworks is now checked against the real client address. Behind a reverse proxy every request looks like it comes from the proxy, so don't list the proxy's address (or loopback) as trusted unless you mean to trust every client behind it.
  • OAuth2 /auth code theft (GHSA-3523-gpwr-558p). redirect_uri must be same-origin and PKCE (S256) is now mandatory. Third-party OAuth2 clients on another origin, or without PKCE, can't use /auth anymore.
  • Reflected XSS on /auth (GHSA-5j66-4gjf-f7h9).
  • XXE in the IP Camera binding's /OnvifEvent (GHSA-c3px-f8cr-493c). If you're behind NAT or a proxy, add those addresses to ipWhitelist.

Other fixes touch the MCP add-on and the ChatGPT binding (max_completion_tokens, tools with reasoning models).

Then 5.2.3, three days later

openHAB 5.2.3 was published October 10. The maintainers' announcement calls it "two urgent fixes over 5.2.2": admin login works again through myopenHAB and reverse proxies (the release notes list it as "Fix broken auth with cloud and proxies"), and Main UI's map page and location picker now default to the OSM Mapnik tile provider after the previous provider started requiring API keys. If you're exposed through myopenHAB or a proxy, skip straight to 5.2.3.

openHAB's notes don't include severity scores or say whether any of these were exploited, so I'm not going to rank them. The practical point is simpler: if you expose openHAB, update, then recheck allowedHosts, trustedNetworks and any OAuth2 clients.

How the other platforms handle it

Hubitat's built-in AI (MCP) Connector first shipped in 2.5.1. Its docs say local AI assistants only, "cloud agents are not supported at this time," and the bearer token "should be protected like a password."

Home Assistant 2026.10 added a Model Context Protocol card under Settings > System > AI. One click turns the server on. New setups expose everything but only allow administrator accounts to connect.

Different platforms, same shape: a token that is effectively a password, and an agent that's only as safe as the account you hand it. openHAB's flags make that trade-off the most explicit of the three, which I like. The 5.2.2 notes are the other half of the story. The controller's own login and proxy handling is attack surface too, and it needs patching like anything else.

Permalink: https://homeautomationweekly.com/issues/4-openhab-mcp-server-5-2-2-security