BA-Workflow CVE-2026-113406

Exploitation requires an authenticated session: the attacker must possess valid credentials for a BA-Workflow account (PR:L), which is the primary limiting factor. Beyond authentication there are no special prerequisites indicated - the description cites no non-default feature, configuration toggle, or deployment mode, and the CVSS vector shows no user interaction (UI:N) and low complexity (AC:L/AT:N), so any authenticated user with network reachability to the application can inject SQL. The main constraints on real-world risk are thus credential requirement and the product's limited deployment base, not technical difficulty.

This is a credible but second-tier priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms a network-reachable, low-complexity SQL injection requiring only low-level authentication (PR:L) - meaning any legitimate application account can likely trigger it, with no user interaction. Vulnerable-system impact is maximal (VC:H/VI:H/VA:H), consistent with CWE-89 allowing read, modify, and delete of database contents. However, the signals that would elevate this to urgent are absent: no EPSS score was provided, there is no CISA KEV listing, and no public proof-of-concept is referenced - so there is no public exploit identified at time of analysis. The practical risk is therefore gated by two factors working against mass exploitation: an attacker must first hold valid credentials (PR:L), and BA-Workflow is a niche product with a small deployment footprint, making widespread opportunistic scanning unlikely. Net assessment: a real, high-impact flaw for organizations actually running BA-Workflow and worth prompt patching, but not a broad internet-wide emergency. No conflicting signals were found, though the absence of EPSS/KEV/POC data means exploitation likelihood is inferred rather than measured.

An attacker who holds a valid low-privilege BA-Workflow account (or who has phished/compromised one) sends crafted input through a vulnerable application parameter, injecting arbitrary SQL that the backend executes. This lets them read sensitive workflow and user data and tamper with or delete records across the database. No public exploit code is identified, so an attacker would need to develop the injection payload themselves, though the low attack complexity makes this straightforward for a skilled actor.