Summary
A critical security vulnerability has been identified in the Orca user portal, resulting from the way the portal processes data received from Orca devices. Because the older Orca devices communicate with the Orca server over an unencrypted and unauthenticated HTTP connection on a non-secure port, an attacker can impersonate a legitimate device and inject malicious payloads. This flaw enables the insertion of harmful code (XSS) directly into the Orca user portal, potentially compromising user accounts, exposing sensitive information, and allowing further unauthorized actions within the portal.
Identifiers
CVE-2026-25599
Vendor: Orca Energy (orcaenergy.eu)
Product: Orca user portal (https://moja.orca.energy) and Orca heat pump (https://si.orcaenergy.eu/en/heat-pump/)
Vulnerability: Missing authentication and clear‑text transmission of data from the heat pumps to the control server, combined with the absence of input validation on aggregated data, can lead to stored XSS that enables theft of cookies from the pump’s web control interface.
CVSS score: 6.3 (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L)
CWE-79: Improper Neutralization of Input During Web Page Generation
CWE-306: Missing authentication
CWE‑319: Cleartext Transmission of Sensitive Information
Affected versions
Orca user portal
The stored XSS vulnerability (CWE-79) has been fully remediated with the release of Orca user portal version 1.19.
Orca heat pump terminals
Older Orca devices that communicate using unencrypted HTTP over a non-secure port are vulnerable to this issue. If your device is more than 5 years old, please contact Orca support to resolve this issue. The portal vulnerability has been remediated.
Legacy terminal information
The legacy terminal where the CWE-306 and CWE-319 were identified is a control unit (terminal) from CAREL, with the following specifications:
- Vendor: CAREL
- Part Number (P/N): PGDT04000F020
- CPU: ARM CPU
- Memory: 256MB DDR2, 128MB Flash
- Operating System: Microsoft Windows CE 6.0
The terminal uses a native proxy application developed by Orca to communicate with the Orca cloud. The SHA256 hash of this application is:
Filename: OrcaDevNativeProxy.exe
SHA256: 51068e96d5cc21002b618c02bd5853520d73cb6451383e4094a70ea055251d5aModern terminal information
Modern Orca terminals, which use secure communication channels based on the WSS (WebSocket Secure) protocol and implement HMAC-based authentication, are not affected by this issue. These devices support encrypted communication and prevent device ID spoofing and ensure message integrity.
Firmware versions
- Legacy terminal firmware: Versions prior to 2.1
- Modern terminal firmware: Versions 2.1 and later
Users can check the firmware version of their terminal by logging into the Orca user portal.
Details
A critical vulnerability was identified in the communication between Orca devices (heat pumps) and the Orca backend server. Communication was performed over plaintext HTTP on a non-secure port, without any encryption (TLS/SSL). Sensitive operational data, including the device identifier, was transmitted without protection (CWE‑319).
When initiating communication, an Orca device transmitted only its device ID. No additional authentication or verification was required by the server. This lack of authentication aligns with CWE‑306, as any client presenting a valid device ID was accepted as legitimate.
Due to this design, a malicious actor could impersonate a legitimate device by crafting a simple script or program that mimicked the communication protocol and reused or guessed an existing device ID. Arbitrary or malicious data could then be sent to the server while appearing to originate from a trusted device.
The server forwarded this data to the Orca user portal at https://moja.orca.energy, where it was displayed to end users. During the period when the stored XSS user portal vulnerability was present, testing demonstrated that injected JavaScript payloads were executed in the victim’s browser, confirming the presence of a stored XSS vulnerability (CWE‑79). This specific XSS issue has since been remediated.
Impact
The identified vulnerabilities have significant security implications for both end users and the Orca platform. Due to the lack of encryption and authentication, an attacker could impersonate a legitimate device and inject arbitrary data into the Orca backend. In the period when the stored XSS vulnerability was present, this allowed malicious payloads to be executed in the browsers of authenticated users, enabling theft of session cookies and unauthorized access to user accounts.
Unauthorized access to an Orca account could result in full remote control of the associated heat pump, including modification of operational parameters, disruption the heat pump’s operational stability and reliability. Such actions could lead to discomfort, increased energy consumption, or potential damage to the device.
Beyond direct device manipulation, the ability to impersonate devices and inject persistent data into the user portal undermines the integrity of the platform’s communication model. Attackers could exploit this to conduct targeted attacks against users, compromise additional accounts, or use the platform as a vector for broader malicious activity.
The combination of plaintext communication, missing authentication, and previously present stored XSS created a high‑risk scenario in which both user safety and system reliability were exposed to potential compromise.
Exploitation status
There are currently no known exploits in circulation that target this vulnerability.
Mitigation
Architectural Controls for Legacy Devices
The reported vulnerability relates to legacy Orca terminals that communicate using unencrypted HTTP over a non-secure port. These devices are classified as End‑of‑Life (EOL) and have not been installed for approximately five years. Due to hardware and firmware limitations, upgrading these legacy terminals to support encrypted communication (TLS/HTTPS) is not technically feasible.
To reduce exposure, communication from EOL devices is handled through a dedicated, physically isolated server environment. This isolation limits the potential impact of traffic interception or device impersonation and prevents such communication from interacting with systems used by newer device generations.
Modern Orca terminals are not affected by this issue. Newer devices use secure communication channels based on the WSS (WebSocket Secure) protocol and implement HMAC‑based authentication, preventing device ID spoofing and ensuring message integrity.
Remediation on the Orca User Portal (moja.orca.energy)
The stored XSS vulnerability identified during testing has been fully remediated. Multiple defensive measures have been deployed to prevent injection, execution, or misuse of data originating from legacy terminals.
The following mitigations are already in production:
- Input Validation and Sanitization -Strict validation and sanitization of all incoming data from terminals have been implemented at the backend layer to prevent malicious payloads from entering the system.
- Secure Output Encoding – Output escaping has been applied to all locations where terminal‑provided data is rendered in the user portal, preventing execution of injected scripts.
- Content Security Policy (CSP) – A restrictive CSP configuration with nonce‑based script and style execution has been deployed. This significantly reduces the attack surface for unauthorized code execution.
- Session Cookie Hardening – Session cookies now include the HttpOnly, Secure, and SameSite=Lax flags, preventing client‑side access to cookies and mitigating session theft attempts.
These measures collectively eliminate the previously exploitable stored XSS vector and strengthen the overall security posture of the user portal.
Options for Users of Legacy Devices
For users who wish to eliminate the risk associated with plaintext communication from EOL terminals, Orca Energija offers the option to upgrade to a newer terminal model compatible with existing Orca heat pumps. Newer terminals provide encrypted communication, strong authentication, and improved long‑term security.
Timeline
- 5 January 2026 – Initial contact of the vulnerability researcher
- 9 January 2026 – Full report of the vulnerability by the researcher
- 14 January 2026 – Vendor formally notified of the vulnerability
- 3 February 2026 – Vendor notified of the CVE assignment
- 9 March 2026 – Vendor fixed the CWE-79 vulnerability
- 17 April 2026 – Advisory published
Acknowledgments
The vulnerability was identified and responsibly disclosed by Tom Kern, SOC Tech Lead at NIL d.o.o., Slovenia, whose analysis enabled the vendor to confirm the issue and implement a fix.
Contact
SI-CERT
ARNES
Tehnološki park 18, 1000 Ljubljana
T: 01 479 88 00
E: info@cert.si