Go Micro CVE-2026-105216

Exploitation requires that the target application (a) uses go-micro's shared TLS helper to enable TLS for its transport, broker, or registry connections, and (b) runs a version before 6.0.0 without the v5 opt-in MICRO_TLS_SECURE=true, which leaves InsecureSkipVerify=true by default. Critically, the attacker must ALSO achieve a man-in-the-middle / on-path network position between the communicating components - reflected by CVSS AC:H and AT:P - since the flaw only enables certificate forgery, not remote code delivery on its own. Limiting factors: no exploitation is possible against plaintext (non-TLS) deployments, against v6.0.0+ where verification is on by default, or against v5 deployments that explicitly set MICRO_TLS_SECURE=true; and the required network interception capability substantially narrows the realistic attacker set.

This is a genuine, structurally serious flaw rather than an inflated high-CVSS score. The root cause is confirmed by source-code evidence: go-micro's shared TLS helper sets InsecureSkipVerify=true by default, and the v6.0.0 CHANGELOG explicitly confirms 'TLS verification is on by default' as a breaking change, meaning all v5 and earlier deployments that did not set MICRO_TLS_SECURE=true were silently vulnerable. The CVSS 4.0 vector (AV:N, PR:N, UI:N, VC:H, VI:H) correctly reflects unauthenticated network exploitation with high confidentiality and integrity impact. However, two signals temper the raw 9.1: AC:H and AT:P indicate exploitation is NOT trivial - the attacker must already hold a privileged on-path/man-in-the-middle position, which is a meaningful barrier. No EPSS score, no KEV listing, and no public POC are present in the input, so there is no evidence of active or at-scale exploitation; the realistic risk is targeted interception by an adversary who already controls a network segment (e.g., shared cloud fabric, compromised router, hostile service mesh hop). Net: high-priority to patch for anyone running go-micro with TLS, but the on-path prerequisite makes mass opportunistic exploitation unlikely.

An attacker positioned on the network path between two go-micro services (for example on a shared cloud network segment or a compromised intermediate hop) presents an arbitrary self-signed certificate. Because the client's shared TLS helper has InsecureSkipVerify=true, the forged certificate is accepted without validation, letting the attacker transparently decrypt and modify gRPC, HTTP, RabbitMQ broker, and Consul/etcd registry traffic - harvesting authentication tokens and credentials in transit. No public exploit identified at time of analysis, though the trivial nature of a MITM TLS downgrade means weaponization would be straightforward for an on-path adversary.