DIAEnergie CVE-2026-78310

Requires a valid authenticated session to DIAEnergie at low privilege (PR:L) - this is NOT unauthenticated. Exploitation then depends on an application function that accepts a user-controlled key/identifier (record ID, report ID, or object reference) and fails to verify the requesting user's authorization for that object. No user interaction by a victim is needed (UI:N), and it is network-reachable (AV:N) against the DIAEnergie web/API interface. The main limiting factor is the credential requirement, confining realistic abuse to legitimate low-privilege users, malicious insiders, or attackers who have already obtained credentials; impact is bounded to unauthorized data disclosure (C:L) with no integrity or availability effect.

This is a genuine but low-priority issue, not a high-CVSS scare. The vendor CVSS 3.1 base of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) is internally consistent with CWE-639 (Authorization Bypass Through User-Controlled Key, i.e. IDOR/BOLA): a network-reachable, low-complexity flaw exploitable by an already-authenticated low-privilege user, yielding only limited confidentiality impact with no integrity or availability effect. All exploitation signals point AWAY from urgency: no EPSS score is provided, the CVE is NOT in CISA KEV, and no public POC is referenced - exploitation status is therefore 'no public exploit identified at time of analysis.' There is no SSVC data supplied. The single limiting factor that most constrains real risk is PR:L: an attacker must first hold valid low-privilege credentials to the DIAEnergie application, so this is a horizontal/vertical data-access-broadening flaw for insiders or post-compromise actors rather than a pre-auth internet worm. No data conflicts are present; the description and CVSS vector agree. Note the CVE is self-reported by the vendor (Deltaww) via a single advisory PDF with no independent NVD enrichment, so severity rests solely on vendor assertion.

An authenticated low-privilege DIAEnergie user modifies a user-controlled identifier (such as a record, report, or object ID) in an API or web request to reference data belonging to another user or tenant that they are not authorized to view, and the application returns it without an ownership check. No public exploit code is referenced, and exploitation requires valid application credentials first.