Two CISA advisories, 17 CVEs each scored twice, and the number at the top of both pages is the lower one

Seventeen flaws, thirty four scores, and one number on the cover

CISA published two advisories on 24 September 2026. ICSA-26-267-01 covers Botslab G980H dashcams and carries fourteen CVEs. ICSA-26-267-02 covers the Eufy Omni C20 and Omni X10 Pro robot vacuums and carries three. Every one of the seventeen is scored twice, once under CVSS v3.1 and once under v4.0, and both numbers are printed on the page.

Thirteen of the seventeen score higher under v4.0. Four score lower. None is unchanged. Six cross upward into a more severe qualitative band, and not one crosses downward. The mean moves from 6.98 to 7.48.

The summary table at the top of each advisory, the part a reader sees first and a ticket usually inherits, gives a v3 score in both cases. ICSA-26-267-01 headlines v3 8.8, high, while the page below it contains a 9.2 critical. ICSA-26-267-02 headlines v3 9.4.

What that does not establish. It does not establish that v4.0 is the better scale, only that it is the newer one and that on this sample it reads higher. It does not establish that CISA is hiding anything: both numbers are published, in full, with vectors, on the same page. It does not establish a trend, because seventeen vulnerabilities from two consumer devices is a small and unrepresentative sample. And it does not establish that any of these flaws is being exploited, because neither advisory says so.

What it does establish is that when a vulnerability carries two official scores, somebody chooses which one travels, and on this occasion the choice went to the older scale in both documents.

The six that changed band

A band change matters more than a decimal, because most remediation policies are written in bands. "Criticals in seven days, highs in thirty" is a sentence that appears in thousands of standards, and it does not care whether the score is 8.9 or 9.0 except at the boundary, where it cares completely.

Every CVE whose qualitative band differs between the two versions, read from the advisories

CVE	v3.1	v4.0	What it is
CVE-2026-81630	8.1 high	9.2 critical	Insufficient verification of firmware, dashcam
CVE-2026-93289	7.5 high	9.0 critical	OS command injection during pairing, vacuum
CVE-2026-82708	6.5 medium	7.1 high	Path traversal, dashcam
CVE-2026-82585	6.5 medium	7.1 high	Cleartext transmission of video and location, dashcam
CVE-2026-79959	6.8 medium	7.0 high	Hard coded root password reachable over UART, dashcam
CVE-2026-88956	6.8 medium	7.0 high	Missing authentication for a critical function, dashcam

Run a policy of "critical in seven days, high in thirty, medium in ninety" over those six rows twice, once with each column, and the two runs disagree about every single one of them. Two flaws move from a thirty day clock to a seven day clock. Four move from ninety days to thirty.

The flaws did not change. The scale did.

Why the same flaw scores differently

This is not a rounding difference or an error. CVSS v4.0 measures partly different things, and the changes tend to push scores up for the kind of flaw these two advisories are full of.

The biggest structural change is to impact. Version 3.1 had a single set of confidentiality, integrity and availability metrics plus a Scope flag to indicate that the blast radius left the vulnerable component. Version 4.0 drops Scope and splits impact in two: Vulnerable System confidentiality, integrity and availability, written VC, VI and VA, and Subsequent System confidentiality, integrity and availability, written SC, SI and SA. A flaw that compromises the device and then whatever the device is connected to now says so in six metrics rather than one flag.

Version 4.0 also adds Attack Requirements, written AT, which records deployment conditions an attacker needs beyond their own effort, and it gives User Interaction a third value, Passive, between none and active.

Compare the two vectors for the command injection in the robot vacuums, both printed in the advisory:

v3.1  AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H                      7.5 high
v4.0  AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H     9.0 critical

Both say adjacent network, high attack complexity, no privileges, no user interaction, and high impact on everything. The v3.1 vector then says S:U, scope unchanged, and stops. The v4.0 vector says the subsequent system takes high confidentiality, integrity and availability impact too, and adds that attack requirements are present. The first version had one bit for the idea that the damage does not stop at the device. The second has three metrics, and using them moves this flaw across the critical line.

