External risk intelligence

s2s-proxy TLS Listener Certificate Verification Bypass.

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-96770

The s2s-proxy is a component used in Temporal service architectures. While it handles TLS connections and RPCs, it is typically deployed as internal infrastructure for service-to-service communication or sidecar proxies rather than a public-facing edge gateway or web application. Plausible internet reachability exists in certain configurations, but it is not a common internet-facing service.

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory highlights a critical vulnerability in the s2s-proxy, a component used for secure communication within certain service architectures. The flaw allows unauthorized access by bypassing certificate verification, potentially enabling attackers to invoke internal operations. The main concern is to confirm if this specific technology is in use and assess any exposure.

Attackers bypass security checks.
Protects internal service-to-service communication.
Confirm relevance and assess potential exposure.

Attack Path

How an attacker could exploit the issue

An attacker could connect to the vulnerable proxy over the network using their own self-signed certificate, bypassing the need for trusted credentials or certificates. This would allow them to interact with the proxy and potentially access internal services or data if the proxy's configuration permits it.

No authentication is required.
Attackers can invoke RPCs with a self-signed certificate.
Compromise of configured proxy RPCs.

Live Threat

Current exploitation, exposure, and threat context

The `s2s-proxy` could allow an attacker to establish a TLS connection and invoke RPCs by using a self-signed certificate. This is possible when the proxy is configured to skip certificate verification and the attacker can present their own certificate and private key. The affected TLS server listener does not verify the client certificate against a configured Certificate Authority, only that the client possesses the private key corresponding to the presented certificate.

Server configurations and credentials.
Unauthenticated TLS connection.
Unauthorized RPC invocation.

Operational Fix

Recommended remediation, mitigation, and detection steps

The s2s-proxy is likely managed by platform or infrastructure teams, with application owners needing to understand its impact on their services. The initial step is to identify all deployments, confirm their reachability and criticality, and then consult with accountable owners to prioritize remediation within planned maintenance windows.

Platform or Infrastructure teams own remediation.
Verify proxy reachability and service criticality.
Coordinate vendor updates and risk mitigation.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the s2s-proxy and how is it used?

The s2s-proxy is a component designed for secure service-to-service communication within Temporal architectures. It functions as a specialized intermediary or sidecar proxy that manages TLS connections and facilitates remote procedure calls (RPCs) between services, ensuring that data moving across the infrastructure is handled according to defined security policies.

What is the vulnerability in CVE-2026-96770?

This vulnerability is classified as CWE-296: Improper Following of a Certificate's Chain of Trust. Essentially, the proxy fails to validate client certificates against a trusted Certificate Authority. Instead, it only checks that the client holds a private key. This flaw allows an attacker to bypass authentication entirely by presenting any self-signed certificate.

Does this flaw trigger if I use trusted certificates?

The vulnerability is not triggered by the validity of the certificate presented; it occurs because the proxy's TLS listener is misconfigured to use Go's RequireAnyClientCert mode. This mode explicitly skips verification against a CA, meaning even if a legitimate, CA-signed certificate is used, the proxy fails to perform the necessary trust validation. The proxy ignores the certificate's authenticity, accepting any connection that can present a private key.

How relevant is this CVE for my environment?

According to Halo Surface Signal, s2s-proxy is typically deployed as internal infrastructure rather than a public-facing gateway. While it is less likely to be directly accessible from the internet, you should assess whether any proxy instances are inadvertently reachable. The risk is highest if the component can be reached over a network by unauthorized entities, as they could then attempt to invoke RPCs without credentials.

How should I respond to the CVE-2026-96770 advisory?

Begin by auditing your infrastructure to locate all deployments of s2s-proxy versions 0.2.2 and earlier. Once identified, evaluate the network reachability of these instances to determine if they are exposed to untrusted segments. Work with your platform or infrastructure teams to coordinate a plan for updating to a secure version that correctly enforces CA-based certificate validation.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.