# Rejected CVEs in Vulnerability Databases

Source: https://docs.openwebui.com/security/supply-chain-security/vulnerability-databases

When a CVE identifier is withdrawn, the authoritative record at [cve.org](https://www.cve.org) moves to the **REJECTED** state and NVD mirrors it. Downstream vulnerability databases, scanners and endpoint-security products ingest that data, and on several of them a withdrawal never reaches the published entry. The entry keeps describing a finding that the CVE Program no longer recognises, to the security teams and organisations who rely on that data.

This section is the public record of some of those cases, the ones we have chased far enough to document. There is one page per database, each listing the withdrawn identifiers it carries, what its entry shows for each and a dated log of every contact attempt and its outcome. It is not an exhaustive survey of every database carrying a stale record against Open WebUI.

> **The short version**
>
> A withdrawn CVE presented as a finding is a defect in the database showing it, not a live issue in Open WebUI. The state at cve.org is the authority, it is public and it takes seconds to check.

## Check any CVE against Open WebUI yourself

1. **Open the record at cve.org** (`https://www.cve.org/CVERecord?id=CVE-YYYY-NNNNN`) and read the state. `REJECTED` means the issuing CNA withdrew the identifier. No downstream presentation overrides that.
2. **Cross-check NVD** (`https://nvd.nist.gov/vuln/detail/CVE-YYYY-NNNNN`), which carries the same state.
3. **Read our assessment** in [Vendor Dispositions](/security/vendor-dispositions), where every externally filed CVE against Open WebUI has a page setting out what the record claims and where it is wrong.

## Databases we have contacted

| Database | What the entries show | First contacted | Status |
| --- | --- | --- | --- |
| SentinelOne | CVE-2025-15603 | 2026-07-23 | No response on four channels. Published security contact does not accept mail. |
| CVEdetails | All 9 withdrawn identifiers | 2026-07-23 | No response |
| Vulmon | All 9 withdrawn identifiers | 2026-07-23 | No response |
| Vulners | All 9 withdrawn identifiers | 2026-07-23 | Replied on one record, internal task opened |
| Rapid7 | 1 of 9; rejection now shown, severity and score retained | 2026-07-23 | No response, entry since corrected in part |
| Positive Technologies | All 9 withdrawn identifiers | 2026-08-08 | Awaiting response |
| Tenable | Rejection shown, but severity and CVSS scores retained | 2026-08-08 | Auto-reply redirected to a product-vulnerability form |
| BaseFortify by Axxemble | Rejection shown, but AI summary calls it remotely exploitable | 2026-08-08 | Awaiting response |
| INCIBE-CERT | All 9; rejection shown on 8 but scores retained, 1 not rejected at all | 2026-08-08 | Awaiting response |
| Askar Labs | All 9 withdrawn identifiers | 2026-08-08 | Awaiting response |

## What this means for your evaluation

If Open WebUI appears in a scan report or a vendor vulnerability database, the presence of an identifier is not by itself evidence that the record is live, correctly classified or correctly scored. Check the state at cve.org first.

Where a record is genuinely live, we say so. Our published advisories, with affected and fixed versions for each, are at [Open WebUI Security Advisories](https://github.com/open-webui/open-webui/security/advisories), and every externally filed CVE we contest has a reasoned page under [Vendor Dispositions](/security/vendor-dispositions). We do not ask anyone to take our word for any of it.

## What we ask of database operators

1. **Reprocess reject and withdrawal transitions** from the CVE and NVD feeds. A one-time snapshot at ingestion means every record later withdrawn stays wrong permanently.
2. **Remove what the withdrawal invalidates.** A rejected identifier has no severity, no base score, no vector, no affected version range and no exploitation-probability estimate, because there is no finding left to describe. Ingesting the rejection into a description field while leaving those in place publishes a contradiction.
3. **Expose the rejected state as a structured field**, not only as prose. A consumer that wants to filter withdrawn records out needs something it can filter on.
4. **Label derived figures as your own.** Where a score, summary or risk estimate is generated by the database rather than taken from the record, say so, so a reader can tell whose assessment they are reading.
5. **Keep the address published in your `security.txt` able to receive mail.** A contact that bounces is worse than no contact, because it consumes the reporter's time before failing.

If you operate a database listed here and have corrected an entry, write to `security@openwebui.com` and we will update the page to reflect it. Once every inaccurate record we have raised with you is corrected, we will take the page down entirely. We are glad to do that, and we would much rather have no pages here at all. Until then the page stays up, because it describes something that is still true.

## See also

- [Supply Chain and Security Scanners](/security/supply-chain-security): our position on automated capability flags and scanner risk scores.
- [Vendor Dispositions](/security/vendor-dispositions): per-CVE assessments, including disputes still open with issuing CNAs.
- [Security Policy](/security/security-policy): the reporting process and threat model.