Canada says this flaw is being exploited. CISA's own machine-readable record, three days later, says none

The field in the record that nobody reads

This site covered the Roundcube release in question last week, in the briefing on eight fixes shipped without names. That piece ended on the observation that the flaw was not in the CISA exploited catalogue. This one is about why, and the answer is in a part of the record that almost nobody opens.

Fetch the NVD record for CVE-2026-48842 and look past the description. Underneath the CVSS block sits a second set of metrics, ssvcV203, written by CISA in its coordinator role. Its contents, timestamped 24 September 2026:

• exploitation: none
• automatable: no
• technicalImpact: total

Three days earlier, on 21 September, the Canadian Centre for Cyber Security updated its advisory on the same CVE to say that public information indicates exploitation is occurring.

So two allied national cyber bodies published assessments of the same vulnerability three days apart, and they do not agree on the single question a defender most wants answered.

What that does not establish. It does not establish that either body is wrong. It does not establish that exploitation is or is not happening, because neither record is a sensor reading. It does not establish that CISA had seen the Canadian advisory, and there is no field that would tell you. And it does not establish carelessness at either end: these are two organisations applying different decision frameworks to the same public evidence, which is exactly what they are set up to do.

What it does establish is that the answer a defender gets depends on which country's publication they read, and that the discrepancy is machine readable, dated, and sitting in the record that most vulnerability tooling already ingests.

What that field actually means

SSVC is a published decision model, and exploitation is one of its decision points with a defined, ordered set of values. In the version recorded here it runs from none, through a state meaning a public proof of concept exists, to active, meaning reliable evidence of exploitation in the wild. Recording none is not a claim that the flaw is unexploitable. It is a statement that, at the moment of assessment, the evidence available to the assessor did not meet the bar for either of the higher values.

The other two points in the same record matter for the same reason. automatable: no says the steps cannot be reliably automated across many targets, which is consistent with the CVSS vector's attack complexity of high. technicalImpact: total says that where it does work, the attacker gets everything. That combination, hard to do and devastating when done, is precisely the profile that produces slow, quiet, targeted exploitation rather than mass scanning, and mass scanning is what tends to generate the reliable evidence that moves the first field.

The same CVE as recorded by two national bodies, from the NVD record and the Canadian advisory, both read on 26 September 2026.

Question	CISA, SSVC in the NVD record	Canadian Centre for Cyber Security
Is it being exploited	exploitation: none	Public information indicates exploitation
Dated	24 September 2026	21 September 2026, as an update
Form	Machine-readable decision point	Prose advisory
Consequence for the reader	Not eligible for the KEV catalogue	Patch as a priority
Evidence cited	None published	Open source reporting

The last row is the one that resolves most of the apparent conflict. The Canadian advisory attributes its assessment to public reporting rather than to Canadian telemetry. CISA's decision point cites nothing, because the format has nowhere to cite anything.

So this is very probably not two agencies looking at different evidence. It is two agencies looking at the same evidence, which is a set of vendor and press reports, and drawing different conclusions about whether it clears the bar. One of them has to publish a single word in a structured field, and the other can write a sentence with a hedge in it.

Why this keeps it out of the catalogue

The KEV catalogue has an entry requirement: reliable evidence of exploitation in the wild. The SSVC record is the same judgement expressed in the same vocabulary, made by the same organisation, and it says none. So the absence of this CVE from the catalogue is not an oversight or a backlog. It is the documented output of a decision that has been made and published.

That is worth knowing because the two possible explanations lead to opposite behaviour. If a flaw is missing from KEV because nobody has got to it, waiting is reasonable. If it is missing because the responsible body has assessed it and concluded the bar is not met, then waiting means deferring to a judgement that an allied agency has publicly contradicted, and you should decide which one your organisation follows rather than letting the gap decide for you.

As of this morning the catalogue is at version 2026.09.25, count 1,726, and Roundcube already has entries in it. This CVE is not among them.

The record both agencies are reasoning over is thin

It is worth looking at what the two bodies actually had in front of them, because it is less than most people assume.

The NVD entry is marked Deferred, meaning NVD is not enriching it. The only CVSS score on the record, 8.1 high, carries the source cve@mitre.org and the type Secondary. There is no primary score, because Roundcube did not assign one: its 24 May announcement listed eight fixes in one line each, with no identifier, no severity and no score attached to any of them. The CVE was created the following day by MITRE, not by the project.

The vector is worth reading rather than the number: AV:N/AC:L is what most people picture when they hear 8.1, and this is AV:N/**AC:H**/PR:N/UI:N/S:U/C:H/I:H/A:H. Attack complexity high is doing the work that keeps it under nine, and it is the same property the SSVC record expresses as automatable: no.

And the exposure is conditional in a way no score can carry. The flaw is in the virtuser_query plugin, which is configured rather than universal, so whether a given deployment is affected is a question about that deployment's configuration file rather than about its version alone.

What to do about it

The question this leaves

Neither agency has done anything wrong here, and the piece would be cheap if it pretended otherwise. One wrote a hedged sentence attributing its view to open sources. The other set a structured field to the value its framework required. Both are defensible, both are dated, and both are public.

The problem belongs to the layer above them. A defender's tooling takes one of these as authoritative, almost always the American one, almost always through the CVSS number and the KEV membership test, and almost never through the field that explains the KEV decision. The disagreement is not hidden. It is simply in a part of the record that the tooling throws away.

So the question for your own vulnerability process: when the exploitation status of a flaw is contested between two national authorities, does anything in your pipeline notice, and if not, whose judgement have you quietly adopted as your own?