baserCMS CVE-2026-114621

The attacker must be able to log into the baserCMS admin panel; exploitation targets the list and detail actions under the Admin and Api/Admin prefixes, triggered by supplying ORM-structure query parameters (contain, conditions, fields, finder, order) that the admin controllers pass directly into the ORM via array_merge, letting request values override defaults and reach the EagerLoader. The primary limiting factor is the authentication requirement (PR:L) - an admin-panel account is needed - which confines exposure to deployments with multiple or semi-trusted admin users or to credential-compromise scenarios. Critically, the documented hardening of setting USE_CORE_ADMIN_API to false does NOT prevent exploitation, because an authenticated browser session still reaches these paths; the earlier 5.3.1/5.4.1 public-page and public-API fixes also did not cover these administrative paths. The only complete fix stated by the vendor is upgrading to 5.3.2 or 5.4.2; the only workaround given is restricting admin accounts to trusted users.

This is a genuine near-term priority for any organization actually running baserCMS, though its blast radius is limited by the product's niche footprint and by an authentication prerequisite. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N, 8.8) is internally consistent with the description: exploitation is network-reachable, low-complexity, requires no user interaction, but does require privileges (PR:L) because the attacker must first authenticate to the admin panel. The CIA triad is fully High - reading password hashes from the users table (C:H) and executing arbitrary SQL that can modify or destroy data (I:H/A:H) - which is credible for a raw SQL injection via ORM options (CWE-89). No EPSS score, no CISA KEV listing, and no PoC/exploit reference were supplied, so there is no evidence of active exploitation or public weaponization; the only external urgency signal is the vuln.today 'this_week' decision label, which aligns with a patched-but-serious authenticated flaw rather than an emergency. The main nuance to flag: PR:L understates the trust barrier in practice - admin-panel access is itself a meaningful gate, so real risk concentrates on multi-user admin deployments and any environment where admin credentials could be phished, reused, or held by semi-trusted operators. A notable confirmed subtlety is that the common hardening step USE_CORE_ADMIN_API=false does NOT mitigate this, since an authenticated browser session still reaches the vulnerable admin paths.

An attacker who holds or obtains any baserCMS admin-panel login (e.g., a low-privilege operator account, or stolen/reused credentials) issues a list or detail request to an Admin or Api/Admin endpoint with crafted query parameters such as contain[Users][conditions][] or order, embedding SQL fragments that the ORM passes straight into WHERE/SELECT/ORDER BY clauses. They use a subquery to exfiltrate password hashes from the users table, then crack or reuse them to escalate to higher-privileged accounts. No public exploit code is referenced, but the vendor advisory and patch commit describe the exact injectable parameters and vulnerable paths, materially lowering the effort to reproduce.