Skip to content

Commit c50db55

Browse files
Classic298Classic298
committed
Answer the CVE system's failures in public and name the databases still serving rejected records
Invalid CVE records against Open WebUI keep circulating, and the pages meant to answer them said too little about why. Some records name the wrong product entirely, some rest on a mechanism the quoted code rules out, and some were published without the report ever reaching us, which would have made a live zero day had the finding been real. Minting a record takes days and removing one takes months, and several vulnerability databases never process the withdrawal at all, so an identifier the issuing CNA has formally rejected keeps displaying to their customers as a live finding. The Vendor Dispositions index now states the project's position on the CVE system directly: we use it, we request identifiers for genuine findings, and these are the specific ways records filed against us have failed. It also says plainly that we will not ship a token fix to make an invalid record disappear, because rejection is the only route that improves the data everyone downstream depends on. The security policy's foreign-CNA rule links to that reasoning rather than asserting itself. Supply Chain and Security Scanners becomes a folder, keeping its URL, and gains one page per vulnerability database: what that database still shows, how it compares to the CNA's own classification, and a dated log of every contact attempt. Twelve disposition timelines gain their follow-ups and the escalations back to the CVE Program Root, and the pages carry styled blocks marking the refutation, the withdrawal and the events that remain open.
1 parent 47ff261 commit c50db55

26 files changed

Lines changed: 473 additions & 16 deletions

‎docs/security/security-policy.mdx‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -89,6 +89,8 @@ We respond to such records by:
8989

9090
**Channel compliance does not entitle a CNA to override vendor disposition.** Reporters who escalate a closed-as-out-of-scope/not-a-vulnerability GHSA report to a third-party CNA after vendor disposition has been issued are likewise considered to have acted against vendor disposition, and **may be barred from future GHSA submissions.**
9191

