Summary
go-micro before 6.0.0 disables TLS certificate verification by default in a shared transport helper. A network attacker positioned between communicating services may impersonate endpoints, intercept traffic, or modify gRPC, HTTP, RabbitMQ, Consul, and etcd communications, potentially exposing credentials and authentication tokens.
Affected context
The vulnerability occurs in go-micro deployments that rely on the shared TLS helper for service communication and leave certificate verification disabled. Risk may extend across gRPC transport, HTTP and RabbitMQ brokers, and Consul or etcd registries when traffic crosses an attacker-observable network path.
Exploit preconditions
- Attack surface: TLS-protected service, broker, or registry connections
- Required access: Network positioning sufficient to observe or interfere with communication
- Trigger point: Establishment of a TLS connection using the shared helper
- Why exploitation is possible: Certificate verification is disabled, allowing an endpoint to accept certificates that are not trusted for the intended peer
Why this happens
The underlying defect is a failure to authenticate the remote certificate during TLS negotiation. Setting InsecureSkipVerify to true by default causes the client to encrypt traffic without verifying that the peer is the legitimate service, which maps to CWE-295: Improper Certificate Validation. Encryption alone does not prevent endpoint impersonation when identity validation is omitted.
Potential impact
- An attacker may impersonate a service, broker, or registry endpoint
- Network traffic could be intercepted or modified
- Authentication tokens, credentials, and other secrets may be disclosed
- Requests or service-discovery data could be redirected to attacker-controlled systems
- Compromised communications could enable unauthorized access or follow-on attacks
General mitigation guidance
Mitigation generally focuses on making certificate and hostname validation mandatory for every TLS connection.
Common defensive patterns include:
- Use secure-by-default TLS configurations that verify certificate chains and peer identities
- Configure explicit trust stores and narrowly scoped certificate authorities
- Avoid globally disabling verification, including through convenience helpers or environment settings
- Protect private keys, credentials, and registry access with least privilege
- Prefer mutually authenticated TLS where service identity assurance is required
- Segment broker, registry, and service traffic to reduce exposure to untrusted networks
- Treat certificate-validation bypasses as exceptional, reviewed, and time-limited configuration
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis searches for
InsecureSkipVerify: trueand equivalent certificate-validation bypasses - Code review checks for shared TLS helpers that disable verification by default
- Configuration audits covering gRPC, HTTP, RabbitMQ, Consul, and etcd clients
- Network testing that presents an untrusted or mismatched certificate and confirms connection rejection
- Policy enforcement requiring validated trust stores, hostname checks, and documented exceptions
- Automated security review tools that flag disabled TLS verification and insecure transport defaults
