DIAEnergie EUVD-2026-64761

The CVSS PR:L metric confirms that a valid low-privilege DIAEnergie application account is required - unauthenticated exploitation is not supported by the available data. Beyond that credential requirement, attack complexity is low (AC:L), meaning no race condition, specific timing, or complex multi-step pre-condition is necessary. The attack is delivered over the network (AV:N) with no user interaction required. The specific vulnerable parameter or endpoint is not named in the available advisory summary; full technical details require review of the vendor advisory PDF. Exploitation is bounded by the need for at least one application credential and by whether the underlying database service has OS-command execution capabilities enabled; if those database features are disabled, the impact may be limited to data exfiltration and integrity loss rather than full RCE.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) scores 8.8, reflecting network-accessible exploitation with low attack complexity and only low-privilege credentials required - a combination historically associated with rapid weaponization once disclosed. No EPSS score is present in the available data, which limits probabilistic exploitation forecasting; the absence of a CISA KEV listing means active exploitation is not confirmed, but this should not be taken as evidence of safety given the OT context. The RCE-class outcome of an SQL injection vulnerability in industrial energy management software means a successful attack could disrupt energy monitoring, manipulate operational data, or serve as a pivot into segmented OT networks. The PR:L requirement does provide a meaningful limit: attackers must possess at least one valid application credential, reducing but not eliminating exposure, particularly in environments with broadly provisioned user accounts.

An attacker holding a low-privilege DIAEnergie account submits a crafted SQL payload through a vulnerable application parameter over the network. The unsanitized input reaches the backend database, where the attacker leverages a database command-execution mechanism to issue operating system commands under the database service account context. This results in full server compromise and potential lateral movement into the broader OT network infrastructure.