Seventeen flaws, two official scores each. Six cross a severity band, and every one of them crosses upward
CISA published two consumer device advisories on 24 September carrying seventeen CVEs, each scored under both CVSS v3.1 and v4.0. Which number reaches a ticket depends on which calculator the tooling happens to speak.
By Parminder Kumar Sharma · · 7 min read
Six of seventeen change band, and none of them go down
On 24 September 2026 CISA published two industrial control system advisories, both for consumer devices. 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. Seventeen identifiers in one day.
Every one of them is scored twice, under CVSS v3.1 and under CVSS v4.0, both printed in the advisory, both official, both from the same assigner.
Recomputing the bands from the advisories:
- Six of the seventeen move up a severity band between the two versions
- None move down
- Thirteen of the seventeen scores rise numerically, four fall
- The mean change is plus 0.49, the largest single rise is 1.5 and the largest fall is 1.1
The severity band is the thing that reaches a human. It is what fills the word in a ticket title, what a policy threshold is written against, and what a monthly report counts. And for six of these flaws it has two correct answers.
What that does not establish. It does not establish that either version is wrong. v4.0 was designed to fix known weaknesses in v3.1, in particular its poor handling of attack requirements and of impact on systems beyond the vulnerable one, and a general upward drift on this kind of device is a plausible consequence of doing that properly. It does not establish that seventeen is a representative sample, because it is one day and two products. It does not establish that anybody mis-triaged anything.
What it establishes is that the number reaching a ticket is chosen, not measured, and that the choice is usually made by whichever calculator a tool happens to implement rather than by anybody who has thought about it.
The six, and the one that matters most
The six CVEs that change severity band between CVSS v3.1 and v4.0, recomputed from the scores printed in ICSA-26-267-01 and ICSA-26-267-02 on 24 September 2026.
| CVE and weakness | v3.1 | v4.0 |
|---|---|---|
| CVE-2026-81630, insufficient verification of data authenticity | 8.1 High | 9.2 Critical |
| CVE-2026-93289, OS command injection | 7.5 High | 9.0 Critical |
| CVE-2026-82708, path traversal | 6.5 Medium | 7.1 High |
| CVE-2026-82585, cleartext transmission | 6.5 Medium | 7.1 High |
| CVE-2026-88956, missing authentication | 6.8 Medium | 7.0 High |
| CVE-2026-79959, hard-coded credentials | 6.8 Medium | 7.0 High |
Take the top row on its own. CVE-2026-81630 is a firmware verification weakness in the dashcam. Under v3.1 it is 8.1, which in most organisations means high, patch in the normal cycle. Under v4.0 it is 9.2, which means critical, and in a good many policies critical means an out of cycle change with an approval attached.
Two further facts from the same advisory make that gap matter more than it would elsewhere. There is no fix. And CISA records that "Botslab has not responded to requests to work with CISA to mitigate this vulnerability".
So the flaw that gains the most from the change of scoring version is the one on the device that cannot be patched, from the vendor that is not answering. Whether that reaches anybody as an emergency depends on a version choice in a scoring library.
The second row is the same shape in the other direction of comfort: the Eufy command injection moves from 7.5 to 9.0, but that one does have a fix, in 1.6.4, and the vendor cooperated.
Why v4.0 moves these particular flaws
The rises are not arbitrary, and it is worth understanding the mechanism rather than treating it as noise.
Two changes in v4.0 do most of the work here. The first is attack requirements, a new metric separated out from attack complexity, which lets a scorer say that an attack needs particular conditions without collapsing that into the same dimension as difficulty. Several of these vectors carry AT:P in v4.0, and some of them were carrying AC:H in v3.1 for what is really a condition rather than a complexity.
The second is the subsequent system impact metrics, which let a score say that a compromise reaches beyond the vulnerable component. The Eufy command injection is the clearest case in the set: its v4.0 vector carries high confidentiality, integrity and availability impact on the subsequent system, and v3.1 had no comparable expression at all other than a scope change.
There is a third effect that is easy to miss and worth naming. Four of the seventeen scores went down, and three of those are the dashcam's adjacent network flaws that sat at 8.8 under v3.1 and land at 8.7 or 7.7 under v4.0. So v4.0 is not simply louder. It redistributes, and on this sample it redistributes upward across bands while nudging a few of the loudest numbers down.
The other thing these advisories are called
Both of these are industrial control system advisories, which is how they will be filed, alerted on and counted.
The robot vacuum is recorded under the critical infrastructure sector Information Technology. The dashcam is recorded under Transportation Systems.
Neither label is a mistake in any procedural sense. The advisory process has a fixed list of sectors, every advisory must carry one, and somebody has to pick the closest. But a security team with a rule that routes Transportation Systems advisories to the people who look after operational technology is about to send a consumer dashcam to the team that runs signalling or fleet telematics, and a team counting ICS advisories as a measure of threat to industrial equipment has just counted a vacuum cleaner.
This is the same failure as the scoring version, one layer up. A controlled field with a fixed vocabulary is being used to carry a judgement it cannot express, and downstream processes read it as though it can.
What to do about it
Take this with you
In the order worth doing
- Find out which CVSS version your vulnerability tooling reports, and whether it is the same version your policy thresholds were written against. If the answer differs by tool, your critical threshold means different things in different consoles.
- Where both scores are published, record both. The advisories print them side by side and most pipelines keep one, which discards the only evidence that a judgement was made.
- For the six flaws above, check which band your own tooling shows and whether that matches the action you would want. That is a five minute test of the whole problem on a real example.
- If you have Botslab G980H dashcams anywhere, including in vehicles that are not on the corporate asset register, treat them as unpatchable and decide whether they stay on any network you care about. There is no fix and the vendor is not responding.
- If you have Eufy Omni C20 or X10 Pro devices, update to 1.6.4 or later, which does fix all three.
- Stop using the ICS advisory sector field as a routing key on its own. Read what the product is before deciding who owns it.
The question this leaves
There is no error anywhere in this story. CISA published both scores, which is more transparent than publishing one. The scores are correctly computed under their respective specifications. The sector labels are drawn from a list that has to be used. The researchers did good work, and one of the two vendors fixed the problem promptly.
And yet the same flaw is high or critical depending on a library version, and a dashcam is filed as transport infrastructure, and both of those facts will be invisible to everyone downstream, because what travels is a single word in a ticket.
So the question for your own process: when a severity level determines what happens next, who chose the scale it came from, and could you say today whether every tool in your estate is using the same one?
Sources
- PrimaryAdvisory ICSA-26-267-01 on Botslab G980H dashcams, read in full for all fourteen CVEs, both score sets, the sector and the vendor responseCISAaccessed 2026-09-26
- PrimaryAdvisory ICSA-26-267-02 on Eufy Omni C20 and Omni X10 Pro, read in full for all three CVEs, both score sets and the fixed versionCISAaccessed 2026-09-26
- PrimaryThe CVSS v4.0 specification, used for the severity band boundaries and for what the attack requirements and subsequent system metrics changedFIRSTaccessed 2026-09-26