What the two products actually are

Both advisories are filed under Industrial Control Systems, which is the process CISA uses for operational technology. One covers a robot vacuum. The other covers a dashcam.

The sector labels are worth reading slowly. The Eufy advisory records the critical infrastructure sector as Information Technology. The Botslab advisory records it as Transportation Systems. Both list worldwide deployment and a company headquarters in China. A household robot vacuum is therefore, on the record, an information technology asset, and a consumer dashcam is a transportation systems asset.

That is not a criticism of the labels. It is what happens when consumer devices are catalogued through a scheme designed for plant equipment: the taxonomy still has to put them somewhere, and the label it produces will be read later by people who filter on it.

The two advisories of 24 September 2026 side by side

Field	ICSA-26-267-01	ICSA-26-267-02
Product	Botslab G980H dashcams	Eufy Omni C20 and Omni X10 Pro
CVEs	14	3
Summary score printed	v3 8.8	v3 9.4
Highest v4.0 on the page	9.2	9.3
Sector recorded	Transportation Systems	Information Technology
Fix available	No	Yes, version 1.6.4 or later
Reported by	Julian of Software Secured	Jared of Somerset Recon

Fourteen flaws and no fix

The scoring story is the interesting one. The dashcam story is the serious one.

Against every one of the fourteen dashcam CVEs, the mitigation field says the same thing: "Botslab has not responded to requests to work with CISA to mitigate this vulnerability." Users are invited to contact the vendor through its own about page. There is no patch, no version to upgrade to and no workaround from the manufacturer.

What the fourteen add up to is a device that records continuously in a vehicle and defends itself with almost nothing. CVE-2026-79959 is a hard coded root password in the firmware that a user cannot change, recoverable by anyone who obtains the firmware or gets physical access, usable over the UART interface. CVE-2026-82585 is cleartext transmission: recordings, live video, location information, images and diagnostic logs travel over unencrypted HTTP and RTSP to the mobile application, readable by anyone on the same wireless network. Around those sit replay based authentication bypass, predictable identifiers, session expiry failures, missing authentication on critical functions, a path traversal, an out of bounds write and hard coded cryptographic keys.

The advisory's own summary is that successful exploitation "could allow an attacker to bypass authentication controls, gain unauthorized access to sensitive data and privileged device functionality, modify device configuration, disrupt device operation".

What neither advisory says

Stated in the two advisories against not established by them

Stated	Not established
Both v3.1 and v4.0 scores, with vectors, for all 17 CVEs	Which score the reader is expected to act on
The Eufy flaws are fixed in version 1.6.4	How many devices have taken that update
Botslab has not responded to CISA	Whether Botslab received the contact, or intends to respond
Sector, country of deployment and vendor headquarters	Any installed base, sales or fleet figure
Researcher credit for both advisories	Any disclosure timeline, or how long the vendors had
Recommended network isolation measures	Any claim of exploitation, for any of the seventeen

That last row matters. Neither advisory says anything is being exploited. These are not KEV entries and they carry no federal deadline. The reason to act on them is the mechanism, not a clock.

What to do about it

The question this leaves

Nobody did anything wrong in these two documents. CISA published both scores and both vectors for every flaw, which is more transparency than most vendors manage, and the summary field has carried a v3 number for years because that is what the field was built for.

But a vulnerability that carries two official numbers has, in practice, whichever number survives contact with a spreadsheet. On these two pages the surviving number is the lower one in thirteen cases out of seventeen, and in two of those the difference is the word critical.

The transition from v3.1 to v4.0 is going to run for years, and during it every organisation is quietly choosing a scale, usually by inheriting whatever their tooling defaults to. So: which version does your patching policy mean when it says critical, and would anybody in your team be able to answer that without looking?