Vulnerabilities

mysql_mcp_server fails to validate Origin/Host headers when running in SSE/HTTP transport mode: the MCP Python SDK's DNS-rebinding protection is left disabled, no CORS or TrustedHost middleware is configured, all routes are unauthenticated, and the service binds to 0.0.0.0 by default. The flaw is triggered whenever MCP_TRANSPORT=sse is set; the default stdio mode is not affected. An attacker with network access to the service, or a victim browser coerced via DNS rebinding against a locally bound instance, can invoke the execute_sql tool to run fully attacker-controlled SQL without credentials, yielding complete data exfiltration and modification, and, if the MySQL account holds FILE privileges, arbitrary file read/write and potential remote code execution via webshell drop. Any deployment of mysql_mcp_server with SSE transport enabled is affected, including the 25 publicly reachable instances identified by internet-wide scanning. No public proof-of-concept or confirmed in-the-wild exploitation is known, and the issue is not listed in CISA KEV.

Do: Upgrade to mysql_mcp_server v0.4.2, which enables the SDK's DNS-rebinding protection via TransportSecuritySettings and recommends binding to 127.0.0.1. Until upgraded, avoid setting MCP_TRANSPORT=sse, bind the service to localhost only, and firewall the port from untrusted networks; also review the configured MySQL account's privileges, especially FILE, and audit for unexpected queries.

ESPHome Device Builder renamed its dashboard authentication environment variables from USERNAME/PASSWORD to ESPHOME_USERNAME/ESPHOME_PASSWORD with no backward-compatible fallback, so standalone deployments that set only the bare names silently lose authentication after upgrading. Because using_password resolves to false, both the REST auth middleware and the WebSocket login gate are disabled, leaving the dashboard open to any unauthenticated client with network access to its port; the only warning is a startup log banner that detached containers (docker run -d) never surface. An attacker who reaches the port gains full dashboard control — editing device configurations, flashing firmware, and per ESPHome's threat model, running arbitrary code at compile time and reading/writing files in the config and data directories. Only standalone Docker/pip deployments relying on the bare env vars are affected; Home Assistant add-on installs (which use --ha-addon and supervisor ingress) and deployments using --username/--password flags or the new ESPHOM_E* names are not. No public proof of concept is known and the flaw is not in the CISA KEV catalog.

Do: Check whether your deployment still sets only USERNAME/PASSWORD and whether startup logs show the 'WITHOUT AUTHENTICATION' banner (inspect with 'docker logs' on detached containers). Migrate credentials to the ESPHOM_EUSERNAME/ESPHOME_PASSWORD environment variables or the --username/--password CLI flags, and immediately restrict network access to the dashboard port (bind to localhost or place behind a firewall/VPN) since an exposed dashboard grants host-equivalent code execution. Home Assistant add-on installations need no action.