CVE-2026-96770 PUBLISHED

s2s-proxy accepts untrusted client certificates

Assigner: Temporal
Reserved: 23.09.2026 Published: 23.09.2026 Updated: 23.09.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.

Metrics

CVSS Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:H
CVSS Score: 9.3

Product Status

Vendor Temporal Technologies, Inc.
Product s2s-proxy
Versions Default: unaffected
  • affected from 0.0.1-alpha to 0.2.2 (incl.)

Affected Configurations

Exploitation requires network access to an affected TLS server listener configured with skipCAVerification set to false. Available RPCs and namespaces are limited by the proxy's allowlists and the permissions granted to its Temporal credentials.

Workarounds

Restrict the listener to known peer addresses or a private network, or use a TLS terminator that verifies client certificates against the intended CA. These controls reduce exposure but do not fix the proxy defect.

Solutions

The fix is expected in version 0.2.3. Upgrade to version 0.2.3 or later when available.

Credits

  • Praetorian, who reported this issue responsibly to Temporal Technologies finder

References

Problem Types

  • CWE-296: Improper Following of a Certificate's Chain of Trust CWE

Impacts

  • An attacker who can reach the listener can connect as a trusted peer with a self-signed certificate and invoke allowed RPCs through the proxy's Temporal credentials. Impact depends on the RPC and namespace allowlists and the permissions granted to those credentials. A permissive deployment can expose workflow data or allow workflow changes and deletion. Data protected by a Payload Codec remains encrypted unless the attacker can also access the customer's Codec Server or encryption keys.