BaseFortify by Axxemble


Product	BaseFortify, a product of Axxemble (basefortify.eu, contact at axxemble.nl)
Problem	The page carries the full rejection notice, and its AI-generated assessment contradicts it
First contacted	2026-08-08
Channels tried	`[email protected]`
Status	Awaiting response

The page states the record is rejected, and then describes the vulnerability

The BaseFortify entry for CVE-2025-15603 reproduces the CNA's withdrawal in full, verbatim, in its Description field, including the vendor explanation recorded alongside it:

** 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)."

That text includes our own explanation of why the reported behaviour was never exploitable. It is on the page.

Directly beside it, in an AI Quick Actions panel occupying the right-hand column of the same screen, a generated Executive Summary reaches the opposite conclusion:

The vulnerability arises because the argument WEBUI_SECRET_KEY is manipulated in a way that leads to insufficiently random values being generated for security-critical keys. [...] The vulnerability can be exploited remotely without authentication, although the attack requires a high level of complexity and is considered difficult to execute.

There is no vulnerability and it was never remotely exploitable. The withdrawal notice explaining both sits level with the generated summary, on the same screen, and both are visible at once.

A reader therefore sees the correct answer and the wrong one in the same glance, and only one of the two is written in the register of an assessment. The rejection is a quoted administrative notice. The contradiction beside it is a confident explanation of how the vulnerability works.

When the summary was produced

The entry shows four dates. Published 2026-03-09, Last Modified 2026-06-18, AI Q&A 2026-03-09 and Generated 2026-08-08, the day we retrieved the page.

We cannot tell from these when the Executive Summary was written. "Generated" appears to be the time the page was rendered, and "AI Q&A" carries the publication date, which suggests the generated material dates from March 2026 and predates the withdrawal in June.

That is the charitable reading and we will assume it. It does not rescue the entry. Whenever the text was written, it is being served today, beside a withdrawal notice, to anyone who opens the page.

The word "rejected" appears once, in the description, and nowhere else

Every other element of the entry presents an ordinary, current finding:

The status badge on the record reads Received.
The title reads "Insufficient Entropy in open-webui JWT Key Handler Allows Remote Attack".
CVSS scores are offered across versions 4.0, 3.1 and 2.0, with a base score of 2.9, a base severity of LOW and a radar chart plotting the vector across eight axes.
EPSS Scores are displayed as current risk data, with a probability and a percentile.
An Affected Vendors & Products table lists a CPE for open-webui, from 0.6.0 through 0.6.16.
An Attack-Flow Graph maps the record onto CWE-330 and CWE-310, then onward to CAPEC attack patterns including "Brute Force", "Signature Spoofing by Key Recreation" and "Session Credential Falsification through Prediction", and from there to MITRE ATT&CK techniques.

A withdrawn record has been given a severity, an affected version range, an exploitation-probability score and a threat-technique mapping. None of it describes anything that exists.

It also means the rejection is invisible to anything that does not parse the description prose. A consumer reading the status field sees "Received". A consumer reading severity sees LOW. A consumer reading the affected range sees 0.6.0 through 0.6.16.

The withdrawal is a single field inside a complete presentation of a live vulnerability: a generated summary explaining how it is exploited, a scored vector rendered as a chart, an exploitation-probability estimate, an affected version range, a weakness classification and a mapped attack chain. Take the description away and nothing on the page would look unusual for a current, unpatched finding.

Generated assessments need a rejection check before anything else

The lesson generalises past this one entry. Asked to summarise a CVE record, a language model is being asked to describe a vulnerability, and the surrounding material is written as though one exists. Producing a confident description of it is the expected result, not a malfunction. Withdrawal is the one piece of context most likely to be lost, because it arrives later and as prose.

Presenting machine-generated exploitability analysis on rejected records is worse than presenting nothing. It converts a correction that the CNA already published into a fluent, authoritative paragraph telling the reader the opposite.

Their `security.txt` expired in January 2025

We record this because it is the same shape of problem as the entry itself, and because it is trivially checkable. BaseFortify publishes a security.txt:

Contact: mailto:[email protected]
Expires: 2025-01-06T10:08:01Z
Encryption: https://basefortify.eu/.well-known/publickey.asc
Signature: https://basefortify.eu/.well-known/security.txt.sig
Canonical: https://basefortify.eu/.well-known/security.txt

RFC 9116 requires the Expires field and states that the file should not be used once that date has passed. This one expired on 2025-01-06, more than nineteen months ago. The address does still receive mail, so the file is stale rather than broken, but a security contact that has been formally expired for over a year and a half is not one a reporter should have to rely on.

Contact log

Date	Channel	Outcome
2026-08-08	`[email protected]`, the address in their expired `security.txt`	Awaiting response

The page states the record is rejected, and then describes the vulnerability​

When the summary was produced​

The word "rejected" appears once, in the description, and nowhere else​

Generated assessments need a rejection check before anything else​

Their security.txt expired in January 2025​

Contact log​

See also​