4276 articles
4276 ARTICLES
Elastic Security Labs tracks REF6045, an active operator-assisted banking fraud operation targeting customers of Mexican banks, fintech, payment processors, and cryptocurrency exchanges.
Learn how to balance control and security using the four stages of Auth0 customization, from standard Universal Login to embedded authentication.
A cybercrime campaign combined a loader-as-a-service framework and DLL sideloading via a Go-compiled fake MpClient.dll, a novel evasion layer combination. The post Vidar Stealer Unmasked: Code Signing Abuse, Go Loaders and File Inflation appeared first on Unit 42.
The new OMB logging directive raises the bar on log collection and explicitly ties every maturity milestone to how well agencies know what’s on their networks. Learn why asset visibility is the first problem to solve. Key takeaways M-26-14 rescinds M-21-31 and replaces blanket data-retention mandates with a five-element logging maturity model (levels 0-4) that agencies must progress through on a strict timeline after CISA publishes the logging reference architecture (LRA). Every maturity level is gated by inventory visibility. Specifically, agencies must demonstrate 70%, 80%, 90%, and 95% IT/OT/IoT asset capture at levels 1 through 4, respectively. After all, you can’t claim log coverage for assets you haven’t discovered. OT and IoT devices are explicitly in scope, including systems without native logging capability. This inclusion makes passive asset discovery tools a necessity rather than an add-on. The clock starts when CISA publishes the LRA within 90 days of the memo. Agencies that close asset-inventory gaps now will be positioned to hit the required deadlines, such as reaching level 1 in 120 days and level 3 in 321 days. You can’t log what you can’t see, and you can’t measure logging maturity against an incomplete inventory On May 22, the U.S. Office of Management and Budget (OMB) Director Russell Vought issued Memorandum M-26-14, titled “Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats.” The directive rescinds M-21-31 and replaces it with a risk-based, prioritized logging framework designed to be both operationally achievable and aligned with today’s threat landscape. For federal cybersecurity leaders, M-26-14 represents a meaningful shift away from blanket data retention mandates and toward measurable, outcome-driven logging maturity. But hidden within its requirements is a foundational dependency that many agencies will need to address before their logging investments can deliver results: complete asset visibility. What M-26-14 requires, and why it’s different from M-21-31 The memorandum organizes logging around two objectives: Continuous event monitoring (CEM): Real-time log ingestion, anomaly detection, and SOC-driven response. Threat hunting, investigation, response, and forensics (THIRF): Centralized retrieval of historical log data to support post-compromise analysis and recovery. Agencies must achieve these objectives across all information systems, explicitly including internet-of-things (IoT) devices and operational technology (OT) systems, whether owned, operated, or managed by third parties. The memo also establishes a logging maturity model with five levels (0–4) that agencies must progress through on a defined timeline, with milestones measured across five elements: Inventory visibility: What percentage of IT/OT/IoT assets are captured in centralized hardware asset management (HWAM)/ software asset management (SWAM) inventories? Collection coverage: Are logs searchable and retrievable for those assets? Collection operations: Do logs generate actionable, tuned alerts? Data retention: Are logs retained for 6 months (searchable) and 12 months (retrievable)? Log management: Are logs encrypted, access-controlled, and properly retired? Agencies must reach level 1 (Basic) within 120 days, level 2 (Intermediate) within 180 days, and level 3 (Advanced) within 320 days of CISA publishing the logging reference architecture (LRA). A critical detail in the maturity model’s design: Overall maturity is calculated based on the lowest watermark across all five elements (Appendix C footnote 8). For example, an agency that achieves level 3 in collection coverage but only level 1 in inventory visibility gets an overall rating of level 1. There is no averaging. This lowest-watermark principle makes inventory completeness the single most consequential element to address first. The denominator problem: Why incomplete inventories break the maturity model Look closely at the maturity model and a pattern emerges: Inventory completeness gates every level. Level 1 requires 70% of IT/OT/IoT assets captured in a centralized inventory Level 2 requires 80% Level 3 requires 90% Level 4 (Optimal) requires 95% The expansive scope of this OMB mandate — spanning on-premises IT, cloud workloads, identity providers, OT, and IoT — creates an immediate challenge: the denominator problem. Because log collection is measured as a percentage of your total inventory, you can’t claim 80% coverage if you only know about 60% of your assets. This operational gap is typically driven by administrative silos, air-gapped networks, and legacy OT/IoT environments that lack native logging or are unsafe to actively scan. Ultimately, managing visibility across this massive footprint comes down to one simple truth: You can’t write a logging plan for assets you haven’t discovered. How Tenable maps to M-26-14’s requirements Tenable has been embedded in the federal cybersecurity ecosystem as an approved continuous diagnostics and mitigation (CDM) vendor whose technology acts as the vulnerability management backbone for hundreds of civilian agencies, and increasingly as the platform that unifies visibility across IT, OT, and cloud attack surfaces. With M-26-14’s asset inventory requirements front and center, the foundation that Tenable’s technology provides is directly relevant to compliance milestones agencies must now achieve. The mapping below shows how Tenable capabilities correspond to M-26-14’s five maturity elements. – Ground truth for the maturity model: Authoritative asset inventory Tenable One Vulnerability Management and Tenable One OT Exposure provide continuous, comprehensive asset discovery across traditional IT, operational technology, and IoT devices. This inventory serves as the ground truth for agencies to measure their maturity model progress, the denominator against which log collection coverage is calculated. – Already CDM-connected: How Tenable accelerates HWAM/SWAM compliance M-26-14 explicitly directs agencies to use CDM, HWAM, and SWAM data to validate log coverage (Appendix B, Requirement 4). As an established primary data source for federal CDM dashboards, Tenable eliminates the need for new data collection by pre-packing and reporting the inventory details M-26-14 requires. – The Tenable solution: A phased approach to full visibility Standard IT scanners can crash fragile OT equipment like programmable logic controllers (PLCs). To meet M-26-14 requirements safely, Tenable offers a tiered approach: Phase 1: Baseline (Level 1): If you’re starting from scratch, use the OT Recon scan policy in Tenable Security Center or Tenable One Vulnerability Management. It uses “Safe Active Querying” with native industrial protocols to discover hardware and firmware details without downtime, helping you reach the 70% Level 1 baseline. Phase 2: Optimal Maturity (Level 4): To hit the 95% asset visibility threshold requiring daily updates, deploy Tenable One OT Exposure. By combining passive network monitoring with safe active querying, you gain persistent, real-time visibility into the deepest parts of the industrial network, bridging the gap to Level 4 maturity. – From inventory to zero trust: Connecting visibility to the CISA Zero Trust Maturity Model Appendix A requires the LRA to align with CISA’s Zero Trust Maturity Model, which defines visibility and analytics as a cross-cutting capability enabling all five zero-trust pillars. The Tenable One Exposure Management Platform provides continuous attack surface visibility and risk quantification that feeds directly into zero trust analytics, connecting vulnerability, identity, and configuration data into a unified exposure view. – Beyond log retrieval: Vulnerability history as forensic evidence When investigating a compromise, security operations center (SOC) analysts need more than logs; they need to know which vulnerabilities existed on affected assets at the time of the incident. Tenable’s scan history and vulnerability timeline provide the forensic context required by Appendix B (items j–k): determining attack vectors, lateral movement paths, and root-cause analysis. – AI-driven prioritization: Focusing logging resources where risk is highest Appendix A explicitly states that the LRA will address using AI to enhance CEM and THIRF capabilities. Tenable Hexa AI and Vulnerability Priority Rating (VPR) deliver AI-driven risk context that helps agencies prioritize which assets and vulnerabilities demand the most urgent logging and monitoring attention, directly supporting the “risk-based, prioritized” philosophy of M-26-14. Beyond inventory: Prioritizing logging resources where threat intelligence risk is highest Establishing an authoritative asset inventory provides the necessary compliance foundation, but it immediately introduces an operational challenge: once an agency uncovers thousands of previously unmanaged IT, OT, and IoT assets, where should security teams begin deploying limited logging resources? The same challenge exists across other parts of the modern attack surface. Cloud workloads, identity providers and directories, web applications, APIs, and containerized environments frequently operate in silos with incomplete inventories and inconsistent visibility. These assets can become equally unknown or poorly logged, creating additional blind spots that M-26-14’s risk-based, prioritized framework requires agencies to close. OMB M-26-14 explicitly shifts federal strategy away from legacy, blanket data -retention mandates and toward a “risk-based, prioritized” logging philosophy. However, the directive does not prescribe a formula for that prioritization. Leaving agencies to manually identify high-value assets (HVAs) and determine logging priorities across complex hybrid IT/OT/cloud/identity environments creates compliance bottlenecks. This is where asset discovery must transition into unified exposure management and threat intelligence. Tenable doesn’t just establish what is deployed on the network; Tenable One delivers continuous discovery, contextual risk scoring (including external exposure and business criticality), and real-time vulnerability intelligence across the entire attack surface — IT, OT, IoT, cloud, identity, web apps, and containers. By continuously cross-referencing all assets with active threat telemetry and exposure context, agencies can instantly identify which systems — regardless of where they reside — are currently being targeted or represent the highest risk. Instead of treating every newly discovered asset with equal urgency, security leaders can use Tenable One’s exposure intelligence to focus CEM and log collection capabilities where the threat and business impact are highest. This directly answers the “what to log first” dilemma while supporting the risk-based, prioritized philosophy of M-26-14. The pre-LRA window: What agencies should do before the clock starts M-26-14’s timelines are aggressive. Once CISA publishes the LRA (within 90 days of the memo), the clock starts: Milestone Deadline Submit Agency Logging Plan 90 days after LRA Achieve Level 1 (Basic) 120 days after LRA Achieve Level 2 (Intermediate) 180 days after LRA Achieve Level 3 (Advanced) 320 days after LRA Where is Level 4? While Level 4 (“Optimal”) represents the highest tier in the five-level maturity framework, OMB M-26-14 does not prescribe a strict day-count deadline for it. Instead, it serves as the ultimate target for continuous operational excellence that agencies build toward once the rigid Level 1 through 3 milestones are secured. Agencies should use the time between now and LRA publication to: Audit asset inventory completeness. Can you account for 70% of IT/OT/IoT assets today? 80%? If not, close the gap now; this is the prerequisite for everything else. Validate log coverage against known assets. Use existing HWAM/SWAM and CDM data to identify systems without adequate logging. Assess OT/IoT blind spots. These environments are explicitly in -scope and often the least visible. Passive discovery tools can illuminate what’s deployed without operational risk. Map existing capabilities to the maturity model. Understand where you stand at, say, Level 0 vs. Level 1 across all five elements, then prioritize the gaps that block progression. Logging maturity starts with knowing what you have M-26-14 makes logging maturity measurable, and it makes asset visibility the foundation of that measurement. Every percentage point of maturity progression, from Level 0 to Level 4, is anchored to how completely an agency knows its IT, OT, and IoT attack surface. Agencies that invest in comprehensive, continuous asset discovery across IT, OT, and IoT will be positioned to meet the memo’s timelines. Those that don’t will struggle to demonstrate the coverage percentages the maturity model demands. The question is whether you know what’s missing from your SIEM logs, and whether you can prove it. Don’t wait for the clock to start: Secure your OMB M-26-14 foundation now The timelines imposed by OMB M-26-14 are aggressive, and the moment CISA publishes the LRA, the compliance clock moves fast. Because overall maturity is tied directly to your lowest-performing element, you cannot afford to let an incomplete asset inventory hold your entire cybersecurity scoring hostage. The message of M-26-14 is clear: you can’t log what you can’t see. Use the pre-LRA window to find your blind spots, build an authoritative inventory, and ensure your team is positioned to succeed. Ready to close your asset visibility gaps and jumpstart your path to Level 4 maturity? Contact the Tenable Federal Team today to schedule an asset visibility assessment.
With the introduction of models that require data sharing with third-party providers—such as Claude Fable 5—organizations need a way to centrally enforce data retention policies. Amazon Bedrock gives you control over whether your prompts and model outputs are retained after an inference request completes. You might need a way to enforce your retention settings across
AI agents are changing how software gets built, but the infrastructure around them hasn’t caught up. Agents burn through tokens on noise. They take actions they shouldn’t. Context evaporates between releases. And most delivery pipelines were never designed for the pace and volume of agentic development. On June 11th we brought together developers in San
While this repository vector is not new, researchers have uncovered a new twist for exploiting trusted metrics to hide malicious code.
Key Takeaways Qualys is a launch partner in Cisco Cloud Control Studio, Cisco’s new unified platform for agentic IT operations. Joint customers can access Qualys intelligence Unified Asset Inventory, TruRisk Prioritized Findings, and orchestrate remediation workflows directly within Cisco’s AI Canvas environment. The integration is powered by Model Context Protocol (MCP) via Cisco Cloud Control
CISA has added one new vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog, based on evidence of active exploitation. CVE-2026-48282 Adobe ColdFusion Path Traversal Vulnerability This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise. Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. BOD 26-04 reinforces the importance of the KEV Catalog and requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria. Aware of an exploited vulnerability not currently listed in the KEV Catalog? Submit it for potential addition through CISA’s KEV Nomination Form. Potential KEV additions must have a CVE ID, evidence of exploitation, and clear mitigation guidance.
View CSAF Summary Hitachi Energy is aware of a buffer overflow vulnerability that affects e-mesh EMS product versions listed in this document. Successful exploitation of this vulnerability could lead to a buffer overflow condition, potentially resulting in application outages (denial of service) and possible arbitrary code execution. Please refer to the Recommended Immediate Actions for information about the mitigation/remediation. The following versions of Hitachi Energy e-mesh EMS are affected: Hitachi Energy e-mesh EMS 4.1.6, 4.4.2, 4.7.0 CVSS Vendor Equipment Vulnerabilities v3 8.1 Hitachi Energy Hitachi Energy e-mesh EMS Heap-based Buffer Overflow Background Critical Infrastructure Sectors: Energy Countries/Areas Deployed: Worldwide Company Headquarters Location: Switzerland Vulnerabilities Expand All + CVE-2026-42945 NGINX Plus and NGINX Open Source used in e-mesh EMS have a vulnerability in the ngx_http_rewrite_module module. This vulnerability exists when the rewrite directive is followed by a rewrite, if, or set directive and an unnamed Perl-Compatible Regular Expression (PCRE) capture (for example, $1, $2) with a replacement string that includes a question mark (?). An unauthenticated attacker along with conditions beyond its control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. e-mesh EMS versions using NGINX v1.30.0 and below are affected. View CVE Details Affected Products Hitachi Energy e-mesh EMS Vendor: Hitachi Energy Product Version: e-mesh EMS versions 4.1.6, e-mesh EMS versions 4.4.2, e-mesh EMS versions 4.7.0 Product Status: known_affected Remediations Vendor fix Apply hotfix for respective e-mesh EMS versions to update NGINX to either v1.30.2 or latest Mitigation Ensure rewrite configuration does not contain “?” to replace unnamed captures, and ensure ASLR is set to active (value=2) across all deployment targets covering all 3 versions. Mitigation Underlying Ubuntu Server 20.04 LTS is End of Life. For e-mesh EMS versions 4.1.6/4.4.2 using Ubuntu 20.04 LTS, upgrade to Ubuntu Server 22.04, or 24.04, or activate Ubuntu Pro/ESM as an interim measure. Relevant CWE: CWE-122 Heap-based Buffer Overflow Metrics CVSS Version Base Score Base Severity Vector String 3.1 8.1 HIGH CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H 4.0 9.2 CRITICAL CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N Acknowledgments Hitachi Energy Internal Team Notice The information in this document is subject to change without notice and should not be construed as a commitment by Hitachi Energy. Hitachi Energy provides no warranty, express or implied, including warranties of merchantability and fitness for a particular purpose, for the information contained in this document, and assumes no responsibility for any errors that may appear in this document. In no event shall Hitachi Energy or any of its suppliers be liable for direct, indirect, special, incidental or consequential damages of any nature or kind arising from the use of this document, or from the use of any hardware or software described in this document, even if Hitachi Energy or its suppliers have been advised of the possibility of such damages. This document and parts hereof must not be reproduced or copied without written permission from Hitachi Energy and the contents hereof must not be imparted to a third party nor used for any unauthorized purpose. All rights to registrations and trademarks reside with their respective owners. Support For additional information and support please contact your product provider or Hitachi Energy service organization. For contact information, see https://www.hitachienergy.com/contact-us/ for Hitachi Energy contact-centers. General Mitigation Factors Recommended security practices and firewall configurations can help protect a process control network from attacks that originate from outside the network. Such practices include that process control systems are physically protected from direct access by unauthorized personnel, have no direct connections to the Internet, and are separated from other networks by means of a firewall system that has a minimal number of ports exposed, and others that have to be evaluated case by case. Process control systems should not be used for Internet surfing, instant messaging, or receiving e-mails. Portable computers and removable storage media should be carefully scanned for viruses before they are connected to a control system. Proper password policies and processes should be followed. Additional information on Industrial Control Systems Cybersecurity Best Practices can be found in the Hitachi Energy “Industrial Control Systems Cybersecurity Best Practices” Cybersecurity Notification. [1] SSVC SSVCv2/E:N/A:N/2026-06-29T17:00:59Z/ Legal Notice and Terms of Use This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy). Recommended Practices CISA recommends users take defensive measures to minimize the exploitation risk of these vulnerabilities. Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet. Locate control system networks and remote devices behind firewalls and isolate them from business networks. When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures. CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies. CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies. Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents. Advisory Conversion Disclaimer This ICSA is a verbatim republication of Hitachi Energy PSIRT 8DBD000253 from a direct conversion of the vendor’s Common Security Advisory Framework (CSAF) advisory. This is republished to CISA’s website as a means of increasing visibility and is provided “as-is” for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Hitachi Energy PSIRT directly for any questions regarding this advisory. Revision History Initial Release Date: 2026-06-30 Date Revision Summary 2026-06-30 1 Initial public release 2026-07-07 2 Initial CISA Republication of Hitachi Energy PSIRT 8DBD000253 advisory Legal Notice and Terms of Use
View CSAF Summary Hitachi Energy is aware of insecure HTTP transmission vulnerability in PROMOD V product versions listed in this document. This vulnerability could allow attackers to intercept or manipulate sensitive data in transit, potentially leading to credential theft, session hijacking, or unauthorized access. The following versions of Hitachi Energy PROMOD V are affected: PROMOD V vers:PROMOD_V/<=1.0.10 CVSS Vendor Equipment Vulnerabilities v3 7.1 Hitachi Energy Hitachi Energy PROMOD V Reliance on HTTP instead of HTTPS Background Critical Infrastructure Sectors: Energy Countries/Areas Deployed: Worldwide Company Headquarters Location: Switzerland Vulnerabilities Expand All + CVE-2026-10763 PROMOD V is using insecure HTTP communication instead of HTTPS. The vulnerability is due to the lack of HTTPS support from 3rd party Digipede server. View CVE Details Affected Products Hitachi Energy PROMOD V Vendor: Hitachi Energy Product Version: PROMOD V versions 1.0.10 and prior Product Status: known_affected Remediations Vendor fix Upgrade to version 1.0.11 and enable HTTPS on Digipede server. [2] Refer to “1.0.11 PROMOD V User Guide”, Section 2 Essential Skills->Running PROMOD V->Digipede Grid. Alternatively, refer to the same section in the online help contained in the application. Mitigation Apply general mitigation factors Relevant CWE: CWE-1428 Reliance on HTTP instead of HTTPS Metrics CVSS Version Base Score Base Severity Vector String 3.1 7.1 HIGH CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N 4.0 7 HIGH CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N Acknowledgments Hitachi Energy Internal Team Notice The information in this document is subject to change without notice and should not be construed as a commitment by Hitachi Energy. Hitachi Energy provides no warranty, express or implied, including warranties of merchantability and fitness for a particular purpose, for the information contained in this document, and assumes no responsibility for any errors that may appear in this document. In no event shall Hitachi Energy or any of its suppliers be liable for direct, indirect, special, incidental or consequential damages of any nature or kind arising from the use of this document, or from the use of any hardware or software described in this document, even if Hitachi Energy or its suppliers have been advised of the possibility of such damages. This document and parts hereof must not be reproduced or copied without written permission from Hitachi Energy and the contents hereof must not be imparted to a third party nor used for any unauthorized purpose. All rights to registrations and trademarks reside with their respective owners. Support For additional information and support please contact your product provider or Hitachi Energy service organization. For contact information, see https://www.hitachienergy.com/contact-us/ for Hitachi Energy contact-centers. General Mitigation Factors Recommended security practices and firewall configurations can help protect a process control network from attacks that originate from outside the network. Such practices include that process control systems are physically protected from direct access by unauthorized personnel, have no direct connections to the Internet, and are separated from other networks by means of a firewall system that has a minimal number of ports exposed, and others that have to be evaluated case by case. Process control systems should not be used for Internet surfing, instant messaging, or receiving e-mails. Portable computers and removable storage media should be carefully scanned for viruses before they are connected to a control system. Proper password policies and processes should be followed. Additional information on Industrial Control Systems Cybersecurity Best Practices can be found in the Hitachi Energy “Industrial Control Systems Cybersecurity Best Practices” Cybersecurity Notification. [1] SSVC SSVCv2/E:N/A:N/2026-06-29T12:01:59Z/ Legal Notice and Terms of Use This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy). Recommended Practices CISA recommends users take defensive measures to minimize the exploitation risk of these vulnerabilities. Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet. Locate control system networks and remote devices behind firewalls and isolate them from business networks. When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures. CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies. CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies. Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents. Advisory Conversion Disclaimer This ICSA is a verbatim republication of Hitachi Energy PSIRT 8DBD000250 from a direct conversion of the vendor’s Common Security Advisory Framework (CSAF) advisory. This is republished to CISA’s website as a means of increasing visibility and is provided “as-is” for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Hitachi Energy PSIRT directly for any questions regarding this advisory. Revision History Initial Release Date: 2026-06-30 Date Revision Summary 2026-06-30 1 Initial public release 2026-07-07 2 Initial CISA Republication of Hitachi Energy PSIRT 8DBD000250 advisory Legal Notice and Terms of Use
View CSAF Summary Successful exploitation of these vulnerabilities could lead to privilege escalation, or result in a denial-of-service attack. The following versions of Hydro-Québec Le Circuit Electrique charging station backend are affected: Le Circuit Electrique charging station backend CVSS Vendor Equipment Vulnerabilities v3 9.8 Hydro-Québec Hydro-Québec Le Circuit Electrique charging station backend Improper Access Control, Improper Restriction of Excessive Authentication Attempts, Insufficient Session Expiration Background Critical Infrastructure Sectors: Transportation Systems Countries/Areas Deployed: Canada Company Headquarters Location: Canada Vulnerabilities Expand All + CVE-2026-20744 The charging station websocket endpoint accepts connections without proper authentication, which could lead to privilege escalation. View CVE Details Affected Products Hydro-Québec Le Circuit Electrique charging station backend Vendor: Hydro-Québec Product Version: Hydro-Québec Le Circuit Electrique charging station backend: <June_2026 Product Status: known_affected Remediations Mitigation Hydro-Québec has updated the majority of charging stations to disable OCPP, mitigating the risk of exploitation. Hydro-Québec has also implemented authentication systems to mitigate the issue for certain charging stations which are still reliant on OCPP. Contact Hydro-Québec with any additional questions. Relevant CWE: CWE-284 Improper Access Control Metrics CVSS Version Base Score Base Severity Vector String 3.1 9.8 CRITICAL CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 4.0 9.3 CRITICAL CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N CVE-2026-42952 Previously, there was no throttling on repeated authentication attempts to the charging station backend, which could allow an attacker to execute a Denial-of-Service attack. View CVE Details Affected Products Hydro-Québec Le Circuit Electrique charging station backend Vendor: Hydro-Québec Product Version: Hydro-Québec Le Circuit Electrique charging station backend: <June_2026 Product Status: known_affected Remediations Mitigation Hydro-Québec has updated the majority of charging stations to disable OCPP, mitigating the risk of exploitation. Hydro-Québec has also implemented authentication systems to mitigate the issue for certain charging stations which are still reliant on OCPP. Contact Hydro-Québec with any additional questions. Relevant CWE: CWE-307 Improper Restriction of Excessive Authentication Attempts Metrics CVSS Version Base Score Base Severity Vector String 3.1 7.5 HIGH CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H 4.0 8.7 HIGH CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N CVE-2026-44383 Multiple connections to the backend using the same charging station ID are allowed, which could allow an attacker to deploy multiple instances of malicious OCPP clients to overwhelm the backend. View CVE Details Affected Products Hydro-Québec Le Circuit Electrique charging station backend Vendor: Hydro-Québec Product Version: Hydro-Québec Le Circuit Electrique charging station backend: <June_2026 Product Status: known_affected Remediations Mitigation Hydro-Québec has updated the majority of charging stations to disable OCPP, mitigating the risk of exploitation. Hydro-Québec has also implemented authentication systems to mitigate the issue for certain charging stations which are still reliant on OCPP. Contact Hydro-Québec with any additional questions. Relevant CWE: CWE-613 Insufficient Session Expiration Metrics CVSS Version Base Score Base Severity Vector String 3.1 7.5 HIGH CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H 4.0 8.7 HIGH CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N Acknowledgments An anonymous researcher reported these vulnerabilities to CISA Legal Notice and Terms of Use This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy). Recommended Practices CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities. Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet. Locate control system networks and remote devices behind firewalls and isolating them from business networks. When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures. CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies. CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies. Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents. No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time. Revision History Initial Release Date: 2026-07-07 Date Revision Summary 2026-07-07 1 Initial Publication Legal Notice and Terms of Use