ERPNext CVE-2026-44446

Attacker must possess valid authentication credentials to the ERPNext instance (CVSS PR:L), meaning self-service signup, leaked credentials, or insider access is the prerequisite - pure unauthenticated exploitation is not indicated. The vulnerable endpoints must be network-reachable to the attacker (AV:N), and the target must run ERPNext < 15.104.3 on the 15.x branch or ERPNext 16.0.0-beta.1 through < 16.14.0 on the 16.x branch. No user interaction is required (UI:N) and attack complexity is low (AC:L), so once authenticated the attacker can exploit directly via crafted HTTP requests. Limiting factors: the authentication requirement blocks fully anonymous scanning, and the specific vulnerable endpoints are not enumerated in public data, so per-instance reconnaissance is required.

Signals are mixed and warrant nuanced prioritization. CVSS 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects network-reachable, low-complexity exploitation by any authenticated user with high impact on all three CIA dimensions, which is severe for a multi-tenant ERP holding finance, HR, and customer data. However, EPSS is only 0.04% (12th percentile) and CISA SSVC reports Exploitation=none with Automatable=no, suggesting no active exploitation campaigns and that weaponization would require per-target tuning rather than mass scanning. There is no CISA KEV listing and no public exploit identified at time of analysis. The Technical Impact=total rating combined with PR:L is the key driver: any low-privileged ERPNext account - including customer/supplier portal users in some deployments - could potentially escalate to full database disclosure, so internet-exposed instances with self-service signup should treat this as high priority despite low EPSS.

An attacker registers or compromises a low-privileged ERPNext account - for example a customer or supplier portal user on an internet-facing instance - then sends a crafted HTTP request to one of the vulnerable endpoints with malicious SQL syntax embedded in a parameter. The injected query extracts sensitive table contents such as user password hashes, API keys, financial records, or PII directly from the MariaDB backend. No public exploit identified at time of analysis, but the SQLi class is well-understood and reproducing exploitation from the diff in the fix commit is feasible for a motivated attacker.