Overview
Vulnerabilities have been identified in Siemens Gridscale X Prepay that allows unauthenticated username enumeration and enables an attacker to bypass account lock functionality. These issues may permit unauthorized access or prolonged access to protected resources, even after an account has been administratively locked.
Description
Siemens Gridscale X Prepay is a scalable energy management solution for utilities, integrating smart meters and customer payment options. The related vulnerabilities increase the risk of unauthorized actions, data exposure, or misuse of sensitive organizational resources.
CVE-2025-40806 Unauthenticated username enumeration. An attacker may determine the validity of usernames by a response code, allowing the attacker to determine whether a username is valid before authentication occurs. This exposure can facilitate targeted attacks by allowing an adversary to identify valid accounts before attempting further compromise.
CVE-2025-40807 Account lock bypass. An attacker can bypass the intended account lock protection by replaying or modifying previously captured valid responses. The issue appears related to session tokens that remain valid after logout or after an administrative account lock. Because these tokens do not expire immediately, an attacker with access to previously captured network responses can continue access the system despite the account being locked. This scenario is particularly concerning when the attacker is a former employee, insider, or anyone with prior authenticated access who may have retained network captured data or sessions artifacts.
Impact
The complete impact of this vulnerability is not yet known.
Solution
Siemens has released a new version of the Gridscale X Prepay and for version 4.2.1 and below, it is recommended to install the provided security update using the appropriates tools and procedures supplied with the product. Before deployment, all updates should be validated, and installed under the supervision of personnel with approved access within the target environment.
As a general security practice, Siemens also advises protecting network access with suitable controls such as firewalls, network segmentation, and VPNs. Systems should be configured in accordance with Siemens’ operational guidelines to ensure that the devices operate within a secure IT environment.
Acknowledgements
Thank you to the reporter, Kira The Raven Security. This document was written by Michael Bragg.

Overview
An unauthenticated HTTP request can enable telnet which may lead to remote code execution with root-level privileges.
Description
TOTOLINK manufactures routers and other networking equipment designed for small businesses and home implementations. The AX1800 routers are popular with users connecting multiple internet-capable devices.
The TOTOLINK AX1800 routers are missing authentication in /cgi-bin/cstecgi.cgi?action=telnet endpoint may result in arbitrary command execution at the administrative level. This vulnerability is being tracked by CVE-2025-13184.
Impact
The impact options include full access to configuration and filesystems. This level of access would provide an attacker the capability to modify routing DNS routing, intercept traffic, and achieve lateral movement across the local area network. There is a potential for wide area (WAN) network access if router management or telnet becomes externally reachable.
Solution
The CERT/CC is currently unaware of a practical solution to this problem. For complete remediation, a firmware update is necessary.
Mitigation Suggestions

Ensure the web management interface is not exposed to the WAN or any untrusted network. Restrict access to the administrative interface to trusted management hosts only.

Treat the X5000R router as untrusted from a security boundary point of view. Where possible, place it behind a separate firewall or router and avoid using it as the primary edge device.

Block or monitor unexpected traffic to telnet (TCP port 23) on the device. The sudden appearance of an open telnet service on the router is a strong indicator of exploitation.

Acknowledgements
Thanks to the reporter, HackingByDoing. This document was written by Laurie Tyzenhaus.

Overview
PCI Express Integrity and Data Encryption (PCIe IDE), introduced in the PCIe 6.0 standard, provides link-level encryption and integrity protection for data transferred across PCIe connections. Several issues were identified in the IDE specification that could allow an attacker with local access to influence data consumed on the link. The PCIe 6.0 IDE Erratum provides corrective guidance, and firmware and hardware updates are expected to address these concerns.
Description
IDE uses AES-GCM encryption to protect confidentiality, integrity, and replay resistance for traffic between PCIe components. It operates between the transaction layer and the data link layer, providing protection close to the hardware against unauthorized modification of link traffic.
Three specification-level vulnerabilities can, under certain conditions, result in consumption of stale or incorrect data if an attacker is able to craft specific traffic patterns at the PCIe interface:

CVE-2025-9612 – A missing integrity check on a receiving port may allow re-ordering of PCIe traffic, leading the receiver to process stale data.
CVE-2025-9613 – Incomplete flushing of a completion timeout may allow a receiver to accept incorrect data when an attacker injects a packet with a matching tag.
CVE-2025-9614 – Incomplete flushing or re-keying of an IDE stream may result in the receiver consuming stale incorrect data packets.

The PCI-SIG has issued a Draft Engineering Change Notice (D-ECN) titled “IDE TLP Reordering Enhancement” to the Base Specification Rev 7.0. The D-ECN feature will be included in upcoming PCI specifications (Base 6.5 and 7.1) and can also be used in current Base 5.x systems through standard compliance procedures. Hardware and firmware vendors that support PCIe 5.0 IDE should apply these corrections and incorporate the updated test procedures to ensure their implementations are compliant. Because IDE operates at the link layer, operating systems and applications may not detect these conditions directly. Timely firmware distribution through normal supply-chain channels is recommended.
Impact
An attacker with physical or low-level access to the PCIe IDE interface may be able to craft packets that cause the receiver to accept stale or corrupted data, affecting the integrity of the protected link.
Solution
Manufacturers should follow the updated PCIe 6.0 standard and apply the Erratum #1 guidance to their IDE implementations. End users should apply firmware updates provided by their system or component suppliers, especially in environments that rely on IDE to protect sensitive data.
Acknowledgements
These issues were reported by Arie Aharon, Makaram Raghunandan, Scott Constable, and Shalini Sharma to follow proper disclosure procedure. Coordination support was actively provided by Intel and PCI-SIG members. This document was prepared by Vijay Sarvepalli.