92+
This rule exists because the cost of these escalations is not symmetric. An identifier can be minted in days, and removing an inaccurate one takes months of correspondence across the issuing CNA, the CVE Program and every downstream database that mirrored it, with none of that effort falling on the party that created the record. For the full reasoning, and the record of what these escalations have actually cost, see [The CVE System and Why This Page Exists](./vendor-dispositions#the-cve-system-and-why-this-page-exists).
93+
9294
## Reporting Guidelines
9395

9496
**[You can find the authoritative version of these guidelines here.](https://github.com/open-webui/open-webui/security)**

‎docs/security/supply-chain-security/vulnerability-databases/axxemble.mdx‎

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
---
2+
sidebar_position: 7
3+
title: "Axxemble"
4+
---
5+
6+
# Axxemble
7+
8+
| | |
9+
| :--- | :--- |
10+
| **Product** | Axxemble vulnerability database |
11+
| **Records still shown as active** | 1 |
12+
| **First contacted** | 2026-08-08 |
13+
| **Channels tried** | `support@axxemble.nl` |
14+
| **Status** | Awaiting response |
15+
16+
---
17+
18+
## Records
19+
20+
### CVE-2025-15603
21+
22+
| | |
23+
| :--- | :--- |
24+
| **Authoritative state** | **REJECTED** at [cve.org](https://www.cve.org/CVERecord?id=CVE-2025-15603) and [NVD](https://nvd.nist.gov/vuln/detail/CVE-2025-15603) since 2026-06-18 |
25+
| **Withdrawn by** | VulDB, the issuing CNA, as a false positive |
26+
| **What Axxemble displays** | An active vulnerability in open-webui, weak `WEBUI_SECRET_KEY` randomness, with no rejection marker, accompanied by an "AI Analysis" stating the issue is remotely exploitable |
27+
| **Our assessment** | [CVE-2025-15603](/security/vendor-dispositions/cve-2025-15603) |
28+
29+
The generated analysis is wrong on the substance, independently of the withdrawal. The behaviour the report described was never remotely exploitable. It concerned a default value in a Windows batch file, and the issuing CNA withdrew the identifier on exactly that basis. Its published rejection reads:
30+
31+
> \*\* REJECT \*\* DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: The vendor explains: "The 't0p-s3cr3t' default was dead code on every supported startup path: start.sh, start_windows.bat and `open-webui serve` all set or auto-generate WEBUI_SECRET_KEY before the backend imports env.py. It was only ever reachable by invoking uvicorn directly, which is unsupported and unsafe (the app would then sign tokens/cookies with a public, hardcoded key)."
32+
33+
Dead code on every supported startup path, reachable only by someone already running the process by hand on the machine, is not a remotely exploitable condition. The generated paragraph asserts something the report never claimed and the CNA expressly rejected.
34+
35+
A machine-generated paragraph asserting remote exploitability, attached to a withdrawn record, states something stronger than the original report ever claimed and stronger than the CNA ever accepted.
36+
37+
---
38+
39+
## Contact log
40+
41+
| Date | Channel | Outcome |
42+
| :--- | :--- | :--- |
43+
| 2026-08-08 | `support@axxemble.nl` | Awaiting response |
44+
45+
---
46+
47+
## See also
48+
49+
- [Rejected CVEs in Vulnerability Databases](./) — the overview and how to verify any record yourself.
50+
- [CVE-2025-15603 vendor disposition](/security/vendor-dispositions/cve-2025-15603)

‎docs/security/supply-chain-security/vulnerability-databases/incibe.mdx‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
---
2+
sidebar_position: 8
3+
title: "INCIBE-CERT"
4+
---
5+
6+
# INCIBE-CERT
7+
8+
| | |
9+
| :--- | :--- |
10+
| **Product** | INCIBE-CERT early-warning vulnerability listing |
11+
| **Records still shown as active** | 1 |
12+
| **First contacted** | 2026-08-08 |
13+
| **Channels tried** | `empresas@` |
14+
| **Status** | Awaiting response |
15+
16+
---
17+
18+
## Records
19+
20+
### CVE-2025-15603
21+
22+
| | |
23+
| :--- | :--- |
24+
| **Authoritative state** | **REJECTED** at [cve.org](https://www.cve.org/CVERecord?id=CVE-2025-15603) and [NVD](https://nvd.nist.gov/vuln/detail/CVE-2025-15603) since 2026-06-18 |
25+
| **Withdrawn by** | VulDB, the issuing CNA, as a false positive |
26+
| **Their entry** | [incibe.es early-warning listing for CVE-2025-15603](https://www.incibe.es/index.php/incibe-cert/alerta-temprana/vulnerabilidades/cve-2025-15603) |
27+
| **What it displays** | An active vulnerability in open-webui, weak `WEBUI_SECRET_KEY` randomness, with no rejection marker |
28+
| **Our assessment** | [CVE-2025-15603](/security/vendor-dispositions/cve-2025-15603) |
29+
30+
This one carries additional weight because INCIBE-CERT is a national CERT. Its early-warning listings are read by organisations as authoritative guidance about what to act on, so a withdrawn identifier presented without a rejection marker propagates further than it would from a commercial aggregator.
31+
32+
---
33+
34+
## Contact log
35+
36+
| Date | Channel | Outcome |
37+
| :--- | :--- | :--- |
38+
| 2026-08-08 | `empresas@` | Awaiting response |
39+
40+
---
41+
42+
## See also
43+
44+
- [Rejected CVEs in Vulnerability Databases](./) — the overview and how to verify any record yourself.
45+
- [CVE-2025-15603 vendor disposition](/security/vendor-dispositions/cve-2025-15603)

‎docs/security/supply-chain-security/vulnerability-databases/index.mdx‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,10 @@ A withdrawn CVE appearing in a commercial vulnerability database is a data-fresh
2727
| [CVEdetails](./cvedetails) | CVE-2025-15603 | 2026-07-23 | No response |
2828
| [Vulmon](./vulmon) | CVE-2025-15603 | 2026-07-23 | No response |
2929
| [Vulners](./vulners) | CVE-2025-15603 | 2026-07-23 | Acknowledged, fix in progress |
30+
| [Positive Technologies](./positive-technologies) | CVE-2025-15603 | 2026-08-08 | Awaiting response |
31+
| [Tenable](./tenable) | CVE-2025-15603 | 2026-08-08 | Auto-reply redirected to a product-vulnerability form |
32+
| [Axxemble](./axxemble) | CVE-2025-15603 | 2026-08-08 | Awaiting response |
33+
| [INCIBE-CERT](./incibe) | CVE-2025-15603 | 2026-08-08 | Awaiting response |
3034

3135
## What this means for your evaluation
3236

‎docs/security/supply-chain-security/vulnerability-databases/positive-technologies.mdx‎

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
---
2+
sidebar_position: 5
3+
title: "Positive Technologies (dbugs)"
4+
---
5+
6+
# Positive Technologies (dbugs)
7+
8+
| | |
9+
| :--- | :--- |
10+
| **Product** | Positive Technologies vulnerability database (dbugs) |
11+
| **Records still shown as active** | 1 |
12+
| **First contacted** | 2026-08-08 |
13+
| **Channels tried** | `dbugs@` |
14+
| **Status** | Awaiting response |
15+
16+
---
17+
18+
## Records
19+
20+
### CVE-2025-15603
21+
22+
| | |
23+
| :--- | :--- |
24+
| **Authoritative state** | **REJECTED** at [cve.org](https://www.cve.org/CVERecord?id=CVE-2025-15603) and [NVD](https://nvd.nist.gov/vuln/detail/CVE-2025-15603) since 2026-06-18 |
25+
| **Withdrawn by** | VulDB, the issuing CNA, as a false positive |
26+
| **Their entry** | [PT-2026-24109](https://dbugs.ptsecurity.com/vulnerability/PT-2026-24109), published and last updated 2026-03-09 |
27+
| **What it displays** | An active vulnerability in open-webui, weak `WEBUI_SECRET_KEY` randomness, CVSS 3.7 Low, annotated "The exploit has been publicly disclosed", with the recommendation to "update to a version of open-webui greater than 0.6.16" |
28+
| **Our assessment** | [CVE-2025-15603](/security/vendor-dispositions/cve-2025-15603) |
29+
30+
The score matches the CNA, so this is a status problem rather than a scoring one: the entry was last updated more than three months before the withdrawal and has not re-synced.
31+
32+
What makes it worse than a stale row is the recommendation. The entry instructs the reader to upgrade in order to remediate an identifier that no longer exists, which turns a data-freshness defect into a maintenance action taken on false grounds.
33+
34+
---
35+
36+
## Contact log
37+
38+
| Date | Channel | Outcome |
39+
| :--- | :--- | :--- |
40+
| 2026-08-08 | `dbugs@` | Awaiting response |
41+
42+
---
43+
44+
## See also
45+
46+
- [Rejected CVEs in Vulnerability Databases](./) — the overview and how to verify any record yourself.
47+
- [CVE-2025-15603 vendor disposition](/security/vendor-dispositions/cve-2025-15603)

‎docs/security/supply-chain-security/vulnerability-databases/sentinelone.mdx‎

Lines changed: 10 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,12 @@ title: "SentinelOne"
1313
| **Channels tried** | Four: `security@sentinelone.com` (published in their `security.txt`), `info@sentinelone.com`, the contact form on their website, and a direct message on X |
1414
| **Status** | No response on any channel. The published security contact does not accept mail. |
1515

16+
:::warning There is no working way to reach SentinelOne about this
17+
The only security contact SentinelOne publishes is the address in its `security.txt`, and that address rejects mail outright. Every other route we could find leads to sales. Across four channels and more than two weeks we have not reached anyone able to act on the record.
18+
19+
We do not think this is how security enquiries should be handled by anyone, least of all by a security vendor. The published file and the bounce it returns are [set out below](#the-published-security-contact-rejects-all-mail).
20+
:::
21+
1622
---
1723

1824
## Records
@@ -39,12 +45,13 @@ A record presented to enterprise customers as remote code execution, when the is
3945
| :--- | :--- | :--- |
4046
| 2026-07-23 | `security@sentinelone.com`, the address published in their `security.txt` | Delivery failed. The receiving system rejected the message. |
4147
| 2026-07-23 | `info@sentinelone.com`, with an explicit note that this was not a sales enquiry and a request to route it to whoever maintains the public Vulnerability Database | Automated sales reply: "Thank you for your interest in SentinelOne", offering a discovery call and a product demo. |
48+
| 2026-07-23 | Contact form on the SentinelOne website | No response |
49+
| 2026-07-23 | Direct message on X | No response |
4250
| 2026-08-03 | Follow-up on both addresses | No response |
4351
| 2026-08-08 | Follow-up on both addresses | Delivery to the `security.txt` address failed again. No response on either. |
44-
| 2026-07-23 to 2026-08-08 | Contact form on the SentinelOne website | No response |
45-
| 2026-07-23 to 2026-08-08 | Direct message on X | No response |
52+
| 2026-08-08 | Contact form on the SentinelOne website, submitted a second time | No response |
4653

47-
Four separate channels, one of which is the address they publish for exactly this purpose. As of 2026-08-08 we have had no substantive response on any of them, and the entry is unchanged.
54+
That is four separate channels, one of them the address they publish for exactly this purpose. As of 2026-08-08 we have had no substantive response on any of them, and the entry is unchanged.
4855

4956
## The published security contact rejects all mail
5057

‎docs/security/supply-chain-security/vulnerability-databases/tenable.mdx‎

Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
---
2+
sidebar_position: 6
3+
title: "Tenable"
4+
---
5+
6+
# Tenable
7+
8+
| | |
9+
| :--- | :--- |
10+
| **Product** | Tenable vulnerability database |
11+
| **Records still shown as active** | 1 |
12+
| **First contacted** | 2026-08-08 |
13+
| **Channels tried** | `vulnreport@tenable.com` (published in their `security.txt`) |
14+
| **Status** | Auto-reply redirected us to a product-vulnerability submission form. Awaiting a substantive response. |
15+
16+
---
17+
18+
## Records
19+
20+
### CVE-2025-15603
21+
22+
| | |
23+
| :--- | :--- |
24+
| **Authoritative state** | **REJECTED** at [cve.org](https://www.cve.org/CVERecord?id=CVE-2025-15603) and [NVD](https://nvd.nist.gov/vuln/detail/CVE-2025-15603) since 2026-06-18 |
25+
| **Withdrawn by** | VulDB, the issuing CNA, as a false positive |
26+
| **CNA rating before withdrawal** | Low (CVSS 2.6, 3.7 and 2.9) |
27+
| **What Tenable displays** | An active vulnerability in open-webui, weak `WEBUI_SECRET_KEY` randomness, carrying **Medium** severity |
28+
| **Our assessment** | [CVE-2025-15603](/security/vendor-dispositions/cve-2025-15603) |
29+
30+
Two problems, as with several entries in this section. The record is withdrawn and still presented as live, and the severity shown is Medium, above the Low the issuing CNA assigned before withdrawing it. A rejected identifier cannot carry a severity at all, because there is no longer a finding to rate.
31+
32+
---
33+
34+
## Contact log
35+
36+
| Date | Channel | Outcome |
37+
| :--- | :--- | :--- |
38+
| 2026-08-08 | `vulnreport@tenable.com`, the address published in their `security.txt` | Automated reply directing us to Tenable's product-vulnerability reporting guidelines and asking us to submit through the form on that page. |
39+
| 2026-08-08 | Reply on the same thread | We explained that this is not a report of a vulnerability in a Tenable product, but a request to correct outdated information in their database, and that we had written to the address Tenable itself publishes as its security contact. Awaiting a response. |
40+
41+
## A correction request is not a vulnerability submission
42+
43+
Tenable's [`/.well-known/security.txt`](https://www.tenable.com/.well-known/security.txt) publishes two contact methods, a HackerOne program and `mailto:vulnreport@tenable.com`. We used the second, which is the appropriate one: there is no vulnerability to disclose here, only a record in their database that no longer matches the authoritative state at cve.org.
44+
45+
The automated response routes every message arriving at that address into the intake path for reports of vulnerabilities *in Tenable products*. That path has no step for "your published data is wrong", so a correction request either gets refiled as something it is not, or goes nowhere.
46+
47+
For a vulnerability-management vendor this gap is a pointed one. Tenable's product exists to tell customers which CVEs to act on, and the only contact route it publishes for being told that one of those records is wrong leads to a form about defects in Tenable's own software. The accuracy of the data is the product.
48+
49+
---
50+
51+
## See also
52+
53+
- [Rejected CVEs in Vulnerability Databases](./) — the overview and how to verify any record yourself.
54+
- [CVE-2025-15603 vendor disposition](/security/vendor-dispositions/cve-2025-15603)

‎docs/security/vendor-dispositions/cve-2024-12534.mdx‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,18 @@ title: "CVE-2024-12534"
1313
| **Issuing CNA** | huntr / Protect AI (from a [bounty report](https://huntr.com/bounties/c7c0a4e6-acd3-49b4-8684-2c2c27014b76)) |
1414
| **Claimed Severity** | High (CVSS 7.5, CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) |
1515

16+
<div className="cve-refutation">
17+
18+
:::danger The mechanism the report depends on does not exist
19+
The claim is that an oversized password exhausts the server through hashing. bcrypt hashes only the first 72 bytes of its input by design and discards the rest, so a 72-byte password and a 72-megabyte password cost exactly the same to verify. No work anywhere in the sign-in path scales with the size of the password, and that scaling is the report's entire premise.
20+
21+
The behaviour described is also not Open WebUI's to have. The 72-byte bound is a property of bcrypt, so if it were a defect it would be a defect in bcrypt rather than in this project. The record is published against Open WebUI as a High-severity denial of service, scored 7.5, for an effect its own stated mechanism cannot produce.
22+
23+
This is not a subtle finding that reasonable reviewers could differ on. The behaviour that refutes it is documented behaviour of the hashing library the report itself names, and it refutes it in a single line. A record was nonetheless minted, scored 7.5 High, and published against this project, where it has stood for over a year.
24+
:::
25+
26+
</div>
27+
1628
---
1729

1830
## Timeline

‎docs/security/vendor-dispositions/cve-2024-7033.mdx‎

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,10 +16,14 @@ title: "CVE-2024-7033"
1616

1717
---
1818

19+
<div className="cve-resolved">
20+
1921
:::tip Resolved: this CVE is now rejected
2022
The issuing CNA has withdrawn the record, so the official CVE entry now carries the `REJECTED` state and NVD and downstream feeds inherit it. The public record now matches Open WebUI's vendor disposition below, confirming our assessment that this was not a genuine vulnerability. There is no advisory and no affected Open WebUI release.
2123
:::
2224

25+
</div>
26+
2327
## Timeline
2428

2529
This CVE was **withdrawn by its issuing CNA** after review. Open WebUI's assessment below is the basis on which the record was rejected.
@@ -29,7 +33,9 @@ This CVE was **withdrawn by its issuing CNA** after review. Open WebUI's assessm
2933
| 2025-03-20 | huntr / Protect AI publishes the CVE. |
3034
| 2026-07-08 | Open WebUI publishes this disposition, rejecting the report as out of scope. |
3135
| 2026-07-08 | Open WebUI contacts huntr / Protect AI directly to dispute the record. |
32-
| 2026-07-16 | huntr / Protect AI accepts the dispute and withdraws the record. |
36+
| 2026-07-16 | <span className="badge badge--success cve-rejected">Officially rejected</span> huntr / Protect AI accepts the dispute and withdraws the record. **The CVE record is now officially REJECTED.** |
37+
| <span className="badge badge--warning">Still open</span> | **The huntr report page has not followed the withdrawal.** The report is still shown as Valid with a green check and its status as "Awaiting fix", while the CVE field on the same page reads Rejected. |
38+
| 2026-08-08 | Open WebUI asks huntr / Protect AI to bring the report validity and fix status in line with the withdrawal, and to make those fields follow CVE state transitions so it does not recur. Awaiting response. |
3339

3440
The record is now in the **REJECTED** state on cve.org, and that state propagates to NVD and downstream feeds. No action is required from users, and the CVE should not be treated as an Open WebUI vulnerability.
3541

‎docs/security/vendor-dispositions/cve-2024-7034.mdx‎

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,10 +16,14 @@ title: "CVE-2024-7034"
1616

1717
---
1818

19+
<div className="cve-resolved">
20+
1921
:::tip Resolved: this CVE is now rejected
2022
The issuing CNA has withdrawn the record, so the official CVE entry now carries the `REJECTED` state and NVD and downstream feeds inherit it. The public record now matches Open WebUI's vendor disposition below, confirming our assessment that this was not a genuine vulnerability. There is no advisory and no affected Open WebUI release.
2123
:::
2224

25+
</div>
26+
2327
## Timeline
2428

2529
This CVE was **withdrawn by its issuing CNA** after review. Open WebUI's assessment below is the basis on which the record was rejected.
@@ -29,7 +33,9 @@ This CVE was **withdrawn by its issuing CNA** after review. Open WebUI's assessm
2933
| 2025-03-20 | huntr / Protect AI publishes the CVE. |
3034
| 2026-07-08 | Open WebUI publishes this disposition, rejecting the report as out of scope. |
3135
| 2026-07-08 | Open WebUI contacts huntr / Protect AI directly to dispute the record. |
32-
| 2026-07-16 | huntr / Protect AI accepts the dispute and withdraws the record. |
36+
| 2026-07-16 | <span className="badge badge--success cve-rejected">Officially rejected</span> huntr / Protect AI accepts the dispute and withdraws the record. **The CVE record is now officially REJECTED.** |
37+
| <span className="badge badge--warning">Still open</span> | **The huntr report page has not followed the withdrawal.** The report is still shown as Valid with a green check and its status as "Awaiting fix", while the CVE field on the same page reads Rejected. |
38+
| 2026-08-08 | Open WebUI asks huntr / Protect AI to bring the report validity and fix status in line with the withdrawal, and to make those fields follow CVE state transitions so it does not recur. Awaiting response. |
3339

3440
The record is now in the **REJECTED** state on cve.org, and that state propagates to NVD and downstream feeds. No action is required from users, and the CVE should not be treated as an Open WebUI vulnerability.
3541

0 commit comments

Comments
 (0)