AdminNeo CVE-2026-96633
HIGH
GHSA-6vfx-w7q3-42gq
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to AdminNeo SQLite mode
-
DeliveryObtain live CSRF token
-
ExploitSubmit crafted db[] drop request with arbitrary path
-
Executionunlink() deletes writable file
-
ImpactIntegrity/availability loss of targeted files
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V5 - File Handling File name/path control
|
| Exploitation Conditions | Exploitation requires an authenticated AdminNeo session running in SQLite mode together with a valid CSRF token, and the targeted file must be deletable by the PHP process; the attacker then submits an arbitrary relative file path in the database-list db[] field, which reaches drop_databases() and unlink() without the .db/.sdb/.sqlite extension validation applied to create/rename. Limiting factors that reduce real-world risk: the attacker must already be authenticated (PR:L) and possess a live CSRF token, the instance must be deployed in SQLite mode, and impact is bounded to files writable by the PHP process; versions before 5.5.1 are affected and the fix is only complete by updating to 5.5.1. |
| Impact | This is a genuine but conditional priority rather than a drop-everything emergency. The supplied CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, base 8.1 High) shows a network-reachable, low-complexity flaw with no user interaction and high integrity and availability impact, but PR:L confirms it requires an authenticated session - so this is not an unauthenticated internet-facing bug. No EPSS score was provided, so statistical exploitation probability cannot be assessed, and the CVE is not listed in CISA KEV, so there is no confirmed active exploitation. A detailed, vendor-validated proof-of-concept (step-by-step reproduction with a live request) is published in the GHSA advisory, so working exploitation is clearly demonstrated even though it is not an unauthenticated mass-exploitation primitive. The vuln.today decision label is 'this_week', consistent with a patched, authenticated, high-impact issue that should be remediated promptly but is not flagged act_now/emergency. Net: the signals are internally consistent (High CVSS, demonstrated PoC, this_week priority) and the main factors reducing real-world risk are the authentication requirement, the SQLite-mode-only trigger, and the niche deployment footprint of this product. Missing data to note explicitly: EPSS is absent and KEV status is negative, so widespread or targeted exploitation cannot be confirmed either way. |
| Exploit ScenarioDerived | An attacker who already holds a valid low-privilege authenticated AdminNeo session in SQLite mode, plus a live CSRF token, submits a crafted database-list drop request placing an arbitrary relative file path in the db[] field. Because the SQLite drop_databases() path passes submitted values straight to unlink() without the check_sqlite_name() extension check used for create/rename, AdminNeo deletes any file writable by the PHP process even if it is not a SQLite database. A validated proof-of-concept demonstrating this (deleting /var/www/html/poc-delete-target.txt) is published in the vendor advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 30, 2026
Arbitrary file deletion in AdminNeo's SQLite driver allows an authenticated SQLite-mode user to remove any file writable by the PHP process by submitting a non-database path in the database-list drop parameter (db[]). Versions before 5.5.1 are affected: create and rename operations are guarded by the .db/.sdb/.sqlite extension check, but the drop path passes submitted values straight to unlink(). Exploitation requires an authenticated AdminNeo session in SQLite mode plus a live CSRF token, and impact is confined to files the PHP process can delete; the GitHub advisory publishes reproduction steps that were validated against a Docker/Nginx deployment. This is a genuine but conditional priority rather than a drop-everything emergency, and the fix is only complete by updating to 5.5.1.
RemediationAI
Upgrade AdminNeo to version 5.5.1, which is the vendor-released patch and the only complete fix identified at time of analysis; the change is commit 26fcef2f32922629751cbea6c0bb593fbf1e957d ("SQLite: Check filename before deleting"), released under https://github.com/adminneo-org/adminneo/releases/tag/v5.5.1, with details in advisory https://github.com/adminneo-org/adminneo/security/advisories/GHSA-6vfx-w7q3-42gq. Updating via Composer means requiring adminneo-org/adminneo 5.5.1 or later. If upgrading is not immediately possible, the exposure can be narrowed by not granting SQLite-mode sign-in to users who should not be able to delete files, and by reducing what the PHP process is permitted to delete - impact is bounded to files writable by that process, so tightening filesystem permissions on the web root (for example keeping writable paths out of the document root) removes reachable targets, at the cost of restricting where SQLite database files can live. The fixed build enforces the .db/.sdb/.sqlite extension check on delete; the advisory's suggested fix further recommends binding submitted db[] values to AdminNeo's own database listing, resolving paths before deletion to reject traversal outside the expected SQLite directory, and requiring the currently selected database path for delete operations.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in composer
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
AdminNeo is a PHP-based database administration front end (a fork of Adminer, where the issue was originally reported) distributed as the Composer package composer/adminneo-org/adminneo and commonly deployed as a standalone PHP application behind Nginx or in Docker. The flaw is CWE-73 (External Control of File Name or Path): the database-list page takes selected database names from the POST body (db[]) and hands them to drop_databases(), and in the SQLite driver that function closes the connection and calls unlink() on each submitted path. The SQLite driver already validates database filenames during create and rename through check_sqlite_name(), which requires a .db, .sdb or .sqlite extension (explicitly to avoid creating PHP files on unsecured servers), but no equivalent validation - and no binding of submitted paths to the databases returned by AdminNeo's own listing - existed on the delete path. The upstream commit 26fcef2f32922629751cbea6c0bb593fbf1e957d adds a call to check_sqlite_name() inside the drop_databases() loop, rejecting targets whose names lack the allowed extensions; the advisory's suggested fix additionally recommends resolving paths before deletion to reject traversal outside the expected SQLite directory and requiring the currently selected database path for delete operations. Attack surface is limited to instances running in SQLite mode, and the trigger for deletion is a POST to the database-list drop action carrying a crafted db[] value; the advisory stresses that a valid CSRF token and an authenticated session are both prerequisites.
Know when Sqlite gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Network-reachable web action with authenticated low-privilege user (PR:L) and CSRF token, no UI; arbitrary file deletion gives high integrity and availability impact but no data disclosure (C:N).
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
DescriptionGitHub Advisory
Summary
AdminNeo allows an authenticated SQLite-mode user to delete arbitrary files writable by the PHP process through the database-list drop action. The SQLite driver validates file extensions when creating or renaming databases, but the database-list drop path passes submitted db[] values directly to unlink().
Originally reported by @slpoiuewalspoid-dotcom in Adminer: https://github.com/vrana/adminer/security/advisories/GHSA-6pg3-chwq-wgqc
Impact
An authenticated AdminNeo SQLite user with a valid CSRF token can submit an arbitrary relative file path in the database-list db[] field. If the PHP process can delete that path, AdminNeo unlinks it even when the file is not a SQLite database.
Root Cause
The database-list page accepts selected database names from the POST body and calls drop_databases():
if ($_POST["db"]) {
queries_redirect(substr(ME, 0, -1), lang('Databases have been dropped.'), drop_databases($_POST["db"]));
}In SQLite mode, drop_databases() attaches an in-memory database and unlinks each submitted path directly:
function drop_databases($databases): bool
{
Connection::get()->close(); // to unlock file, doesn't work in PDO on Windows
foreach ($databases as $db) {
if (!@unlink($db)) {
Connection::get()->setError(lang('File exists.'));
return false;
}
}
return true;
}The same SQLite driver protects create and rename operations with check_sqlite_name(), which requires a .db, .sdb, or .sqlite extension:
function check_sqlite_name($name) {
// avoid creating PHP files on unsecured servers
$extensions = "db|sdb|sqlite";
if (!preg_match("~^[^\\0]*\\.($extensions)\$~", $name)) {
Connection::get()->setError(lang('Please use one of the extensions %s.', str_replace("|", ", ", $extensions)));
return false;
}
return true;
}The drop path does not apply an equivalent extension check or bind the submitted path to a known listed SQLite database.
POC
1. Start a complete AdminNeo application
Build and start AdminNeo from the audited source using the official standalone Docker image shape. The validation image copies the audited source tree into /var/www/html and starts Nginx HTTP server.
Log in through the SQLite entry point using a SQLite database path poc.sqlite.
2. Prepare a writable target file
Place a non-database file under a location writable by the AdminNeo PHP process. The validation used:
/var/www/html/poc-delete-target.txtThe same directory also contained a SQLite database:
/var/www/html/poc.sqlite3. Submit the database-list drop request
Use the authenticated session and live CSRF token, but submit the non-database path as the selected database:
POST /?sqlite=&username= HTTP/1.1
Host: <adminer-host>
Cookie: <authenticated-session>
Content-Type: application/x-www-form-urlencoded
db[]=/var/www/html/poc-delete-target.txt&all=&drop=Drop&token=<live-csrf-token>The request reaches drop_databases($_POST["db"]), and SQLite drop_databases() calls unlink() on the submitted non-database path.
After the request, the poc-delete-target.txt was deleted.
Suggested Fix
Apply the same target validation used by SQLite create/rename before deleting database files. At minimum:
- Reject paths whose basename does not end in
.db,.sdb, or.sqlite. - Bind
db[]values to databases returned by AdminNeo's database listing instead of trusting submitted paths. - Resolve paths before deletion and reject traversal outside the expected SQLite database directory.
- Consider requiring the current selected database path for delete operations instead of accepting arbitrary submitted file paths.
Articles & Coverage 3
Technical POC Analysis
CWE-73: External Control of File Name or Path.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
AdminNeo versions prior to 5.5.1 contain a high-severity arbitrary file deletion vulnerability in the SQLite driver (CVE-2026-96633). Authenticated SQLite-mode administrators could delete any file writable by the PHP process, potentially disrupting operations or destroying critical data. Leadership should prioritize remediation to protect the integrity of systems managed through AdminNeo.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Cross-Site Request Forgery exploits the automatic credential inclusion behavior of web browsers.
Affected Products (CPE)GitHub Advisory
Multiple unspecified vulnerabilities in SQLite before 3.8.10.2, as used in Apple iOS before 9, have unknown impact and a
SQLite3 from 3.6.0 to and including 3.27.2 is vulnerable to heap out-of-bound read in the rtreenode() function when hand
SQLite 1.0.12 through 3.39.x before 3.39.2 sometimes allows an array-bounds overflow if billions of bytes are used in a
The getNodeSize function in ext/rtree/rtree.c in SQLite through 3.19.3, as used in GDAL and other products, mishandles u
Memory corruption in SQLite versions before 3.50.2 allows network-based attackers with low privileges to manipulate aggr
An exploitable use after free vulnerability exists in the window function functionality of Sqlite3 3.26.0. Rated high se
Arbitrary DLL loading in SQLite's sqldiff.exe utility on Windows allows attackers to achieve code execution by abusing t
Memory corruption in SQLite versions before 3.53.2 enables attackers to crash processes, exhaust memory, or potentially
SQLite 3.32.2 has a use-after-free in resetAccumulator in select.c because the parse tree rewrite for window functions i
SQLite through 3.31.1 allows attackers to cause a denial of service (segmentation fault) via a malformed window-function
A segmentation fault can occur in the sqlite3.exe command-line component of SQLite 3.36.0 via the idxGetTableInfo functi
OAuth and SCIM identity confusion in Open WebUI 0.6.41-0.10.x (SQLite-backed deployments only) allows unauthenticated re
Exploit-DB