Apache Storm’s 14 new CVEs published unscored; CISA backfilled them five hours later, and CVE-2026-82434 now carries both a 10.0 and a 6.5

Fourteen Apache Storm CVE records went live Monday with almost no severity data; CISA’s Authorized Data Publisher wrote CVSS v3.1 scores into them five hours later, and on the one record Apache had scored itself the two numbers are 10.0 and 6.5.

What happened

Apache’s security team published fourteen CVE records against Apache Storm on Monday, September 14, 2026, in two waves: CVE-2026-82439 and CVE-2026-84179 at 2:17 p.m. UTC, then twelve more — CVE-2026-82426 through CVE-2026-82438 — at 3:17 p.m. UTC. All are assigned by [email protected], and all carry the same affected range: org.apache.storm artifacts from 3.0.0 up to but not including 3.1.0.

Thirteen of the fourteen arrived with no CVSS score of any kind. The exception is CVE-2026-82434, which Apache scored itself on CVSS v4.0 at 10.0 CRITICAL, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H.

At 8:16 p.m. UTC, just over five hours after the second wave, CISA’s Authorized Data Publisher wrote CVSS v3.1 scores into the batch. The lastModified stamps run from 2026-09-14T20:16:54.527 to 2026-09-14T20:16:57.580, a four-second sweep. Checked one record at a time, the scores CISA added are:

• CVE-2026-82431 — 9.8 CRITICAL, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. SimpleACLAuthorizer ignores nimbus.groups when nimbus.users is empty.
• CVE-2026-82435 — 9.8 CRITICAL. The worker’s Netty decoder sizes buffers from an attacker-supplied length field ahead of SASL authentication.
• CVE-2026-82439 — 9.8 CRITICAL. The DRPC server’s function-name-to-queue map never evicts entries.
• CVE-2026-82426 — 6.5 MEDIUM. Nimbus accepts any server-side path as a topology jar, unchecked.
• CVE-2026-84179 — 6.5 MEDIUM. Merged Nimbus daemon configuration reaches read-only topology users with keystore and truststore passwords unredacted.
• CVE-2026-82434 — 6.5 MEDIUM, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N.
• CVE-2026-82437 — 4.3 MEDIUM. Logviewer daemon log endpoints ignore logs.users and logs.groups.

One record in the batch was skipped. CVE-2026-82438 still carries no CVSS metric block at all, and its lastModified is identical to its published time, 2026-09-14T15:17:10.900 — the sweep did not touch it. It is not a minor entry — Apache’s description covers three separate cross-origin failures at once:

“Three separate mechanisms allowed a web page on an unrelated origin to read responses that Storm’s HTTP components served to an authenticated user. The Logviewer reflected the request’s Origin header back in Access-Control-Allow-Origin while also sending Access-Control-Allow-Credentials: true. … The shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name where an initialisation parameter name was expected. … Finally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET request.”

The 10.0 and the 6.5 describe the same flaw

CVE-2026-82434 is the one record where the two sources meet, and they do not agree: Apache’s 10.0 on v4.0 and CISA’s 6.5 on v3.1 now sit in the same record. Usefully, the record contains the text needed to test both. Apache’s own description says Nimbus “served that configuration verbatim to any caller holding read-only topology permissions.” That is a privilege requirement. Apache’s 10.0 vector sets PR:N — no privileges required — which the sentence directly above it does not support. CISA’s PR:L matches the description.

On integrity the error runs the other way. The description says the leaked ZooKeeper payload “is not read-only,” that “the cluster state implementation uses write-capable ACLs for worker heartbeats, backpressure and error state, so a recipient can forge or remove that state for the topology concerned,” and then narrows it: “It is not a write credential on assignments.” CISA scored integrity impact I:N — none at all. Apache’s VI:H and SI:H read as too much; CISA’s I:N reads as too little.

Why it matters

The gap between 3:17 p.m. and 8:16 p.m. UTC is the practical problem. For five hours on a Monday, fourteen Storm records were public and feeding every scanner that polls NVD, with no severity on thirteen of them. Anyone whose triage queue sorts by CVSS saw a block of entries with nothing to sort on. Three turned out to be 9.8s. A team that swept the morning’s new records and moved on has already seen this batch at its lowest apparent priority, and will not necessarily look again.

This is not a CISA failure; the ADP exists to fill gaps a CNA leaves, and filling fourteen records in four seconds on the same day is fast work. It is a reminder that a CVE’s severity is not a property of the flaw — it is a field somebody writes later, and until they write it the record is not silent, it is empty, which reads very differently to an automated queue.

