Socket Firewall CVE-2026-90651: the fix shipped in June

Socket Firewall sits between your package managers and the registries they pull from, and decides which packages are allowed onto your machines. CVE-2026-90651, published September 12, says that in registry mode before version 2.0.0 it did not verify upstream TLS certificates by default. The tool whose entire job is deciding what code you install accepted any certificate on the wire — including self-signed ones.

What actually happened

Per the CVE record, the defect is CWE-295, improper certificate validation, scored CVSS 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:L). When api_ssl_verify and upstream_ssl_verify were omitted from socket.yml, the generated configuration set SOCKET_API_SSL_VERIFY='false' and UPSTREAM_SSL_VERIFY='false', and the OpenResty/Lua HTTP client handling outbound requests accepted any certificate without validating the chain.

Two things break at once. An attacker positioned between Socket Firewall and an upstream registry can substitute package content in transit — that is the obvious one. They can also sit between the firewall and the Socket API and alter the allow/block decisions the firewall enforces. The scanner returns whatever the man in the middle says it returns.

There was also a window where the documented mitigation did not work. Setting both keys to true enables verification, but in versions before 1.1.334 the generated nginx configuration never emitted lua_ssl_trusted_certificate, so verification could not succeed without hand-patching the generated config to inject lua_ssl_trusted_certificate and lua_ssl_verify_depth.

Now the timing. Socket Firewall v2.0.0 — "Enable verified outbound connections by default" — was published June 29, 2026, crediting Alberto Garcia at Magic for the report. The CVE was published September 12, 2026. That is roughly 75 days during which the only signal available to anyone still on 1.x was a major version bump flagged as a breaking change.

And it is genuinely breaking: if your firewall talks to an internal registry behind a private CA, 2.0.0 will start rejecting it until you supply the CA through api_ssl_ca_cert / upstream_ssl_ca_cert.

Why Socket Firewall's blind spot matters for your supply chain

Read the failure mode plainly. A breaking-change major release with no advisory attached is exactly the upgrade a small team defers. Nothing was on fire. The release notes said "action may be required." So it sat in the backlog, and the thing sitting in the backlog was the control that decides which npm packages reach your build.

Three things follow.

Check your version tonight. If you run Socket Firewall in registry mode, anything below 2.0.0 shipped with verification off unless you explicitly turned it on — and below 1.1.334, turning it on did not work. Upgrade, then supply your private CA rather than disabling verification to make the error go away.

Treat security tooling as a tracked dependency. Most teams pin and monitor their application dependencies and run their security tools on whatever version got installed the day someone set it up. Put the proxy, the scanner and the agent in the same update pipeline as the app.

Assume your controls can be lied to. The interesting half of this bug is not package substitution, it is that the verdict channel was unauthenticated. Any control that phones home for a decision needs that channel verified, or the control is decorative. Our rule: if a tool's answer changes what ships, its transport gets pinned, verified, and logged.

Sources: CVE-2026-90651 record, Socket Firewall v2.0.0 release notes, Socket registry mode configuration reference.