|
| 1 | +--- |
| 2 | +sidebar_position: 8 |
| 3 | +title: "BaseFortify by Axxemble" |
| 4 | +--- |
| 5 | + |
| 6 | +# BaseFortify by Axxemble |
| 7 | + |
| 8 | +| | | |
| 9 | +| :--- | :--- | |
| 10 | +| **Product** | BaseFortify, a product of Axxemble (basefortify.eu, contact at axxemble.nl) | |
| 11 | +| **Problem** | The page carries the full rejection notice, and its AI-generated assessment contradicts it | |
| 12 | +| **First contacted** | 2026-08-08 | |
| 13 | +| **Channels tried** | `support@axxemble.nl` | |
| 14 | +| **Status** | Awaiting response | |
| 15 | + |
| 16 | +--- |
| 17 | + |
| 18 | +## The page states the record is rejected, and then describes the vulnerability |
| 19 | + |
| 20 | +The BaseFortify entry for [CVE-2025-15603](https://basefortify.eu/cve_reports/2026/03/cve-2025-15603.html) reproduces the CNA's withdrawal in full, verbatim, in its Description field, including the vendor explanation recorded alongside it: |
| 21 | + |
| 22 | +> \*\* 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)." |
| 23 | +
|
| 24 | +That text includes our own explanation of why the reported behaviour was never exploitable. It is on the page. |
| 25 | + |
| 26 | +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: |
| 27 | + |
| 28 | +> 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. |
| 29 | +
|
| 30 | +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. |
| 31 | + |
| 32 | +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. |
| 33 | + |
| 34 | +### When the summary was produced |
| 35 | + |
| 36 | +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. |
| 37 | + |
| 38 | +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. |
| 39 | + |
| 40 | +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. |
| 41 | + |
| 42 | +### The word "rejected" appears once, in the description, and nowhere else |
| 43 | + |
| 44 | +Every other element of the entry presents an ordinary, current finding: |
| 45 | + |
| 46 | +- The status badge on the record reads **Received**. |
| 47 | +- The title reads "Insufficient Entropy in open-webui JWT Key Handler Allows **Remote Attack**". |
| 48 | +- 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. |
| 49 | +- **EPSS Scores** are displayed as current risk data, with a probability and a percentile. |
| 50 | +- An **Affected Vendors & Products** table lists a CPE for `open-webui`, from 0.6.0 through 0.6.16. |
| 51 | +- 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. |
| 52 | + |
| 53 | +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. |
| 54 | + |
| 55 | +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. |
| 56 | + |
| 57 | +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. |
| 58 | + |
| 59 | +### Generated assessments need a rejection check before anything else |
| 60 | + |
| 61 | +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. |
| 62 | + |
| 63 | +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. |
| 64 | + |
| 65 | +--- |
| 66 | + |
| 67 | +## Their `security.txt` expired in January 2025 |
| 68 | + |
| 69 | +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`](https://basefortify.eu/.well-known/security.txt): |
| 70 | + |
| 71 | +``` |
| 72 | +Contact: mailto:support@axxemble.nl |
| 73 | +Expires: 2025-01-06T10:08:01Z |
| 74 | +Encryption: https://basefortify.eu/.well-known/publickey.asc |
| 75 | +Signature: https://basefortify.eu/.well-known/security.txt.sig |
| 76 | +Canonical: https://basefortify.eu/.well-known/security.txt |
| 77 | +``` |
| 78 | + |
| 79 | +[RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html) 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. |
| 80 | + |
| 81 | +--- |
| 82 | + |
| 83 | +## Contact log |
| 84 | + |
| 85 | +| Date | Channel | Outcome | |
| 86 | +| :--- | :--- | :--- | |
| 87 | +| 2026-08-08 | `support@axxemble.nl`, the address in their expired `security.txt` | Awaiting response | |
| 88 | + |
| 89 | +--- |
| 90 | + |
| 91 | +## See also |
| 92 | + |
| 93 | +- [Rejected CVEs in Vulnerability Databases](./) — the overview and how to verify any record yourself. |
| 94 | +- [CVE-2025-15603 vendor disposition](/security/vendor-dispositions/cve-2025-15603) |
0 commit comments