SURIQ
The dangerous detail in the new ERPNext database flaw is not the SQL injection itself. It is who gets to fire it. Creating a supplier record is a routine, low-privilege task in ERPNext, the kind of thing a purchasing clerk or a vendor-onboarding integration does every day. CVE-2026-12895 turns that everyday action into a read of the whole database, down to pieces of the admin account's password hash and whatever integration tokens the instance holds.
Frappe fixed the issue in ERPNext 15.111.0 for the 15.x line and 16.22.0 for the 16.x line. If you self-host ERPNext, that upgrade is this week's work. The reason it earns more than a routine patch note is the blast radius: the flaw sidesteps the permission model that ERPNext operators rely on to keep low-privilege users in their lane.
What the flaw actually does
Spain's national cybersecurity body, INCIBE, coordinated the disclosure and credited researcher Alejandro Ramos. According to the Frappe advisory and the CVE record, ERPNext built some SQL queries by interpolating strings with Python's str.format() rather than using parameterized queries. The name of a Supplier record, what Frappe calls the docname, was one of the values dropped straight into a query. Put SQL metacharacters in that name and the database reads them as query syntax instead of data.
From there, an authenticated user with low privileges can run arbitrary SQL. That is the part worth sitting with. Those queries do not pass through Frappe's DocPerm layer, the access-control system that decides which records a role is allowed to see, so the attacker reads tables the application would never render for them: the user and authentication records, stored credentials, API and integration tokens, and financial data. INCIBE's notice describes exactly this reach.
Why "low privilege" is the scary part, not a reassurance
The advisories rate this 7.1 on the CVSS 4.0 scale, a high rather than a critical, and the score reflects that an attacker needs an account before anything else. Do not read that as comfort. In many ERPNext deployments the accounts that can create or edit suppliers are handed out widely: purchasing staff, accounts-payable users, and in some setups a supplier or customer portal, or an inbound integration that creates records over the API. Each of those becomes a possible path to reading the crown jewels of the install.
The injection point is easy to miss in code review for the same reason it is dangerous. A record's name looks like an identifier, not like untrusted input, so it does not draw the scrutiny a search box or a filter parameter would. Injection through a docname is a reminder that in a system where users name their own records, the name field is user input. It is the same lesson we keep relearning from the bug classes that refuse to die.
Affected and fixed versions
| ERPNext branch | Affected | Fixed in |
|---|---|---|
| 15.x | Below 15.111.0 | 15.111.0 |
| 16.x | Below 16.22.0 | 16.22.0 |
The researcher identified the flaw on ERPNext 15.107.0 with Frappe 15.107.2. Both maintained branches received a fix: move the 15.x line to 15.111.0 or later, and the 16.x line to 16.22.0 or later. The advisory lists no configuration workaround, so upgrading is the fix. The same read-everything shape has shown up in other self-hosted enterprise software this year, including Quest NetVault Backup and self-hosted admin panels like Control Web Panel.
Patch is step one. Rotation is step two.
Because this flaw exposes secrets rather than crashing a service, upgrading does not undo any access that already happened. If your ERPNext instance has been reachable by users or integrations you do not fully trust, treat the stored secrets as potentially read and rotate them once you patch: the administrator password, any API keys and integration tokens configured in the instance, and credentials for connected services such as payment gateways or mail. There is no public exploit and no report of exploitation in the wild at the time of writing, so scale this to your exposure rather than treating every install as an emergency.
For detection, the signal lives in your database and application logs, not in a network signature. Watch for SQL metacharacters appearing inside document names, unexpected queries issued from low-privilege sessions, and reads against user, authentication, or secrets tables that a normal ERPNext workflow would never touch. If you keep query logs on the database behind Frappe, that is where this abuse would leave a trace.
The pattern behind the bug
SQL injection is thirty years old and still lands on maintained, actively developed software. The lesson ERPNext underlines is narrower and more useful than "sanitize your inputs": string interpolation into SQL is unsafe no matter how trusted the value looks, and an object's own name is not exempt. Parameterized queries are the fix in the code. For operators, the discipline is the mirror image applied to access: assume any account that can create records can reach further than its role suggests, and rotate secrets whenever a read-everything bug like this one lands.