GHSA-G39V-CVJH-8FPF

When ENABLE_YAML_CONFIG_EDITING=true, every ha_config_set_yaml call backs up the pre-edit file to <config>/www/yaml_backups/, which Home Assistant serves at /local/ with no authentication. Anyone who can reach the HA web interface can download the most recent pre-edit configuration.yaml (or other YAML file), typically containing plaintext MQTT passwords, REST credentials, webhook IDs, geofence coordinates, and shell_command definitions, with zero credentials.

Details

The backup feature is good, do_backup defaults to True and protects users from a bad edit. The issue is the location:

• custom_components/ha_mcp_tools/__init__.py:596, backup_dir = config_dir / "www" / "yaml_backups"
• custom_components/ha_mcp_tools/__init__.py:602, backup_file = backup_dir / f"{safe_name}.{timestamp}.bak"
• custom_components/ha_mcp_tools/__init__.py:606-607,692-693, backup path returned to caller and logged at INFO

<config>/www/ is /local/ and HA serves it unauthenticated by design (intended for static dashboard assets). An attacker discovers the path three ways: (1) it's returned to the MCP client in result["backup_path"]; (2) it's logged at INFO and recoverable via ha_get_logs; (3) the timestamp format is %Y%m%d_%H%M%S, 86,400 candidates per day, enumerable. Backups accumulate (no rotation), so a long-running install holds a chronological history.

Preconditions: ENABLE_YAML_CONFIG_EDITING=true (off by default), at least one YAML edit made, and the attacker can reach HA's port 8123 (LAN, or internet via Nabu Casa / reverse proxy).

PoC

A pytest E2E test against a fresh Docker HA container with the custom component installed (using the project's existing ha_container_with_fresh_config fixture):

[1] ha_config_set_yaml(yaml_path="template", action="add", ...) → success=True
[1] backup_path = 'www/yaml_backups/configuration.yaml.20260505_171335.bak'
[2] GET http://<ha>:8123/local/yaml_backups/configuration.yaml.20260505_171335.bak
    (no Authorization header)
[2] HTTP 200, 440 bytes, the full pre-edit configuration.yaml
[control] GET /api/config without auth → HTTP 401

The control proves the result is meaningful: the same instance returns 401 for an authenticated endpoint; only /local/ is unauthenticated by HA design.

Resolution

Fixed in 7.4.1.dev456 (PR #1180). The fix relocates new backups to <config>/.ha_mcp_tools_backups/ (config root, not served by /local/) and adds a one-time migration on integration setup that moves any pre-existing exposed backups, surfaces a persistent notification telling the user to rotate exposed secrets, and removes the legacy directory if empty.

The fix ships in the next biweekly stable release and is available immediately on the dev channel. Updating to a release containing the fix is sufficient, no manual action required for users who upgrade.

Manual cleanup (for users who cannot upgrade yet)

If you used ha_config_set_yaml on a vulnerable version and cannot wait for the next stable release, manually remove the exposed backups:

rm -rf <config>/www/yaml_backups/

Then rotate any secrets that may have been in the YAML files those backups captured (MQTT/REST credentials, webhook IDs, shell_command definitions, geofence coordinates). The directory is reachable at http(s)://<ha-host>:8123/local/yaml_backups/ until removed. After the next addon/package upgrade containing the fix, the integration will run this cleanup automatically and surface a persistent notification with the same rotation guidance.

CWE-552 (Files or Directories Accessible to External Parties). Affects users with ENABLE_YAML_CONFIG_EDITING=true who have made at least one YAML edit. Anyone who can reach HA port 8123 reads the most recent pre-edit config without credentials. CVSS 6.5 medium (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N); 7.5 high if HA is internet-exposed.

GHSA-G39V-CVJH-8FPF has a CVSS score of 6.5 (Medium). The vector is reachable from an adjacent network, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (7.5.0); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is GHSA-G39V-CVJH-8FPF? GHSA-G39V-CVJH-8FPF is a medium-severity security vulnerability in ha-mcp (pip), affecting versions < 7.5.0. It is fixed in 7.5.0.
2. How severe is GHSA-G39V-CVJH-8FPF? GHSA-G39V-CVJH-8FPF has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of ha-mcp are affected by GHSA-G39V-CVJH-8FPF? ha-mcp (pip) versions < 7.5.0 is affected.
4. Is there a fix for GHSA-G39V-CVJH-8FPF? Yes. GHSA-G39V-CVJH-8FPF is fixed in 7.5.0. Upgrade to this version or later.
5. Is GHSA-G39V-CVJH-8FPF exploitable, and should I be worried? Whether GHSA-G39V-CVJH-8FPF is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-G39V-CVJH-8FPF is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-G39V-CVJH-8FPF? Upgrade ha-mcp to 7.5.0 or later.