CVE-2026-90651: High severity socketdev/socket-registry-firewall vulnerability
Socket Firewall (socketdev/socket-registry-firewall) in registry mode before 2.0.0 does not verify upstream TLS certificates by default. When the apisslverify and upstreamsslverify configuration keys are omitted from socket.yml, the generated configuration sets SOCKETAPISSLVERIFY='false' and UPSTREAMSSLVERIFY='false', and the OpenResty/Lua HTTP client used for outbound requests accepts any certificate, including self-signed and otherwise untrusted certificates, without validating the chain. An attacker positioned to intercept traffic between Socket Firewall and the Socket API or an upstream package registry can present a crafted certificate and modify responses in transit, including substituting malicious package content or altering the allow/block decisions the firewall enforces. Setting apisslverify: true and upstreamsslverify: true enables verification; however, in versions before 1.1.334, the generated nginx configuration did not emit luassltrustedcertificate, and thus verification could not be used successfully without manually patching the generated configuration. Version 2.0.0 changes the default for both settings to true.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
socketdev/socket-registry-firewallto a version that resolves this vulnerability.Fixed in 2.0.0 - Configuration
Set api_ssl_verify: true in socket.yml so Socket Firewall verifies the TLS certificate for connections to the Socket API (including internal proxy termination cases).
Socket Firewall (socketdev/socket-registry-firewall) api_ssl_verify = true - Configuration
Set upstream_ssl_verify: true in socket.yml so Socket Firewall verifies the TLS certificate for connections to the upstream package registry (including internal proxy termination cases).
Socket Firewall (socketdev/socket-registry-firewall) upstream_ssl_verify = true - Configuration
When using an internal TLS-terminating proxy or a private CA, provide the CA for Socket API connections via api_ssl_ca_cert (so certificate verification can succeed).
Socket Firewall (socketdev/socket-registry-firewall) api_ssl_ca_cert = <private CA certificate content/path> - Configuration
When using an internal TLS-terminating proxy or a private CA, provide the CA for upstream registry connections via upstream_ssl_ca_cert (so certificate verification can succeed).
Socket Firewall (socketdev/socket-registry-firewall) upstream_ssl_ca_cert = <private CA certificate content/path> - Configuration
For versions before 1.1.334, api_ssl_verify/upstream_ssl_verify could not be used successfully because generated nginx config did not emit lua_ssl_trusted_certificate; manually patch the generated configuration to include lua_ssl_trusted_certificate so verification can work.
Socket Firewall (socketdev/socket-registry-firewall) lua_ssl_trusted_certificate = present (manually patch generated config) - Compensating control
If you must remain on a Socket Firewall version earlier than 2.0.0 and registry mode is used, compensate by ensuring upstream TLS certificates are verified (since registry mode before 2.0.0 does not verify upstream TLS certificates by default).
Event History
Frequently Asked Questions
Which deployments are exposed by the insecure default?
Registry-mode deployments before 2.0.0 are exposed when api_ssl_verify and upstream_ssl_verify are omitted from socket.yml. In that case, generated configuration disables certificate verification for both Socket API and upstream registry connections.
What does an attacker need to exploit this issue?
An attacker must be positioned to intercept traffic between Socket Firewall and either the Socket API or an upstream package registry. They can then present an untrusted or self-signed certificate that the outbound HTTP client accepts.
What can an attacker do after intercepting the connection?
They can modify responses in transit, including substituting malicious package content or changing the allow/block decisions enforced by the firewall.
What mitigation is available if an upgrade to 2.0.0 is not immediately possible?
Set api_ssl_verify: true and upstream_ssl_verify: true in socket.yml. For versions before 1.1.334, this also requires manually patching the generated nginx configuration because it does not emit lua_ssl_trusted_certificate, preventing verification from working successfully otherwise.
How can I determine whether my configuration is affected?
Inspect socket.yml for omitted api_ssl_verify and upstream_ssl_verify settings, and inspect the generated configuration for SOCKET_API_SSL_VERIFY='false' and UPSTREAM_SSL_VERIFY='false'. On versions before 1.1.334, also check whether lua_ssl_trusted_certificate is present if certificate verification has been enabled.