Skip to main content

Rejected CVEs in Vulnerability Databases

When a CVE identifier is withdrawn, the authoritative record at 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, 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​

DatabaseWhat the entries showFirst contactedStatus
SentinelOneCVE-2025-156032026-07-23No response on four channels. Published security contact does not accept mail.
CVEdetailsAll 9 withdrawn identifiers2026-07-23No response
VulmonAll 9 withdrawn identifiers2026-07-23No response
VulnersAll 9 withdrawn identifiers2026-07-23Replied on one record, internal task opened
Rapid71 of 9; rejection now shown, severity and score retained2026-07-23No response, entry since corrected in part
Positive TechnologiesAll 9 withdrawn identifiers2026-08-08Awaiting response
TenableRejection shown, but severity and CVSS scores retained2026-08-08Auto-reply redirected to a product-vulnerability form
BaseFortify by AxxembleRejection shown, but AI summary calls it remotely exploitable2026-08-08Awaiting response
INCIBE-CERTAll 9; rejection shown on 8 but scores retained, 1 not rejected at all2026-08-08Awaiting response
Askar LabsAll 9 withdrawn identifiers2026-08-08Awaiting 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, and every externally filed CVE we contest has a reasoned page under 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 [email protected] 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​

This content is for informational purposes only and does not constitute a warranty, guarantee, or contractual commitment. Open WebUI is provided "as is." See your license for applicable terms.