Unauthenticated Servlet Flaws in Hitachi Energy Asset Suite Expose Critical Energy Infrastructure

As reported by CISA in advisory ICSA-26-279-03, Hitachi Energy has disclosed two unauthenticated servlet access vulnerabilities affecting Asset Suite versions 9.9.0 and prior. These flaws — CVE-2026-7395 and CVE-2026-11796 — target critical energy infrastructure deployments worldwide and underscore a persistent and troubling pattern in ICS software: leaving diagnostic and administrative servlets exposed without authentication in production environments.

Vulnerability Summary

Affected Product: Hitachi Energy Asset Suite ≤ 9.9.0Patch Status: Vendor fix available in version 9.9.1 (release pending); mitigations available nowCritical Infrastructure Sector: EnergyDeployment Footprint: Worldwide

Why This Matters

The core issue is deceptively simple: servlets designed for testing or internal administrative functions — HTTPPublishAdapterTestServlet, PropertiesReloadServlet, CacheFlushServlet, MetadataCacheFlushServlet, and ResourceBundleReloadServlet — are accessible without authentication. CVE-2026-7395 is the more dangerous of the two: it allows unauthenticated users to access the HTTPPublishAdapterTestServlet, which was explicitly designed for non-production testing. Through this servlet, an attacker can upload configuration files, leading to information disclosure and integrity compromise. In an energy sector context, that could mean tampering with asset configuration data that feeds operational decisions.

CVE-2026-11796 exposes four additional servlets to unauthenticated access, enabling denial-of-service conditions. While DoS on an asset management platform may seem less severe than configuration tampering, in OT environments, loss of visibility into asset status can delay response to physical incidents and disrupt maintenance workflows.

The vulnerability class here — CWE-306, Missing Authentication for Critical Function — is one of the most recurrent in ICS/OT software. Vendors ship diagnostic tooling that was never meant for production exposure, and operators fail to lock it down during deployment hardening.

Who Is Most at Risk

Shield53 Recommendations

Immediate Actions

• Disable the affected servlets now. At minimum, disable HTTPPublishAdapterTestServlet on all production systems. Evaluate whether PropertiesReloadServlet, CacheFlushServlet, MetadataCacheFlushServlet, and ResourceBundleReloadServlet serve any legitimate production function — if not, disable them as well.
• Restrict network access to the Asset Suite application server via allowlisting at the network layer. Only authorized administrative workstations and dependent systems should reach the application's management interfaces.
• Apply WAF or reverse proxy rules that block requests to the named servlet paths as an interim compensating control until the 9.9.1 patch is available and deployed.
• Plan the upgrade to Asset Suite 9.9.1 as soon as it is released. Track vendor communications for the exact release date and treat this as a priority patch given the energy sector classification.

Detection Guidance

• Monitor web server and application logs for HTTP requests targeting /HTTPPublishAdapterTestServlet, /PropertiesReloadServlet, /CacheFlushServlet, /MetadataCacheFlushServlet, or /ResourceBundleReloadServlet paths
• Alert on any unauthenticated access attempts to these endpoints, especially from non-administrative network ranges
• Review historical logs for evidence of prior exploitation — file upload attempts and repeated cache flush requests are strong indicators

Broader Hardening

• Conduct a full servlet and endpoint inventory across all ICS/OT applications in your environment. Diagnostic and test endpoints should be disabled by default in production.
• Implement OT-specific network segmentation following Purdue Model principles to limit exposure of management platforms.
• Ensure change management processes include security configuration reviews for all new ICS software deployments, not just patching cycles.

These vulnerabilities are a reminder that ICS software hardening does not end at installation. The gap between vendor defaults and production-ready security configuration remains one of the most exploitable surfaces in operational technology environments today.