Telnyx MCP EUVD-2026-67026

Exploitation requires the server to be running the Streamable HTTP transport (rather than the default stdio transport) with the vulnerable all-interfaces bind in versions through 6.83.0, and the attacker must have network reachability to that listening port. Given CVSS AV:N/AC:L/PR:N/UI:N, once the HTTP port is reachable there are no further prerequisites: no credential, no user interaction, and default header handling accepts requests with no auth. The principal limiting factor is exposure - deployments using stdio transport or where the port is confined to loopback/firewalled are not remotely reachable; the vulnerable HTTP-on-all-interfaces configuration is what enables unauthenticated exploitation.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N, score 9.3) aligns tightly with the description: remote, low-complexity, no authentication, no user interaction, with high confidentiality and integrity impact. This is a genuine high-priority issue rather than an inflated score, because exploitation requires only network reachability to the port and the payoff is direct abuse of the operator's telecom API credentials and a code-execution key. Mitigating real-world exposure: the danger is greatest where the server was deliberately or accidentally reachable beyond localhost, so any operator running it on a shared host, container with a published port, or non-loopback bind should treat it as urgent and audit exposure immediately. There is no CISA KEV listing and no EPSS figure in the provided data, and no public exploit was identified, so active exploitation is not evidenced - but the low attack complexity and credential-theft impact mean patching should not wait for exploitation signals.

An attacker who can reach the MCP HTTP port - for example on a shared host, an exposed container port, or a flat internal network - sends an MCP initialise and tool-dispatch request with no authentication headers. The server accepts it and executes the requested tools against the upstream Telnyx API using its own stored API key and code-execution key, letting the attacker abuse the victim's telecom account. No public exploit code was identified, but attack complexity is low (AC:L) and no user interaction is required.