CVE-2025-10492: a Java deserialisation flaw in Jasper Report gives attackers remote code execution on Hitachi Energy Ellipse

A Java deserialisation vulnerability in the JasperSoft reporting library gives unauthenticated attackers remote code execution on every version of Hitachi Energy Ellipse through 9.0.50. CISA published advisory ICSA-26-092-03 on 2 April 2026. NVD rates CVE-2025-10492 at CVSS 3.1 9.8: network-accessible, low complexity, no privileges required, no user interaction. The affected sector is Critical Manufacturing. The deployment footprint is worldwide. There is no patch for the community edition of the underlying library.

That last sentence is the one worth reading twice.

What Ellipse is and why it matters

Hitachi Energy Ellipse is an enterprise asset management (EAM) platform used by utilities, mining operations, transport networks and manufacturing plants to manage maintenance schedules, work orders, procurement and regulatory compliance for physical infrastructure. It is not a SCADA controller or a PLC. It is the administrative backbone that sits behind those systems: the software that decides when a turbine gets serviced, which spare parts are ordered and whether a maintenance window has been approved.

Compromising Ellipse does not directly trip a relay or open a valve. It does something arguably worse in a sustained campaign: it gives an attacker visibility into every physical asset an organisation owns, the maintenance state of each one and the workflows that govern their operation. For an adversary conducting pre-positioning in a critical infrastructure environment, these are targeting data of the highest order.

Hitachi Energy, headquartered in Switzerland, is a major supplier to the energy sector globally. Ellipse is deployed across critical manufacturing environments worldwide, according to CISA's advisory. The exact number of installations is not public, but Ellipse has been a fixture in the asset management space for decades, originally developed by Mincom before being acquired by ABB and subsequently by Hitachi Energy.

The vulnerability: CWE-502 in a reporting library

CVE-2025-10492 is a deserialisation-of-untrusted-data vulnerability (CWE-502) in the JasperSoft Library, a third-party Java reporting framework that Ellipse uses for generating custom reports. The flaw allows improper handling of externally supplied data, enabling attackers to execute arbitrary code remotely on systems running the affected library.

Java deserialisation vulnerabilities are a well-understood bug class. The mechanics are familiar: an application accepts a serialised Java object from an untrusted source and deserialises it without adequate validation. If the classpath contains gadget classes that perform dangerous operations during deserialisation (file writes, command execution, JNDI lookups), an attacker can construct a payload that triggers arbitrary code execution the moment the object is deserialised. Tools like ysoserial have made constructing these payloads straightforward for over a decade.

What makes this instance notable is not the novelty of the technique but the context in which it appears. The JasperSoft Library is embedded in Ellipse as a third-party dependency for the custom reporting subsystem. The attack vector is the report loading mechanism itself. An attacker who can submit or influence a Jasper report file gains code execution on the underlying server.

The CVSS 4.0 score assigned by the vendor is 8.7 (High), which requires low privileges. NVD's own CVSS 3.1 assessment is harsher: 9.8 (Critical), with no authentication requirement. The discrepancy likely reflects different assumptions about whether the reporting interface is exposed to unauthenticated users in a default deployment. In practice, the answer depends entirely on how each organisation has configured network segmentation and access controls around its Ellipse instance, which is precisely the kind of assumption that fails in the field.

The blast radius extends well beyond Ellipse

Ellipse is one consumer of the JasperSoft Library. It is not the only one.

According to the NVD configuration data for CVE-2025-10492, the vulnerability affects:

• JasperReports Library Community Edition up to 7.0.3
• JasperReports Library Professional Edition up to 9.0.2
• JasperReports Server up to 9.0.0
• JasperReports IO At-Scale and Professional editions up to 4.0.0
• JasperReports Studio Community Edition up to 7.0.3
• JasperReports Studio Professional Edition up to 9.0.2
• JasperReports Web Studio up to 3.0.1

JasperReports is one of the most widely used open-source reporting engines in the Java ecosystem. It is embedded in enterprise resource planning systems, business intelligence platforms, healthcare record systems and government applications. Any product that bundles an affected version of the library and exposes report loading to user-controlled input inherits the same vulnerability.

The JasperSoft security advisory, published in September 2025 and referenced in the NVD entry, provides remediation guidance for the professional and at-scale editions. But the community forums paint a different picture for users of the community edition, with threads titled "CVE-2025-10492: No fix available after JasperReports upgrade, Community Edition."

