CVE-2026-96770 in s2s-proxy
Summary
by MITRE • 09/23/2026
All published s2s-proxy versions through 0.2.2 are affected. In versions 0.1.16 through 0.2.2, TLS server listeners use Go's RequireAnyClientCert mode when skipCAVerification is false. This mode checks that the client holds the certificate's private key but does not verify the certificate against the configured CA. An attacker can therefore use a self-signed certificate and key to establish a TLS and yamux connection, then invoke RPCs allowed by the proxy's configuration and Temporal credentials. No certificate or private key trusted by the deployment, and no Temporal credential, is required.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The s2s-proxy software versions ranging from 0.1.16 through 0.2.2 contain a critical authentication bypass vulnerability rooted in improper TLS client certificate verification logic. When the skipCAVerification configuration flag is set to false, indicating an intent to enforce strict mutual TLS authentication, the underlying Go implementation utilizes RequireAnyClientCert mode for server listeners. This specific operational mode performs only a cryptographic proof-of-possession check, verifying that the connecting client holds the private key corresponding to the presented certificate's public key. Crucially, it fails to validate the certificate against any configured Certificate Authority or trusted root store. Consequently, the system accepts any validly signed TLS handshake where the client can prove ownership of the key pair, regardless of whether the identity represented by that certificate is authorized within the deployment's security policy.
This architectural flaw allows an attacker with network access to establish a fully authenticated connection using self-signed certificates and keys generated locally without needing approval from any trusted authority. Once the TLS tunnel and subsequent yamux multiplexed connections are established, the proxy proceeds to authorize requests based solely on its internal configuration rules and Temporal credentials rather than validating the client's identity via X509 certificate chains. This effectively neutralizes the intended security control of mutual authentication, reducing it to a mere connectivity check that can be trivially spoofed by any entity capable of generating cryptographic key pairs.
The operational impact is severe, as it enables unauthorized access to remote procedure calls exposed by the proxy. An attacker can invoke RPCs permitted by the proxy's configuration and leverage Temporal credentials to interact with backend services without possessing legitimate certificates or private keys trusted by the organization. This bypass undermines the principle of least privilege and trust boundaries established in zero-trust architectures, potentially leading to data exfiltration, unauthorized state manipulation, or further lateral movement within the infrastructure depending on the permissions granted to the invoked RPCs.
To mitigate this vulnerability, organizations must immediately upgrade s2s-proxy to a version later than 0.2.2 where the TLS verification logic has been corrected to properly validate client certificates against trusted Certificate Authorities as intended by the skipCAVerification setting. Until an update is applied, administrators should consider network-level controls such as IP whitelisting or firewall rules restricting access to s2s-proxy ports to only known and trusted source addresses. Additionally, auditing Temporal credentials for unusual activity can help detect exploitation attempts that may have occurred during periods of exposure. This vulnerability aligns with CWE-287 Improper Authentication, specifically the failure to verify identity claims against a trust anchor, and maps to MITRE ATT&CK technique T1078 Valid Accounts if an attacker leverages stolen or misconfigured credentials after bypassing the certificate check.