A CVE record published overnight says an attacker in the path could have rewritten the allow and block decisions the firewall exists to enforce, and that for some versions the setting meant to prevent that could not be made to work.
What happened
NVD published CVE-2026-90651 at 12:17 a.m. UTC on Sunday, September 13, 2026. The record is marked Received, MITRE is the assigning source, and the weakness is CWE-295, improper certificate validation. The CVSS v3.1 score is 8.1, High, from the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:L. The affected range is every version of socketdev/socket-registry-firewall before 2.0.0.
Socket Firewall in registry mode sits between a developer’s package manager and the upstream registry. Socket’s own configuration reference describes it as an intermediary that intercepts package requests, checks them against Socket’s database for supply-chain risk, and allows or blocks the download according to policy. The documentation lists npm, PyPI, Maven, Cargo, Ruby Gems, NuGet, Go, Conda, and OpenVSX as supported ecosystems. It is, in other words, the component an organization installs specifically so that a malicious package never reaches a build.
The record describes what that component did with certificates. Quoting it: “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.”
The consequence, again in the record’s words: “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.”
That last clause is the part worth reading twice. The attack does not merely bypass the control. It rewrites the control’s answers.
The record then adds a second finding that appears nowhere in the vendor’s release notes: “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.” An operator on a build older than 1.1.334 who found the flags, read them correctly, and set both to true did not get verification. They got a configuration that could not work until they hand-edited generated output.
Version 2.0.0 changes both defaults to true. The project’s release page titles it “v2.0.0 — Enable verified outbound connections by default” and dates it to June 29; the listing does not state the time zone for the clock time it displays alongside. The body reads, in full: “The firewall now has api and upstream verify set to true to better match best security practices and prevent potential man-in-the-middle attacks out of the box. This does mean if your environment uses things like content proxies without custom CA certificates being imported it could introduce breaking functionality. Action may be required (breaking change): if your firewall connects to internal or private registries that use self-signed or privately issued certificates, you’ll need to provide your certificate authority so it can be trusted, or turn off verification for those connections.” The page closes with “Thanks to Alberto Garcia at Magic for reporting the issue.”
The release notes name no CVE, carry no severity, and describe the change as a breaking default and a security improvement. The record published this morning scores the same change 8.1 and files it as a certificate-validation vulnerability. Both documents are about the same behavior. They do not read as though they are.
Socket’s current configuration reference — the other reference the CVE cites — lists api_ssl_verify with a default of true and upstream_ssl_verify with a default of true, inheriting from api_ssl_verify when unset. It carries no version qualifier on either default. An operator running a 1.x build who opens that page today to check their posture will read that verification is on.
No source checked reports exploitation, and the CVE is not in the Known Exploited Vulnerabilities catalog.
Why it matters
The premise of a registry firewall is that the answer it returns is trustworthy. Every other supply-chain control an organization buys is downstream of that premise: the policy engine, the allowlist, the audit log that says a package was checked. If the transport carrying those answers accepts any certificate presented to it, then an attacker with a position on the path — a compromised egress proxy, a hostile network on a contractor’s laptop, a misconfigured corporate TLS terminator, a DNS answer bent toward the wrong host — does not have to defeat the policy. They get to write it.
This is a different and worse failure than an ordinary missing-verification bug. When a chat client skips certificate validation, an attacker reads messages. When the component that decides whether software may be installed skips certificate validation, an attacker decides whether software may be installed. The scoring vector reflects this, and it is unusual enough to point at: confidentiality is scored Low, integrity is scored High, and the scope is marked Changed. Most CWE-295 records lean on confidentiality, because most of them are about reading traffic. This one leans on integrity, because the interesting thing an attacker does here is not listen. It is substitute.
The attack complexity is High, and that is a real constraint rather than a formality. Somebody has to be in the path. But the population of machines running a registry firewall skews toward exactly the environments where being in the path is plausible: enterprise networks with inspecting proxies, build fleets behind egress gateways, self-hosted runners on networks their operators do not fully control. The control was bought because those networks are not trusted. The control then trusted them.
The lua_ssl_trusted_certificate detail is the part that should worry anyone who runs an older build. It converts a bad default into something closer to a trap. A careful operator — the kind who reads configuration references, who does not accept defaults, who turns knobs toward safety on principle — would have set both flags to true and moved on with a documented, auditable, entirely false belief that outbound connections were verified. Their configuration file would pass review. Their compliance evidence would look correct. This publication keeps finding the same pattern in different products: a security setting that is present, readable, and inert. A guard that fails open leaves no trace in the artifact a reviewer inspects.
There is also a timing gap of the sort that is becoming routine. The behavior changed on June 29. The identifier arrived roughly two and a half months later, in the small hours of a Sunday. Anyone whose vulnerability management keys on CVE IDs had no reason to prioritize the upgrade in July or August, because there was nothing to match. The release notes did say the change was security-relevant, and an operator reading them carefully would have upgraded. Operators reading release notes carefully is not a control.
What to do
Upgrade Socket Firewall to 2.0.0 or later. Treat it as the breaking change the vendor says it is: if your firewall reaches an internal registry or passes through a content proxy that presents a privately issued certificate, supply that certificate authority through api_ssl_ca_cert or upstream_ssl_ca_cert before you cut over, or the upgrade will break fetches rather than secure them.
Before upgrading, look at your current generated configuration rather than at your socket.yml. Check whether SOCKET_API_SSL_VERIFY and UPSTREAM_SSL_VERIFY are set to false, and, on builds older than 1.1.334, whether lua_ssl_trusted_certificate appears in the generated nginx configuration at all. Absent that directive, any true in your source configuration was not doing what it said.
Do not rely on the current documentation to tell you what your installed version does. The configuration reference describes 2.0.0 behavior with no version qualifier; the defaults it documents are not the defaults a 1.x build generates.
If your firewall has been running on an untrusted path — a network you do not control, a proxy you do not own — treat recent allow decisions as unverified rather than as evidence. Re-check the integrity of packages admitted through it against registry checksums, which is a cheaper exercise than it sounds for a lockfile-pinned build.
Sourcing note
Checked: the NVD record for CVE-2026-90651, published at 12:17 a.m. UTC on September 13, 2026, vulnStatus Received, assigning source MITRE; the project’s release page for tag v2.0.0 on GitHub, which is one of the two references the CVE cites; and Socket’s registry mode configuration reference, which is the other. All quotations above are reproduced from those pages. The Known Exploited Vulnerabilities catalog was read from the cisagov/kev-data GitHub mirror, catalog version 2026.09.11, because cisa.gov returns 403 to automated fetching; CVE-2026-90651 does not appear in it. Could not reach: GitHub’s REST API returned 403, so release timestamps come from the rendered release pages, which display a clock time without naming its time zone — this story therefore gives the release date and not the hour. Release notes for version 1.1.334 were not present in the release listing retrieved, so the lua_ssl_trusted_certificate claim rests on the CVE record alone and has not been confirmed against a vendor document. Unresolved: the vendor’s release notes do not reference a CVE or a severity, and neither the release page nor the documentation states that versions before 2.0.0 shipped with verification off; whether Socket intends to publish an advisory of its own is not known.