Socket Firewall in registry mode before version 2.0.0 does not verify upstream TLS certificates when the api_ssl_verify or upstream_ssl_verify keys are omitted from socket.yml. The generated configuration sets these variables to false, and the OpenResty/Lua HTTP client accepts any certificate, including self‑signed ones, without validating the chain. An attacker able to intercept traffic between the firewall and the Socket API or an upstream package registry can present a forged certificate, modify responses, inject malicious package content, or alter the firewall’s allow/deny decisions. The flaw is an instance of improper validation Based on the description, it is inferred that this flaw could allow remote code execution on clients that retrieve compromised packages.

All installations of Socket:Socket Firewall running registry mode versions earlier than 2.0.0 are affected. This includes the 1.x series, particularly 1.1.x where default verification is false and the generated Nginx configuration omits lua_ssl_trusted_certificate. Beginning with version 2.0.0, the default for api_ssl_verify and upstream_ssl_verify is true are retained.

The CVSS score of 8.1 indicates high severity, while the EPSS score of < 1% shows a very low but nonzero likelihood of exploitation. The vulnerability is not listed in CISA’s KEV catalog. Attackers would need network proximity or control over the TLS termination point to launch a man‑in‑the‑middle; this vector is inferred from the description. Because Socket Firewall is widely deployed in production, the risk remains significant if the default settings are not overridden.