CVE-2026-90651

HighCVSS 8.1

Published: 13/09/2026(UTC)Updated: 22/09/2026(UTC)Translated: 13/09/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.19%

9th percentile - higher than 9% of all known CVEs

Summary

Socket Firewall (socketdev/socket-registry-firewall) in registry mode before 2.0.0 does not verify upstream TLS certificates 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', and the OpenResty/Lua HTTP client accepts any certificate without chain validation. An attacker positioned to intercept traffic can present a crafted certificate and modify responses, including substituting malicious package content or altering allow/block decisions.

Risk Assessment

The vulnerability allows an attacker to intercept and modify traffic between the firewall and the Socket API or upstream package registry, potentially leading to installation of malicious packages or bypassing security policies. The risk is high in environments where the firewall enforces supply chain security.

Recommendation

Update Socket Firewall to version 2.0.0 or later, which enables TLS verification by default. If updating is not possible, manually set api_ssl_verify: true and upstream_ssl_verify: true and ensure the nginx configuration includes lua_ssl_trusted_certificate.

Other vulnerabilities in Socket Firewall

CVE-2025-64726High
Socket Firewall binary versions prior to 0.15.5 are vulnerable to arbitrary code execution when run in untrusted project directories. An attacker can place a malicious `.sfw.config` file that sets the `NODE_OPTIONS` environment variable with a `--require` directive, executing malicious JavaScript before Socket Firewall's security controls are initialized.

Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS