The cyberattack disclosed by CenterPoint Energy is an important reminder that serious incidents affecting critical-infrastructure organisations do not always involve ransomware, operational disruption or attacks against industrial control systems. CenterPoint has confirmed that an unauthorized third party obtained personal information relating to a portion of its customers through an external-facing system, while a threat actor separately claimed to have stolen approximately 7.49 million customer records containing names, phone numbers, service and billing addresses, account numbers, billing amounts and partial Social Security numbers. CenterPoint has not yet confirmed the attacker's figures or the specific categories of data affected, so those details should continue to be treated as allegations until the investigation is complete, but the company's SEC filing establishes the central fact that customer information was indeed obtained by an unauthorized party. The incident therefore deserves attention not because electricity or gas delivery was interrupted, but because it demonstrates how digital systems surrounding critical infrastructure can expose millions of customers even while the physical service itself continues functioning normally.

The alleged attack method is particularly instructive because the threat actor claims the data was extracted by iterating through millions of identifiers exposed through a public API rather than by deploying ransomware or exploiting some spectacular zero-day vulnerability. According to the attacker's account, the external API lacked sufficient rate limiting, web application firewall protection and other controls capable of stopping large-scale automated enumeration. If that description is confirmed, the incident would illustrate one of the most basic but frequently underestimated API security problems: an individual request may be completely legitimate while millions of those same requests executed automatically become a data breach. Security therefore cannot evaluate API requests only one at a time; it must also understand the behaviour, volume, sequence and context of requests over time.

This distinction is important because traditional application security often focuses on whether a user is authorised to access a particular endpoint, while attackers increasingly look for ways to abuse legitimate functionality at scale. An API that returns customer information when supplied with a valid identifier may be behaving exactly as designed from the perspective of a single transaction, yet if identifiers are predictable or enumerable, an attacker may be able to systematically retrieve records belonging to thousands or millions of other customers. Strong API security therefore requires object-level authorisation, unpredictable identifiers where appropriate, rate limiting, automated abuse detection, behavioural monitoring and restrictions on how much information a single session, account or network source can retrieve within a given period.

The CenterPoint incident also highlights why Broken Object Level Authorization, often referred to as BOLA or IDOR-style exposure, remains one of the most serious risks in modern API environments. Developers can easily assume that possession of an identifier implies permission to retrieve the associated object, particularly when the application was originally designed around internal workflows or trusted clients. Attackers have no such assumption and will test whether changing a number, UUID or parameter allows them to access another user's record. When millions of customer objects are available behind the same API pattern, a small authorisation mistake can become a mass data exposure event rather than an isolated privacy issue.

Rate limiting deserves particular attention because it is often treated as a performance or availability feature rather than a security control. In reality, effective rate limiting can substantially increase the cost and visibility of automated data harvesting. A legitimate customer may need to retrieve a handful of records during a normal session, while an attacker attempting to enumerate millions of customer IDs exhibits a completely different behavioural pattern. Security controls should be able to identify unusually high request volumes, sequential identifier access, excessive failed object lookups and sudden changes in request velocity, then throttle or block that activity before large-scale extraction is completed. Allowing an external client to retrieve millions of records without triggering intervention represents not simply a capacity problem but a failure to recognise abusive behaviour.

The alleged lack of web application firewall protection is equally significant, although a WAF should never be regarded as a substitute for proper API authorization. Web application and API protection technologies can help identify automated enumeration, suspicious request patterns, known attack payloads and abusive clients, but the strongest defence remains ensuring that the backend itself verifies whether the requesting identity is entitled to access the requested object. Security architecture becomes fragile when it depends entirely on a perimeter control to compensate for weaknesses in application logic. If an API exposes sensitive customer information, access control should remain effective even if the request reaches the application directly.

The incident also demonstrates why organisations need comprehensive inventories of external-facing APIs. Many enterprises maintain good visibility into internet-facing websites and VPN gateways but have a far less complete understanding of APIs created for mobile applications, customer portals, third-party integrations and legacy services. These endpoints can remain operational for years, sometimes after the original developers or business owners have moved on, while continuing to expose sensitive information. Attackers actively discover and test such interfaces because APIs provide structured, machine-readable data and are therefore ideal targets for automation. An undocumented or forgotten API can effectively become a high-speed data extraction interface available to anyone who understands its request structure.

For utilities, this is especially important because customer records can contain information valuable for fraud, impersonation and highly targeted social engineering. Names, addresses, phone numbers, billing information, account identifiers and partial Social Security numbers can potentially be combined to construct convincing phishing messages or support attempts to impersonate customers during interactions with financial institutions or service providers. Even when passwords are not exposed, contextual personal information significantly improves an attacker's ability to make fraudulent communications appear legitimate. A criminal who knows someone's utility provider, service address, approximate billing amount and account details can create a far more convincing message than one relying on generic phishing language.

Utility-related information can also reveal sensitive patterns about individuals and households. Service addresses identify where customers live or operate businesses, while billing and account information can provide additional context about customer relationships. This means the consequences of the incident should not be evaluated solely by asking whether full Social Security numbers or payment card data were exposed. Modern identity attacks frequently rely on combinations of individually modest data points that become powerful when aggregated, and attackers routinely correlate information from multiple breaches to create increasingly complete profiles of potential victims.

The fact that CenterPoint's electricity and natural gas operations remained unaffected is nevertheless important and should not be understated. Cyberattacks against utility companies naturally raise concerns about service disruption and critical infrastructure resilience, but CenterPoint has stated that electric and gas delivery remained operational and undisrupted. This suggests that the incident, based on currently available information, affected the company's customer-facing digital environment rather than operational technology controlling physical energy delivery. The distinction matters because cybersecurity reporting should separate confirmed impact from imagined worst-case scenarios, particularly when critical infrastructure is involved.

At the same time, the absence of an operational outage does not make the incident minor. Critical-infrastructure security includes protecting customer identities and business systems as well as maintaining physical service availability. An organisation can successfully keep electricity flowing while simultaneously suffering a serious confidentiality failure affecting millions of people. The three traditional cybersecurity objectives of confidentiality, integrity and availability remain equally relevant: maintaining availability of power does not compensate customers whose personal data may have been exposed, just as protecting customer information would not compensate for an extended outage.

The attack also demonstrates the importance of separating customer-facing systems from critical operational environments. CenterPoint's statement that energy delivery was unaffected suggests that operational systems were not disrupted by the incident, which is exactly the outcome segmentation is intended to support. External web applications, customer portals and APIs necessarily face the internet and therefore carry greater exposure, while operational technology should remain strongly separated from those environments through network segmentation, access controls and tightly governed communication paths. An organisation should assume that an internet-facing application may eventually be compromised and design the architecture so that such compromise cannot easily propagate into systems controlling physical operations.

The company's response also provides a reminder about the role of incident detection. CenterPoint began its investigation after becoming aware of an online post in which a third party claimed to possess customer information, rather than publicly stating that internal monitoring had detected the data extraction as it occurred. This raises an important question for every organisation operating large APIs: would security systems recognise an attacker methodically retrieving millions of records before the attacker announced the breach publicly? Data-exfiltration detection should ideally happen while information is leaving the environment rather than after the stolen dataset appears on an underground forum or public platform.

API monitoring therefore needs to extend beyond conventional attack signatures. A request can be syntactically valid, contain no malicious payload and return an ordinary HTTP 200 response while still being part of an attack. Security analytics should evaluate how many records an identity or source has accessed, whether identifiers are being queried sequentially, whether requests match expected customer behaviour and whether unusually large volumes of sensitive information are moving through an endpoint. This type of contextual monitoring is especially important for attacks that abuse legitimate application functionality because there may be no traditional exploit signature for a firewall or intrusion prevention system to detect.

Another important lesson concerns data minimisation. APIs should return only the information required for the specific business function being performed. If a customer-facing endpoint needs to display a service address, there may be no reason for the same response to include other identity or billing attributes. Reducing the amount of information returned by each request can significantly reduce the impact of an authorization or enumeration flaw. Data minimisation is therefore not simply a privacy principle but a practical security control: information that an application never exposes cannot be harvested through that application.

Organisations should also reconsider how identifiers are designed and exposed. Sequential numeric identifiers make automated enumeration considerably easier because an attacker can simply increase or decrease the number until additional valid records are discovered. Randomised identifiers do not replace authorization, but they can make blind enumeration more difficult and increase the attacker's workload. The correct model combines strong object-level permission checks with non-predictable identifiers, rate limiting, anomaly detection and logging rather than relying on any one measure alone.

The incident has already triggered proposed class-action lawsuits, demonstrating how quickly cybersecurity failures can turn into legal and regulatory exposure. The cost of a breach therefore extends beyond technical remediation and customer notification to include investigation expenses, potential litigation, regulatory scrutiny, reputational damage and long-term customer support. CenterPoint has stated that it does not currently expect the incident to materially affect its financial condition or results of operations and that it maintains cybersecurity insurance coverage, but the final scope remains under investigation. The broader lesson is that security weaknesses in a seemingly ordinary customer API can ultimately create consequences extending far beyond the development team responsible for that API.

There is also a governance lesson for executive management and boards. Organisations frequently receive reports showing the number of blocked attacks, vulnerabilities patched or security alerts processed, but those metrics do not necessarily answer the more important question of whether sensitive data can be extracted through legitimate interfaces at abnormal scale. Security programmes should therefore include business-level scenarios such as how many customer records one account can access, how quickly an automated client can retrieve them, what controls would detect that behaviour and how rapidly access could be stopped. Testing those questions proactively is considerably cheaper than answering them after millions of records have allegedly been downloaded.

For defenders, the practical response extends beyond simply installing another security product. Organisations should inventory every internet-facing API, classify the information available through each endpoint, enforce object-level authorization, implement adaptive rate limits, monitor unusual access patterns and test APIs specifically for enumeration and business-logic abuse. Sensitive API activity should feed into central logging and security analytics so that abnormal data access can be correlated across identities, addresses, devices and sessions. Development teams should also integrate API security testing into the software lifecycle rather than treating penetration testing as an occasional exercise performed shortly before launch.

The broader cybersecurity lesson from the CenterPoint Energy incident is that attackers do not always need to break systems when they can persuade those systems to hand over information through functionality that already exists. Modern applications expose enormous quantities of structured data through APIs, and automation allows adversaries to transform a seemingly minor authorization or rate-limiting weakness into an industrial-scale extraction operation. Protecting those systems therefore requires security controls capable of understanding not only whether each request is technically permitted but whether the overall behaviour makes sense.

Ultimately, the incident illustrates the difference between protecting infrastructure and protecting the data flowing through it. CenterPoint's electricity and gas services remained operational, yet customer information was still obtained through an external-facing system. Both outcomes matter. As utilities and other critical-infrastructure organisations become increasingly digital, their attack surface now includes mobile applications, customer portals, APIs and cloud services alongside traditional operational networks. Cyber resilience therefore means not only keeping essential services running but also ensuring that the digital interfaces surrounding those services cannot quietly become high-speed channels for extracting the personal information of millions of customers.

CenterPoint Energy disclosed a breach compromising some customers' personal information after an attacker leaked data allegedly stolen from the utility company. [...]

Source: CenterPoint Energy confirms customer data stolen in cyberattack via Bleeping Computer — published 15 Sep 2026.