Tenable
| Product | Tenable vulnerability database |
| Records still shown as active | 1 |
| First contacted | 2026-08-08 |
| Channels tried | [email protected] (published in their security.txt) |
| Status | Auto-reply redirected us to a product-vulnerability submission form. Awaiting a substantive response. |
Records
CVE-2025-15603
| Authoritative state | REJECTED at cve.org and NVD since 2026-06-18 |
| Withdrawn by | VulDB, the issuing CNA, as a false positive |
| CNA rating before withdrawal | Low (CVSS 2.6, 3.7 and 2.9) |
| What Tenable displays | An active vulnerability in open-webui, weak WEBUI_SECRET_KEY randomness, carrying Medium severity |
| Our assessment | CVE-2025-15603 |
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.
Contact log
| Date | Channel | Outcome |
|---|---|---|
| 2026-08-08 | [email protected], 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 publishes two contact methods, a HackerOne program and mailto:[email protected]. 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.
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.
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 — the overview and how to verify any record yourself.
- CVE-2025-15603 vendor disposition