We Said It Was Still Not in KEV. Eight Days Later CISA Added It. The Fix Had Been Available for Forty-Two Days.
On October 15 we published a post about Nextcloud servers being backdoored through their built-in office app, and we put the complaint in the headline: it is still not in KEV. On October 23 CISA added CVE-2026-110447 to the Known Exploited Vulnerabilities catalog. Eight days after we asked.
This is a loop-closing post, so here is the whole loop, including the parts that do not flatter us.
What changed
CVE-2026-110447 is now in the catalog, listed as "Collabora Online – Built-in CODE Server OS Command Injection Vulnerability," added October 23, 2026. Known ransomware use: unknown.
We pulled our own mirror of the catalog this morning to check. It is there. It is also, as far as our mirror goes back, the first Collabora entry CISA has ever listed. Every other catalog hit for the string Collabora is Zimbra Collaboration Suite or Citrix Content Collaboration, which are different products that happen to share a word.
So if you run Nextcloud with the built-in CODE app and you are a federal agency, this one now has a deadline attached: Monday, October 26. Three days from listing, which matches what we found in August — CISA has not issued a 21-day window since March, and the median is now three days.
If you are a school, a nonprofit or a ten-person firm, which is who actually runs this software, nothing about your risk changed on October 23. It changed on September 10, when the attacks started.
The four clocks
This is the part worth keeping. Four dates, all public, all checkable:
September 9 — the fix is committed to Collabora's repository.
September 10 — the first attack appears in an administrator's access log.
September 11 — version 26.4.303 ships with the fix and no security notice.
October 14 — the CVE and the advisory are published.
October 23 — CISA adds it to KEV.
Which gives you:
43 days from the first logged attack to the federal catalog.
42 days in which a fix existed, was shipped, and the bug it fixed was not on the list anyone sorts their patch queue by.
9 days from the advisory to the catalog entry.
8 days from our post asking where the entry was.
The forty-two is the number. Not the nine, and not the eight. A patch sat in a release for six weeks while the hole it closed was being used, and the mechanism most defenders trust to tell them what is urgent said nothing, because that mechanism cannot speak until a CVE exists and exploitation is confirmed. The CVE did not exist until October 14. The confirmation came after that.
None of this is a failure by CISA. The catalog did exactly what it is built to do, in the order it is built to do it. The problem is that a lot of people use it as a priority queue, and it is not one. It is a federal compliance list that happens to be an excellent free signal.
What we got right, and what we did not claim
We said on October 15 that a patch queue sorted by KEV membership would sort this one to the bottom while it was being exploited. Eight days later the entry arrived and the argument held. That is the useful part.
What we did not claim then and are not claiming now: we did not find this. Two Nextcloud administrators did, by reading their own access logs, and a third found it because Nextcloud's integrity checker flagged a new PHP file. The credit belongs to GitHub user HeikoBw, who opened the issue on September 11, to the administrators who filed the two reports after his, to reporter wwwshellcodeit who filed the CVE, and to Collabora's maintainers who shipped a four-line fix in two days.
We got our indicators the same way you could have: by reading that GitHub issue and the reporting that followed. They went into our feed on October 15 under the source manual-batch-nextcloud-collabora-110447 — two attacker IP addresses at confidence 80, the web shell hash at 90, and the two callback tokens. Every record says in its own description that it is third-party reporting and not a DugganUSA observation. That was true on October 15 and it is still true.
So this is not a detection lead. It is a coverage-timing result: we wrote about an exploited bug eight days before the federal catalog listed it, using public reports anyone could read. The honest version of that sentence is less impressive than a scoop and more useful, because it is repeatable by anyone willing to read a GitHub issue.
What we still cannot see
We checked our edge again today, and we have to report the same non-answer we reported on October 15.
Our exploit-path checker has no harvested fingerprint for CVE-2026-110447, which means there is nothing for it to match our edge traffic against. On October 15 we searched every sensor we have — edge blocks, edge canaries, origin honeypot — for the richdocumentscode path and both attacker addresses across roughly 79,000 records, and found zero.
That zero was not evidence then and it is not evidence now. We do not run Nextcloud. We have no canary on that path. A sensor that could not have fired tells you nothing when it does not fire, and we would rather say so twice than let a clean dashboard do the talking. Nine days later the honest status of our own visibility into this bug is unchanged: unmeasured.
If you have not patched
The advice has not moved, and none of it needs us.
Upgrade the richdocumentscode app to 26.4.303 or later, or remove it. Disabling it is not sufficient — that is Collabora's own wording, because the vulnerable file is a plain PHP script your web server runs directly whether the app is switched on inside Nextcloud or not. Nextcloud 29 and older cannot install the fixed version, so upgrade Nextcloud or take the app out.
Then look for leftovers. List any file in your Nextcloud apps folder whose name starts with shx and ends in .php, then search the rest of your web root. Read your access logs back to September 10 for requests to the app's proxy script carrying encoded path traversal or shell substitution markers. Check your authentication log for sudo attempts by the web server account. Rotate anything that account could read — the database password in your config file, any API tokens, any password vault or wallet file sitting on the same box.
Both published attacker addresses and the shell hash are in our free indicator feed, and the file list above is in the October 15 post in full detail.
The point, restated
The catalog arrived. It arrived forty-two days after the fix, forty-three after the first attack, and it arrived into an audience of schools and nonprofits who were never going to be reading a federal patch deadline anyway.
Sort by "is it being exploited, and do I run it." Not by "is it on the list yet." The list is good, and free, and we use it every day. It is also, structurally, behind — and the gap is not noise, it is six weeks.
We will keep marking these both ways: the times our argument held, and the times our instruments could not answer. Today is one of each.
If this helped you check a server, or if you found something we got wrong, the rating widget below takes ten seconds and is the only way we know.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=we-said-it-was-still-not-in-kev-eight-days-later-cisa-added-it-the-fix-had-been-available-for-fort
Comments