The disagreement on CVE-2026-82434 is the more durable lesson. Two competent sources read the same paragraph and produced 10.0 and 6.5, and neither vector matches what the paragraph says. That is an argument for reading the description whenever the number is going to drive a decision. Storm’s own text here is unusually good — it says what the credential can and cannot do more precisely than either vector manages.

The affected range names exactly one release

Every record scopes the flaw to 3.0.0 through before 3.1.0. On Maven Central, the storm-core version list goes 2.8.9, then 3.0.0, then 3.1.0 — so the affected range, read literally, covers a single shipped release. Everything on the 2.x line, through 2.8.9, falls outside it, and a scanner matching on the stated range will report those clusters clear.

The records do not say whether the 2.x line was examined and found unaffected or simply not examined. Several of the flaws sit in code with a long history: SimpleACLAuthorizer, the setuid worker-launcher, the Netty pipeline ordering. That is a question for Apache, not an assertion here — Maven Central artifact downloads are blocked by this container’s egress policy, so no source-level check of 2.x was possible. It is worth an operator’s own five minutes if they run 2.x.

One more gap: CVE-2026-82436 sits between two published records and returns no result from the NVD API as of this writing. It is named so nobody assumes the batch is contiguous.

What to do

Upgrade to Apache Storm 3.1.0. It has been on Maven Central since September 12, 2026, at 10:38 p.m. UTC, two days before the CVEs published, so the fix was in place before the disclosure. It is the single action that addresses all fourteen.

Before you upgrade, check one configuration. CVE-2026-82431 only bites a specific setup. Apache’s description is explicit: “An operator who restricted cluster access by group alone, leaving nimbus.users unset, therefore received no restriction at all,” and “Both lists left empty continues to mean that no restriction is configured, which is the shipped default and is unchanged.” So: if you set nimbus.groups and left nimbus.users empty, your group restriction has never applied and every authenticated principal can call submitTopology, beginFileUpload and getNimbusConf. Apache adds that “the failure is silent; nothing in the logs or the configuration indicates that the group list is being ignored.” The 9.8 does not tell you this; the description does.

Rotate ZooKeeper topology credentials after upgrading, not just before. CVE-2026-82434 says the submission client “logged the generated payload at INFO on every submission that generated one,” and the SASL handlers logged it at DEBUG. Upgrading stops the leak; it does not unwrite the logs. Any support bundle or log archive pulled from a 3.0.0 cluster may hold storm.zookeeper.topology.auth.payload values that are still live.

Check what is reachable. CVE-2026-82435 acts on frames before authentication, so a worker slot port reachable from an untrusted network is exposed however the cluster is authenticated. CVE-2026-82439 targets DRPC, whose authorizer Apache notes defaults to unset. Both need only TCP connectivity.

Do not triage this batch by scanner severity this week. Thirteen of fourteen had no score for five hours, one still has none, and the one with two has two that disagree.

Sourcing note

Scores and timestamps here were read one record at a time from the NVD API at services.nvd.nist.gov/rest/json/cves/2.0?cveId=, which republishes the CNA’s record. Individually verified in this run, with published and lastModified timestamps and full metric blocks: CVE-2026-82426, CVE-2026-82431, CVE-2026-82434, CVE-2026-82435, CVE-2026-82437, CVE-2026-82438, CVE-2026-82439 and CVE-2026-84179. CVE-2026-82427 through CVE-2026-82430, CVE-2026-82432 and CVE-2026-82433 were seen only in a windowed keyword query, which is why no score is given for them above.

That caution is not theoretical: the windowed query in this run returned CVE-2026-82438 as 8.1 HIGH, while two separate single-record reads of it show no CVSS metric block at all. The per-record read is the one to trust, and any score attributed to this batch elsewhere should be checked against a single-CVE fetch before it is acted on.

Apache’s advisory thread on lists.apache.org could not be read from here — the archive renders as an empty single-page application to an automated fetch — and the Apache Storm project’s security.html page returned a 404. The oss-security copies at openwall.com returned subject lines only; the one for CVE-2026-82431 reads “CVE-2026-82431: Apache Storm Client: Authorization Bypass When nimbus.groups Is Configured Without nimbus.users.” All quoted description text above therefore comes from the NVD copy of the CNA record, not from the mailing list post.

Release dates come from the storm-core Maven Central metadata, which gives <release>3.1.0</release> and lastUpdated 20260912223857. CVE-2026-82436 returned zero results from the NVD API; NVD has previously returned zero for records that exist, so its absence is reported, not concluded.

Unresolved: whether Storm 2.x is affected and simply out of the stated scope; whether CVE-2026-82438 will receive a score; and which of the two scores on CVE-2026-82434, if either, its source would defend against the description. No exploitation of any of these has been reported by any source checked, and none is claimed here.