INCIBE-CERT
| Product | INCIBE-CERT early-warning vulnerability listing (Spain's national CERT) |
| Problem | Withdrawn records keep their CVSS scores and severity ratings, one is presented at 9.00 CRITICAL, and one carries no rejection notice at all |
| First contacted | 2026-08-08 |
| Channels tried | empresas@ |
| Status | Awaiting response |
This page is not a general complaint about INCIBE-CERT's data quality. It concerns one specific and consequential gap.
A withdrawn record, presented as CRITICAL by a national CERT
Start with the single entry that shows what the gap costs. Four parties have assessed CVE-2024-7053, and this is where each of them landed:
| Source | Assessment |
|---|---|
| The CVE record on cve.org | REJECTED since 2026-08-13 |
| The issuing CNA, at assignment | 7.6 High |
| Open WebUI | The described chain cannot occur, for four independent reasons |
| INCIBE-CERT, today | 9.00 CRITICAL |
The highest score of the four is the one published by the national CERT. It exceeds what the issuing CNA itself claimed, on an identifier that same CNA has since withdrawn, describing an attack chain that could never have run.
The order matters. The CNA assigned it at 7.6. INCIBE-CERT raised it to 9.00. The CNA then withdrew the record entirely. The rating that survives on the early-warning listing is the one nobody stands behind: not the CNA, which retracted it, and not us.
A 9.00 CRITICAL is not a filing detail. It is the number that decides whether a security team drops what it is doing, whether a procurement review blocks, and whether a scanner escalates a build. Organisations read a national CERT's early-warning listing as guidance on what to act on, which is precisely the weight this entry carries and precisely what makes it costly. Our full assessment is on the disposition page.
The rejection reaches the description and stops there
INCIBE-CERT does ingest reject transitions into the description field. On a withdrawn record the description is replaced with the CNA's notice, and nothing else on the page changes. Every one of these still displays a CVSS vector, a base score and a severity label:
| Identifier | Description field | Severity still shown |
|---|---|---|
| CVE-2024-7033 | Rejection notice | 7.20 HIGH |
| CVE-2024-7034 | Rejection notice | 7.20 HIGH |
| CVE-2024-7038 | Rejection notice | 2.70 LOW |
| CVE-2024-7039 | Rejection notice | 6.70 MEDIUM |
| CVE-2024-7040 | Rejection notice | 4.90 MEDIUM |
| CVE-2024-7959 | Rejection notice | 7.70 HIGH |
| CVE-2025-29446 | Rejection notice | 3.30 LOW |
| CVE-2025-63391 | Rejection notice | 7.50 HIGH |
A rejected record cannot have a severity
A CVSS score is a statement that a vulnerability exists and that this is how bad it is. When the issuing CNA withdraws an identifier it is stating that there is no vulnerability. A page that carries both is asserting two contradictory things, and it resolves the contradiction differently depending on who is reading:
- A person who opens the page and reads the description learns the record is dead.
- Anything consuming the data programmatically may take the severity and the vector and never see the description at all. Scores are the fields built for machines: they are structured, comparable and sortable, which is exactly why tooling reads them and prose summaries get skipped.
There is also no uniform, machine-readable rejected state anywhere on the entry. The withdrawal exists only as English text inside a free-form description field, and the surrounding fields still describe a live finding. A consumer that wants to filter withdrawn records out has nothing dependable to filter on.
Half of the records above are still labelled HIGH, the highest at 7.70.
Some of those figures differ from what the issuing CNA assigned, in both directions. CVE-2024-7033 and CVE-2024-7034 are shown at 7.20 High against a CNA score of 6.5 Medium, and CVE-2024-7039 is shown at 6.70 Medium against a CNA score of 8.3 High. These are NVD's assessments rather than INCIBE-CERT's own, and NVD publishes them alongside the CNA's rather than in place of it. The direction of any individual figure matters less than the fact underneath all of them: a withdrawn identifier is still being presented with a severity at all.
One record carries no rejection at all
CVE-2025-15603 was withdrawn by VulDB on 2026-06-18. The INCIBE-CERT entry was last modified on 2026-04-29 and has not been touched since, so it still carries the original text in full:
A security vulnerability has been detected in open-webui up to 0.6.16. [...] It is possible to launch the attack remotely. The attack requires a high level of complexity. The exploitability is told to be difficult. The exploit has been disclosed publicly and may be used.
Three CVSS scores accompany it, across versions 2.0, 3.1 and 4.0. There is no indication anywhere on the page that the identifier no longer exists.
The other eight entries carry INCIBE-CERT's own Last modified dates of 2026-07-16 and 2026-06-29, matching their withdrawals. Whatever ran on those dates did not reach this one, and nothing has flagged the omission in the seven weeks since.
Contact log
| Date | Channel | Outcome |
|---|---|---|
| 2026-08-08 | empresas@ | Awaiting response |
What would fix this
Removing the fields a withdrawn record cannot have. A rejected identifier has no severity, no base score and no vector, because there is no finding left to rate. Those fields should come off the entry when the withdrawal is ingested, rather than being left standing beside it. Exposing the rejected state as a structured field, instead of only as English inside a description, would then let anything reading the data act on it.
The transition is already ingested. What remains is deleting what it invalidates.
See also
- Rejected CVEs in Vulnerability Databases, the overview and how to verify any record yourself.
- Vendor Dispositions, our assessment of each identifier listed above.