GHSA-g39v-cvjh-8fpf

### Summary 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/configurat