# Tenable Source: https://docs.openwebui.com/security/supply-chain-security/vulnerability-databases/tenable | | | | --- | --- | | Product | Tenable CVE database | | Problem | Withdrawn records carry the rejection notice and keep their severity rating and CVSS scores | | First contacted | 2026-08-08 | | Channels tried | vulnreport@tenable.com (published in their security.txt) | | Status | Auto-reply redirected us to a product-vulnerability submission form. Awaiting a substantive response. | > **note** > > Tenable ingests reject transitions. The description field on a withdrawn record reads that the identifier has been rejected by its CNA. The problem is described below. --- ## The rejection reaches the description and stops there Take [CVE-2024-7038](https://www.tenable.com/cve/CVE-2024-7038), withdrawn by huntr / Protect AI on 2026-07-16. The Tenable page states the position plainly in its description: > Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. Everything else on the page contradicts it. The record is headed **medium**, and the Risk Information block is intact and unqualified: | Field | Value shown | | --- | --- | | Severity | Medium | | CVSS v2 | 3.3 | | CVSS v3 | 2.7 | | CVSS v4 | 5.1 (no CVSS v4 score was assigned by the issuing CNA) | | EPSS | 0.00062 | A rejected identifier cannot carry a severity, because there is no finding left to rate. This one is labelled Medium, and every score behind that label is presented without qualification. The same holds on [CVE-2025-15603](https://www.tenable.com/cve/CVE-2025-15603), withdrawn by VulDB on 2026-06-18, which is likewise headed **Medium** and carries CVSS v2 2.6, v3 3.7 and v4 **6.3**. The issuing CNA's own v4 score for that record is 2.9, so the figure driving the Medium label is more than double it and comes from elsewhere. ### The severity is the field that travels On a page, the contradiction is at least visible. The description and the severity sit together and a reader can see both. Everywhere else, they come apart. A severity is a single structured value, which is what makes it easy to sort, filter, threshold and display, and that is why it is the field that downstream systems consume. The rejection is a paragraph of English inside a description field. Nothing else on the entry carries the withdrawal, so there is no structured field on the page that a consumer could filter on. For these records the published judgement is Medium, and that is the field carried forward. The reject transition is processed. What remains is removing what it invalidates: a withdrawn identifier has no severity, no base score and no vector, and those fields should come off the record rather than remain beside the notice saying it was withdrawn. --- ## Contact log | Date | Channel | Outcome | | --- | --- | --- | | 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. | | 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. | ## A correction request is not a vulnerability submission 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 records in their database that no longer match the authoritative state at cve.org. The automated response directed us to the guidelines and form for reporting vulnerabilities _in Tenable products_. That path has no step for "your published data is wrong". 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. --- ## See also - [Rejected CVEs in Vulnerability Databases](/security/supply-chain-security/vulnerability-databases/) — the overview and how to verify any record yourself. - [Vendor Dispositions](/security/vendor-dispositions) — our assessment of each identifier filed against Open WebUI.