SentinelOne
| Product | SentinelOne Vulnerability Database |
| Records still shown as active | 1 |
| First contacted | 2026-07-23 |
| Channels tried | Four: [email protected] (published in their security.txt), [email protected], the contact form on their website, and a direct message on X |
| Status | No response on any channel. The published security contact does not accept mail. |
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.
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.
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 classification before withdrawal | CWE-330, use of insufficiently random values. Rated Low (CVSS 2.6, 3.7 and 2.9) |
| What SentinelOne displays | An active vulnerability in open-webui, characterised as "JWT Key Handler RCE" |
| Our assessment | CVE-2025-15603 |
Two separate defects are stacked here. The first is status: the identifier has been withdrawn and the page still presents it as live. The second is classification: remote code execution was never the CNA's finding. VulDB filed insufficiently random values and rated it Low, then withdrew it entirely. The recorded rejection reason on the CVE record states that the default value in question was inactive code, unreachable through any supported startup method.
A record presented to enterprise customers as remote code execution, when the issuing CNA rated it Low and then withdrew it, overstates the original finding in two directions at once.
Contact log
| Date | Channel | Outcome |
|---|---|---|
| 2026-07-23 | [email protected], the address published in their security.txt | Delivery failed. The receiving system rejected the message. |
| 2026-07-23 | [email protected], 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. |
| 2026-07-23 | Contact form on the SentinelOne website | No response |
| 2026-07-23 | Direct message on X | No response |
| 2026-08-03 | Follow-up on both addresses | No response |
| 2026-08-08 | Follow-up on both addresses | Delivery to the security.txt address failed again. No response on either. |
| 2026-08-08 | Contact form on the SentinelOne website, submitted a second time | No response |
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.
The published security contact rejects all mail
A security.txt file exists for one reason: so that anyone with something to report can find the correct address without guessing. It is the machine-readable front door to a company's disclosure process, standardised as RFC 9116. SentinelOne publishes one, and the single address in it does not accept mail.
The file at /.well-known/security.txt designates exactly one point of contact:
Contact: mailto:[email protected]
Expires: 2029-12-31T06:00:00.000Z
Preferred-Languages: en
Every message we sent to that address was rejected by the receiving system before it reached a person:
We're writing to let you know that the group you tried to contact (security)
may not exist, or you may not have permission to post messages to the group.
The address resolves to a Google Group at sentinelone.com that is closed to external posters. We received this bounce on every attempt, most recently on 2026-08-08, more than three years before the expiry date the file itself advertises.
Publishing an address and rejecting mail at it is not a reachable security contact. It is the appearance of one, and it fails in the worst way available: the reporter does the correct thing, follows the published route, and is turned away by a mail server. The only other published route, info@, is sales intake, so a security report sent there is answered by marketing automation. Those two are precisely the channels someone acting in good faith finds first.
We state it plainly because SentinelOne is a security vendor, and because a working disclosure contact is table stakes that its own customers are expected to meet.
See also
- Rejected CVEs in Vulnerability Databases — the overview and how to verify any record yourself.
- CVE-2025-15603 vendor disposition