Dell published the advisory on 1 October. The CVE records landed five days later

This afternoon we sat down and queried, one by one, the thirteen own CVE identifiers listed in a Dell advisory published five days ago. Eight existed. Five returned 404. Twenty minutes later all thirteen were published: the registry filled up while we were writing this post.

The advisory is DSA-2026-448, covering Dell Container Storage Modules, the component that wires Dell storage arrays into a Kubernetes cluster. Initial release: 1 October 2026. Inside there are two flaws at the maximum score, CVSS 10.0, thirteen CVEs of Dell's own and another long batch inherited from Go dependencies. There is exactly one way out: move to version 1.18.0.

We do not run Dell arrays or that particular module: we operate Kubernetes and Docker Swarm, but with Proxmox VE and Ceph underneath. So what we are measuring here is not anybody's risk, but something else: how long your process takes to find out.

What we queried and what came back

The CVE programme has a public API that needs no key and no sign-up. You ask it for an identifier and it answers with the official record, or a 404 if it does not exist yet. We took the thirteen proprietary identifiers in the advisory and ran them through it. Here is the line, and anyone can repeat it right now:

for c in 63688 63692 67269 54472 61421 67273 67270 \
         76105 61411 70411 63689 63691 63690; do
  printf "CVE-2026-%s " $c
  curl -s "https://cveawg.mitre.org/api/cve/CVE-2026-$c" \
    | jq -r '.cveMetadata.datePublished // .error'
done

The timestamps are the ones the registry itself returns, not our reading of them. Last check: 15:42 UTC on 6 October 2026.

Fifty-seven minutes for all thirteen records, at one every four or five minutes. And look at the middle column: 10, 10, 9.9, 9.8, 9.8, 9.6, 8.2, 7.7, 7.7, 7.1, 6.5, 6.1, 5.4. Thirteen out of thirteen in descending order of severity, without a single exception; somebody is draining a queue sorted by CVSS. On our first query five were missing. We asked three more times while drafting this, and each time there was a new one; the last landed at 15:29:48, with the post already half written.

They are in NVD already. And they still do not help you

Many vulnerability management tools do not query the raw CVE registry: they match your inventory against the US national database, NVD, using CPE product identifiers. Without a CPE, a scanner has a piece of text and no automatic way of knowing whether it is about you. We asked about both 10.0s and one of the 9.8s at 15:29 UTC, right after closing the table above:

curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-63688" \
  | jq '{total:.totalResults,
         published:.vulnerabilities[0].cve.published,
         status:.vulnerabilities[0].cve.vulnStatus,
         cpe:(.vulnerabilities[0].cve.configurations != null),
         score:.vulnerabilities[0].cve.metrics.cvssMetricV31[0].type}'

{ "total": 1,
  "published": "2026-10-06T15:17:18.890",
  "status": "Awaiting Analysis",
  "cpe": false,
  "score": "Secondary" }

It is there. NVD did not follow the trickle: it pulled the whole batch in one pass at 15:17, some forty-five minutes after the first record appeared. The other three lines are the ones that count. Awaiting Analysis: NVD has not analysed it. configurations absent: there is no CPE, nothing to match your inventory against. And the only CVSS it carries is flagged Secondary, sourced from [email protected]: that 10.0 was put there by Dell, not by NVD. Identical in all three we checked.

There is some fine print worth knowing before you build a process on top of NVD. Since 15 April 2026, NIST prioritises enrichment for three groups: CVEs that appear in CISA's KEV catalogue, CVEs affecting software used within the US federal government, and CVEs for critical software as defined by Executive Order 14028. Everything else goes into a category NIST itself labels "Lowest Priority - not scheduled for immediate enrichment", adding bluntly that "we will no longer routinely provide a separate severity score for those CVEs". We checked the KEV catalogue, version 2026.10.04 with 1,734 entries: none of these thirteen CVEs is in it. So: no exploitation catalogued by CISA, which is good news, and at the same time none of them comes in through the one prioritised door an outsider can actually check.

Two clocks, not one

There is nobody to point at here, and that is what makes it hard to fix. Dell is its own numbering authority —every CVE record carries assignerShortName: dell—: it reserves the identifiers, publishes the advisory to its customers once the fix is ready, and fills in the public records afterwards. Thirteen records by hand take the afternoon they take. And NVD is doing exactly what it announced in April it would do. Both clocks work; what does not work is assuming they tell the same time.

The vendor's clock runs ahead, and the gap between the two is not fixed: it depends on which vendor, on how many records it has to fill in, and on whether the CVE falls into one of the three prioritised groups. Here it was five days to the record, and the CPE enrichment —the thing that lets a tool decide for you— may never arrive at all. If your procedure says "when the scanner flags it as critical, we open a ticket", you have just found out that trigger may never fire.

We already wrote about what you do when there is no patch. Here the patch has been available for five days and the process still has not noticed, because it is waiting for a third party to tell it.

What is inside, if it does concern you

For anyone running Dell CSM in a cluster, the gist of the records that are already public, in Dell's own words:

Those last two deserve their own paragraph, and here we are giving an opinion. A credential baked into a publicly distributed product was never a secret: it was one by oversight, not by design. Bumping the binary to 1.18.0 removes the credential from the code, but it does not revoke whatever is already deployed and trusting it. If your installation holds a signing secret or a token that shipped as a default and nobody changed, the version bump does not invalidate it. That has to be rotated by hand, and it is exactly the step that falls out of a process which measures patching by counting installed versions.

On how to read an advisory carrying many CVEs at once without being led by the headline, we already wrote about another batch of ten. It applies here too: the highest score is not always the one that hurts you most.

The question that is left

If the clock that runs ahead is the vendor's, the question stops being technical: who is subscribed to that advisory, and what do they do on a Thursday afternoon when it arrives? A CSI module lives exactly on the seam between two teams. Storage says that is Kubernetes. Platform says that is the array. Both are right and neither has it on their list.

We keep our inventory in NetBox and treat every production piece —including the internal ones— as what it is: something with an owner and an update window. What this episode leaves us with is one more column worth recommending: which vendor bulletin each component depends on, and who reads it. It is ugly to maintain, and it is the one that turns an advisory into a ticket the same day instead of waiting for a third party to translate it. That idea of one team with shared goals across security, infrastructure and data is exactly what our RID programme is, instead of three lists that never touch. And the part about somebody reading the advisory at five in the afternoon on a Tuesday is, literally, 24×7 support.

What we are not claiming

With four servers, one hypervisor and no component living between two vendors, you do not need this: one well-subscribed mailing list that somebody actually reads does the same job without the ceremony. It starts to matter when the seams appear —array plus orchestrator, firewall plus VPN concentrator, identity plus application—, which is exactly where the module in this post lives. And the conflict of interest, stated up front: we sell managed services and support. If your own people own that column, fine, and you owe us nothing; if you would rather we owned it, tell us. The bad option is the third one, which is the usual one.

Sources