By: Alex Williams
Pellera Technologies identified multiple vulnerabilities in Delta Electronics DIAEnergie, an industrial energy management software system that allows its users to visualize and monitor electric and power systems. These vulnerabilities can be chained together to achieve unauthenticated remote code execution.
Pellera reported these findings to Delta Electronics in July 2026, and the vulnerabilities were publicly disclosed in September 2026. This article breaks down two of these vulnerabilities: CVE-2026-78308 and CVE-2026-78309.
WithoutVerifyToken() Authentication Bypass – CVE-2026-78308
DIAEnergie uses two filters to enforce authentication for API endpoints: JwtAuthFilter(), which enforces the JWT Bearer token, and BasicAuthenticationFilter(), which enforces individual module privileges. In both filters, they call their member method WithoutVerifyToken() to check if authentication is required for the request [1] [2]. Note that this method is identical for both filters.
In both method calls to WithoutVerifyToken(), the value of the Request-URI is passed in as a parameter. The method WithoutVerifyToken() will check for multiple strings in the Request-URI. If any of the following checks are successful, the method successfully returns and authentication is bypassed as it is assumed that the user is attempting to access an unauthenticated endpoint [3]:
- Ending in the string “/Login”.
- Containing the string “/Login?”.
- Ending in the string “/PostEquip”.
- Ending in the string “/PostOPCUACEquip”.
- Ending in the string “/PostImageByEquipID”.
- Containing the string “/setLanguage?”.
The vulnerability exists because WithoutVerifyToken() evaluates the entire Request-URI, including URL parameters, rather than just the endpoint path. This enables an attacker to add one of the required strings above to a URL parameter’s values and bypass authentication to authenticated endpoints. For example, an HTTP POST request to the user creation endpoint could include a Request-URI like “/api/DIAE_us?x=/Login”. As this passes one of the conditionals, ending in the string “/Login”, this bypasses authentication and allows for unauthenticated attackers to create arbitrary users, including accounts with admin privileges.
GetCollectionByFilter() Authenticated SQL Injection to Remote Code Execution – CVE-2026-78309
In DIAEnergie, tags are used to describe alerts for monitoring. An authenticated user can query the list of existing tags by sending an HTTP GET request to the Request-URI “/DataHandler/WebApis/DIAE_tagHandler.ashx”. When this request is received, the method DIAE_tagHandler.ProcessRequest() [4] is called to handle the request. If the value of the HTTP parameter api is equal to the string “GetByFilter”, then the method _GetByFilter() is called [5].
In the method _GetByFilter(), the values of the HTTP parameters filter and keyword [6] are stored and eventually passed into the method DIAE_tagSQLRepository.GetCollectionByFilter() [7]. This is the method that retrieves the stored tags and filters them by the specified filter and/or keyword.
In the method DIAE_tagSQLRepository.GetCollectionByFilter(), the value of the filter and keyword parameters are formatted to be multiple LIKE conditionals on the later queries [8]. Multiple SQL queries are then executed depending on the values of the filter and keyword parameters.
This is one of the following SQL queries executed where the value of str4 is the value of the created LIKE conditionals.
select top(<Number_of_Results>) <Hardcoded_List_of_Columns> from DIAE_tag as t left join DIAE_itnl as i on t.tid=i.tfid where t.del<>1 <Hardcoded_Conditional> <str4>
The vulnerability exists as the value of the HTTP parameters filter and keyword are not sanitized of SQL injection-related characters/strings. Additionally, the SQL queries that are executed are not parameterized.
For example, the following parameters:
would cause the following SQL query to be executed:
Successful exploitation of this vulnerability can result in an attacker achieving SQL injection, which could result in data manipulation, denial of service, or, in the worst case, remote code execution.
Proof of Concept
Timeline
- July 01, 2026: Pellera reports the vulnerabilities to Delta Electronics, using VulnCheck as an intermediary.
- July 08, 2026: VulnCheck reports these vulnerabilities to Delta Electronics.
- July 24, 2026: VulnCheck provides a preliminary security advisory from Delta Electronics. Pellera responds.
- September 25, 2026: VulnCheck reports to Pellera that Delta Electronics has released an advisory addressing these vulnerabilities and assigned them to CVE-2026-78308, CVE-2026-78309, CVE-2026-78310, CVE-2026-78311, CVE-2026-78312, and CVE-2026-78313.