This is the structural problem. Commercial customers of JasperSoft (now part of TIBCO, now part of Cloud Software Group) can obtain patched versions. Community edition users, and the products that embed the community edition as a dependency, may have no fix path at all. The vulnerability was published in September 2025. CISA's advisory for its impact on Ellipse arrived in April 2026, seven months later. How many other products embed the same unpatched library and have not yet issued advisories?

The mitigation is not a fix

Hitachi Energy's recommended mitigation, as stated in the CISA advisory, is to "restrict the loading of external custom reports created by end users by allowing only trusted Jasper reports generated by the system administrator."

This is an access control workaround, not a remediation. It reduces the attack surface by limiting who can trigger the vulnerable code path, but it does not remove the vulnerability. If an attacker compromises an administrator account, or if the restriction is improperly configured, or if the "trusted reports" themselves can be manipulated before loading, the deserialisation flaw remains exploitable.

CISA's general mitigation guidance adds the standard recommendations: minimise network exposure for control system devices, place control networks behind firewalls, isolate them from business networks and use VPNs for remote access. These are sound principles that assume a level of network segmentation discipline that many operational environments struggle to maintain.

The deeper issue is the dependency chain. Ellipse does not control the JasperSoft Library. Hitachi Energy cannot patch a third-party library it did not write. The commercial path through Cloud Software Group may eventually produce a patched version that can be integrated into an Ellipse update. But the timeline for that integration, the testing cycle for an OT product, the change management process in a critical manufacturing environment: all of it introduces lag measured in months, not days.

A pattern in Hitachi Energy advisories

This is not the first time Hitachi Energy products have appeared in CISA ICS advisories in recent months. In March 2026, CISA published ICSA-26-062-03 for vulnerabilities in the Hitachi Energy RTU500 series CMU Firmware, affecting multiple firmware branches. Those vulnerabilities could expose user management information or cause device outages.

Two advisories for different Hitachi Energy product lines in consecutive months does not, by itself, indicate a systemic problem. Every major ICS vendor accumulates advisories. But the pattern is worth monitoring, particularly because the Ellipse vulnerability is inherited from a third-party dependency rather than from Hitachi Energy's own code. Vendors who embed open-source components into OT products inherit the security posture of every dependency they ship.

The OT reporting surface nobody audits

The broader question raised by CVE-2025-10492 is about a class of OT attack surface that receives far less attention than protocol vulnerabilities or PLC firmware bugs: enterprise reporting and business intelligence layers.

Reporting frameworks are designed to process complex data structures and render them into documents. They often support rich input formats: XML, JRXML templates, SQL queries and, in the case of JasperReports, serialised Java objects. They exist at the boundary between the operational data an OT system produces and the business processes that consume it. They are, by design, data-processing engines that accept externally structured input.

In IT environments, this attack surface is well understood. Web application firewalls, sandboxing, input validation and patching cycles provide layers of defence. In OT environments, reporting platforms often run on the same infrastructure as the asset management system, behind the same firewall, with the same set of credentials, on patching cycles measured in quarters or years.

The Jasper Report vulnerability in Ellipse is a concrete example of this gap. The reporting subsystem is not the part of the OT stack that most security teams focus on during assessments. It is not the Modbus endpoint, the OPC UA server or the HMI interface. It is the reporting engine that generates the PDF a maintenance manager opens on Monday morning. And it is the one running an unpatched Java deserialisation vulnerability with a CVSS score of 9.8.

What to do now

Organisations running Hitachi Energy Ellipse 9.0.50 or earlier should implement Hitachi Energy's recommended restriction on custom report loading immediately. Audit which users and service accounts have the ability to load or modify Jasper reports. Review network segmentation to ensure the Ellipse instance is not reachable from untrusted networks.

Beyond Ellipse, any organisation using JasperReports in any capacity should check which version is deployed and whether it falls within the affected ranges. Community edition users should evaluate whether the reporting functionality can be isolated or disabled until a fix is available.

The uncomfortable truth is that many organisations will not know whether they are affected. JasperReports is the kind of dependency that gets bundled into enterprise applications and forgotten. It does not appear in an OT asset inventory. It does not show up in a Nessus scan looking for PLC vulnerabilities. It sits in a lib/ directory on a server that was provisioned seven years ago, quietly deserialising whatever is handed to it.