There is a category of breach that produces no alerts, trips no detection rule and leaves no trace of intrusion — because no intrusion occurs. Someone asks a public interface a question it was never meant to answer, and it answers, politely, several million times.
What happened
On 14 September 2026, CenterPoint Energy filed a Form 8-K with the SEC disclosing that it was aware of an online post by a third party claiming to hold a data set containing customer information. CenterPoint is a Houston-based utility serving roughly seven million customers across Indiana, Minnesota, Ohio and Texas.
The route in was an internet-facing company system. According to the attacker's own account, the interface lacked authentication tokens, rate limiting, certificate checks and a web application firewall. They claim to have extracted 7.49 million customer records in JSONL format — names, phone numbers, addresses, account numbers, billing amounts, partial Social Security numbers and driver's licence numbers — and state that a CAPTCHA was the only obstacle that prevented them reaching the full 17.44 million records available.
Two things deserve emphasis, in opposite directions.
The filing is strong evidence. An 8-K is a regulated disclosure with legal consequences for inaccuracy. This is not a vendor press release or a forum boast; the company has acknowledged the event on the record.
The numbers are not. CenterPoint has explicitly declined to confirm the record count, saying it continues to work with outside experts to determine the scope and will notify affected customers and regulators as required. The 7.49 million figure and the data categories come from the attacker. We would not repeat them as established fact, and neither should anyone else — a point the industry got wrong repeatedly this year.
The company stated operations remained undisrupted. The systems controlling electricity and gas delivery were not involved.
Why this kind of breach is so hard to notice
A conventional intrusion leaves evidence: a login from somewhere odd, a privilege escalation, a process that should not be running, an outbound connection to an unfamiliar host. Detection engineering is built on the assumption that something abnormal happens.
An over-permissive API produces none of that. Every request is well-formed. Every response is a 200. The traffic is to a service that is supposed to be reachable, from clients that look like clients. The only tell is volume — and volume is only a signal if someone decided in advance what normal looks like and set a threshold against it.
This is why these cases so often surface not through monitoring but through the attacker's own publicity. The organisation learns about it when it appears on a forum.
The questions this should prompt
Most organisations can list their web applications. Far fewer can list the API endpoints behind them, and fewer still can say what each one returns to an unauthenticated request. The gap tends to open in predictable places:
- An endpoint built for a mobile app, assumed private because the app is the only intended client.
- A lookup used by one internal page that was never meant to be callable directly.
- An integration endpoint for a partner, authenticated by a shared key that was never rotated or scoped.
- Something a vendor stood up during a project, still live after the project ended.
None of these are exotic. They are the ordinary residue of building software over time.
What to actually do
Inventory what is internet-facing, including the parts you did not build. Not just sites — endpoints. Scan your own external footprint the way an attacker would, and include subdomains, staging environments and anything a supplier deployed on your behalf.
Test what each endpoint gives up with no credentials. Strip the token, send the request, read the response. Do it from outside your network. This single exercise finds more than most penetration tests are scoped to cover, and it costs an afternoon.
Rate-limit by default, not by exception. An interface that returns one customer record per request is a lookup. The same interface answering two hundred thousand times is a bulk export. The difference is a threshold someone has to set.
Do not rely on a CAPTCHA as an access control. By the attacker's own account it slowed them down; it did not stop them taking 7.49 million records. CAPTCHA is friction, not authorisation.
Alert on response volume per client. If you log API traffic and nobody reads it, you have the evidence of the breach and none of the benefit. Volume anomalies on a per-identity basis are one of the few detections that work for this class of problem.
Design the response to return less. An endpoint that answers "is this account valid?" does not need to return the account holder's driver's licence number. Over-returning is the most common root cause here and the easiest to fix in code review.
A note on critical infrastructure
Public reporting has been clear that gas and electricity delivery were unaffected, and that distinction matters. The operational technology that runs a grid is a different environment from the customer billing systems that hold personal data, and conflating them produces alarmism that helps nobody.
But the customer side of a utility holds exactly the material that makes identity fraud work: name, address, account number, partial SSN, driver's licence. For the seven million people on the other end, "the lights stayed on" is true and not especially comforting.
The summary
Nothing was hacked, in the sense most people mean. A system that was supposed to be reachable was reachable, and it answered more generously and more often than anyone had thought to check. That is a design and inventory problem rather than a defensive one, which is why it so rarely gets caught by the controls organisations spend the most on.
The fix is unglamorous and cheap relative to the exposure: know what you expose, test what it returns without credentials, and put a limit on how many times it will answer.
Sources
- CenterPoint Energy confirms data breach following claims on hacking forum — Help Net Security
- CenterPoint Energy customers' personal information breached in data incident — ABC13 Houston
- CenterPoint Energy data breach — hackers stole customers' personal data — Cybersecurity News
