CVE-2026-90651: Socket Firewall TLS Certificate Bypass

CVE-2026-90651 Overview

CVE-2026-90651 affects Socket Firewall (socketdev/socket-registry-firewall) running in registry mode before version 2.0.0. The product ships without upstream TLS certificate verification enabled by default. When api_ssl_verify and upstream_ssl_verify are omitted from socket.yml, the generated configuration sets SOCKET_API_SSL_VERIFY='false' and UPSTREAM_SSL_VERIFY='false'. The embedded OpenResty/Lua HTTP client then accepts any certificate, including self-signed or untrusted ones. This missing validation [CWE-295] enables machine-in-the-middle attackers to substitute malicious package content and alter allow/block decisions the firewall enforces.

Critical Impact
Attackers positioned on the network path between Socket Firewall and its upstream registry can inject malicious packages into downstream builds by tampering with firewall policy decisions and registry responses.

Affected Products

Socket Firewall (socketdev/socket-registry-firewall) registry mode, all versions before 2.0.0
Versions before 1.1.334 cannot successfully enable verification without manually patching the generated nginx configuration
Deployments relying on default socket.yml without explicit api_ssl_verify and upstream_ssl_verify settings

Discovery Timeline

2026-09-13 - CVE-2026-90651 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-90651

Vulnerability Analysis

Socket Firewall proxies package registry traffic and applies allow/block decisions based on responses from the Socket API. Outbound requests to both the Socket API and upstream package registries flow through an OpenResty/Lua HTTP client embedded in the generated nginx configuration. The client honors two environment variables, SOCKET_API_SSL_VERIFY and UPSTREAM_SSL_VERIFY, that control whether TLS peer certificates are validated.

When operators omit api_ssl_verify and upstream_ssl_verify from socket.yml, both variables are written as 'false'. The Lua client then accepts any presented certificate without validating the chain, hostname, or issuer. A network-positioned attacker can therefore terminate TLS with a self-signed certificate and rewrite responses in transit.

A secondary defect compounds the issue. In versions before 1.1.334, the generated nginx configuration did not emit a lua_ssl_trusted_certificate directive. Operators who set both keys to true still could not complete a successful TLS handshake against legitimate upstreams without manually patching the generated configuration.

Root Cause

The root cause is an insecure default configuration combined with improper certificate validation [CWE-295]. The configuration generator emits verify=false when the keys are unset, and the Lua HTTP client performs no chain validation in that mode. Version 2.0.0 changes the default for both settings to true.

Attack Vector

Exploitation requires network positioning between Socket Firewall and either the Socket API or the configured upstream registry. Suitable positions include compromised network infrastructure, ARP or BGP hijacks, malicious egress proxies, and DNS redirection. Once positioned, the attacker presents a crafted certificate, terminates the TLS session, and modifies responses. The attacker can substitute malicious package tarballs or flip firewall allow/block decisions so that blocked packages appear approved.

Detection Methods for CVE-2026-90651

Indicators of Compromise

Presence of SOCKET_API_SSL_VERIFY='false' or UPSTREAM_SSL_VERIFY='false' in the running container environment
Generated nginx configuration lacking a lua_ssl_trusted_certificate directive on versions before 1.1.334
Unexpected certificate issuers observed on outbound connections from Socket Firewall to api.socket.dev or configured upstream registries
Package tarball hashes served by the firewall that do not match the upstream registry's published integrity values

Detection Strategies

Inspect socket.yml across all deployments and flag any where api_ssl_verify or upstream_ssl_verify is missing or set to false
Compare Socket Firewall image digests against release v2.0.0 or later to identify vulnerable instances
Perform outbound TLS interception audits from Socket Firewall hosts and verify that only expected certificate authorities are trusted
Monitor package integrity by comparing served hashes against upstream registry metadata retrieved through an independent path

Monitoring Recommendations

Alert on any change to socket.yml or the generated nginx configuration in CI/CD or runtime environments
Log and review all TLS handshake failures and unexpected certificate chains from Socket Firewall egress traffic
Track newly installed package versions in downstream builds and correlate against firewall decision logs

How to Mitigate CVE-2026-90651

Immediate Actions Required

Upgrade Socket Firewall to version 2.0.0 or later, which defaults both verification settings to true
On any deployment still running an older version, explicitly set api_ssl_verify: true and upstream_ssl_verify: true in socket.yml
For versions between 1.1.334 and 2.0.0, redeploy after enabling verification to regenerate the nginx configuration with lua_ssl_trusted_certificate
Audit recently installed packages sourced through Socket Firewall for signs of tampering and rebuild affected artifacts from trusted mirrors

Patch Information

Version 2.0.0 sets SOCKET_API_SSL_VERIFY and UPSTREAM_SSL_VERIFY to true by default and emits the required trusted-certificate directive. Release details are available in the GitHub Release v2.0.0. Configuration options are documented in the Socket.dev Configuration Reference.

Workarounds

On versions 1.1.334 and later, set both verification keys to true in socket.yml and restart the container
On versions before 1.1.334, manually patch the generated nginx configuration to include a lua_ssl_trusted_certificate directive pointing at a valid CA bundle, then enable both verification keys
Restrict egress from Socket Firewall to known Socket API and registry endpoints through a controlled forward proxy that enforces certificate pinning

bash

# socket.yml — enforce TLS verification for API and upstream traffic
api_ssl_verify: true
upstream_ssl_verify: true