CVE-2026-90651

Socket Firewall (socketdev/socket-registry-firewall) in registry mode before version 2.0.0 generates configuration with SOCKET_API_SSL_VERIFY='false' and UPSTREAM_SSL_VERIFY='false' whenever the api_ssl_verify and upstream_ssl_verify keys are omitted from socket.yml, causing the OpenResty/Lua HTTP client to accept any certificate, including self-signed or untrusted ones, without chain validation. A network-level man-in-the-middle positioned between the firewall and the Socket API or an upstream package registry can present a crafted certificate and modify traffic in transit. This allows substitution of malicious package content served to builds as well as tampering with the allow/block decisions the firewall enforces, undermining the tool's core supply-chain security purpose. All self-hosted registry-mode deployments before 2.0.0 that rely on the default settings are affected; on versions before 1.1.334, even explicitly enabling verification failed without manually patching the generated nginx configuration because lua_ssl_trusted_certificate was not emitted. No public proof of concept is known and the vulnerability is not listed in the CISA KEV catalog.

What to do: Upgrade Socket Firewall to version 2.0.0 or later, where TLS verification defaults to true for both the Socket API and upstream registries. If upgrading is not immediately possible, ensure you are on at least 1.1.334 and explicitly set api_ssl_verify: true and upstream_ssl_verify: true in socket.yml; on older versions you must manually add the lua_ssl_trusted_certificate directive to the generated nginx configuration for verification to actually work. Inspect generated configs for SOCKET_API_SSL_VERIFY='false'/'UPSTREAM_SSL_VERIFY='false', run the firewall only on trusted network paths in the meantime, and consider auditing packages fetched through affected instances for tampering.