CVE-2026-90651 in Socket
Summary
by MITRE • 09/13/2026
Socket Firewall (socketdev/socket-registry-firewall) in registry mode before 2.0.0 does not verify upstream TLS certificates by default. When the api_ssl_verify and upstream_ssl_verify configuration keys are omitted from socket.yml, the generated configuration sets SOCKET_API_SSL_VERIFY='false' and UPSTREAM_SSL_VERIFY='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 api_ssl_verify: true and upstream_ssl_verify: true enables verification; however, in versions before 1.1.334, the generated nginx configuration did not emit lua_ssl_trusted_certificate, 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability in Socket Firewall prior to version 2.0.0 represents a critical failure in transport layer security due to the default disabling of TLS certificate verification. When operating in registry mode, the application relies on an OpenResty and Lua HTTP client stack to communicate with upstream package registries and its own API endpoints. By design, if the configuration keys api_ssl_verify and upstream_ssl_verify are omitted from the socket.yml file, the system defaults these settings to false. This default behavior instructs the underlying HTTP client to accept any TLS certificate presented by remote servers without performing standard chain validation. Consequently, self-signed certificates or those issued by untrusted Certificate Authorities are accepted as valid, effectively nullifying the security guarantees provided by HTTPS and exposing the communication channel to interception and manipulation.
This architectural flaw creates a severe risk of man-in-the-middle attacks against both internal API communications and external package retrieval operations. An attacker positioned within the network path between Socket Firewall and the upstream registry or API server can intercept traffic using tools such as mitmproxy or by configuring rogue DNS entries combined with SSL stripping techniques. Because the client does not validate the certificate chain, the attacker can present a crafted certificate that appears valid to the application but is actually controlled by the adversary. This allows for active content modification where malicious package binaries can be substituted for legitimate ones during download, leading to supply chain compromise. Furthermore, attackers can alter the allow or block decisions enforced by the firewall itself, potentially bypassing security policies and allowing unauthorized software execution within protected environments.
The severity of this issue is compounded by historical implementation gaps in earlier versions prior to 1.1.334. Even when administrators attempted to enable verification by setting api_ssl_verify and upstream_ssl_verify to true, the generated Nginx configuration failed to emit the necessary lua_ssl_trusted_certificate directive. This omission meant that without manual patching of the generated configuration files, TLS verification could not function correctly regardless of user intent. This lack of secure-by-default configuration in versions before 2.0.0 significantly increases the attack surface for organizations relying on default settings or automated deployment pipelines that do not explicitly override these insecure defaults. The vulnerability aligns with CWE-295 Improper Certificate Validation and is exploitable via MITM attacks categorized under ATT&CK technique T1071 Application Layer Protocol, specifically within HTTPS traffic manipulation scenarios.
To mitigate this risk, organizations must ensure they are running version 2.0.0 or later of Socket Firewall, where the default behavior for both api_ssl_verify and upstream_ssl_verify has been corrected to true. For environments still operating on older versions that cannot be immediately upgraded, it is imperative to explicitly set these configuration keys to true in socket.yml and manually verify that the generated Nginx configuration includes the lua_ssl_trusted_certificate directive pointing to a valid CA bundle. Regular auditing of TLS configurations and monitoring for certificate anomalies can further reduce exposure. Ultimately, enforcing strict certificate validation by default ensures integrity and authenticity of data exchanged with upstream registries and internal APIs, preventing adversaries from injecting malicious content or evading security controls through traffic interception.