CenterPoint Energy: Customer Data Stolen via External-Facing System, Hacker Claims 7.49M Records

"CenterPoint Energy (NYSE: CNP) is a Houston-based utility that delivers electricity and natural gas to roughly 7 million customers in Indiana, Minnesota, Ohio and Texas. In a Form 8-K filed with the SEC on September 14…"

CenterPoint Energy (NYSE: CNP) is a Houston-based utility that delivers electricity and natural gas to roughly 7 million customers in Indiana, Minnesota, Ohio and Texas. In a Form 8-K filed with the SEC on September 14, 2026, it confirmed that "an unauthorized third party obtained personal information relating to a portion of the Company's customers through one of the Company's external-facing systems." The company has not said how many customers were affected or what data was taken. A threat actor using the alias "4d722e4d656f77" claims to have taken about 7.49 million records by scraping an unprotected API, and has published an archive of about 2.5 GB that it says contains the data. CenterPoint has not confirmed the 7.49M figure, the attack method, or whether the leaked data is genuine. Service delivery was not affected.

What Happened

The company's account and the attacker's account overlap only in part.

The company's version (8-K, as reported by Reuters, BleepingComputer, SecurityWeek, CyberInsider and FOX 26): - CenterPoint says it learned of the incident in September from an online post claiming to hold customer data. - It then activated its incident response protocols, brought in third-party cybersecurity experts, and "took steps to further protect" its systems. - It confirmed that personal data for "a portion" of customers was obtained through an external-facing system. - It says it intends to notify affected customers and regulators as required by law. - It said electric and gas delivery "remains operational and undisrupted." According to SecurityWeek, the company does not expect the breach to have a material impact.

The attacker's version: - The actor posted on a cybercrime forum. SecurityPointBreak, citing the monitoring account Dark Web Intelligence, names the forum as BreachForums. - Sources disagree on when the post went up. SecurityPointBreak says September 1. SecurityWeek dates the forum claims to September 12. BleepingComputer says the actor contacted it "earlier this month." - The actor told BleepingComputer it leaked the data because CenterPoint "ignored their messages and treated them as a joke." - SecurityWeek reports the actor also threatened: "next time we won't simply pull data, we'll start attacking the main infrastructure."

Disputed and unverified details: - Breached.Company lists September 14 as both the incident date and the disclosure date. September 14 is the filing date. No source establishes when the intrusion actually took place. - CyberSecureToday reports that CenterPoint found the intrusion by spotting "anomalous query traffic," and that it forced credential resets, deployed WAF monitoring, and confirmed its OT/SCADA networks were isolated. None of this appears in the 8-K language quoted by the outlet-tier sources. Those sources say the company learned of the incident from the attacker's post, not from its own detection. Treat these claims as unverified. - SecurityPointBreak reports that five proposed class actions were filed in federal court before the 8-K, by Shamis & Gentile and Lippe & Associates, on behalf of customers in Indiana, Texas and Minnesota. It also reports that Edelson Lechtzin LLP announced an investigation on September 10. No other source in this set confirms the lawsuits. - History: SecurityWeek notes this is not the first claim against CenterPoint. In 2024 an access broker called AntiBrok3rs named the company as one of several energy targets, and a different actor made data claims a few months later.

What Was Taken

CenterPoint has not disclosed the number of affected customers or the types of data involved. Everything below comes from the attacker's claims, and the reported details vary by source.

Volume: - Most reports use about 7.49M "records." Breached.Company says "files." - SecurityPointBreak adds that the actor claimed 7.49M raw records and 6.73M "filtered" records. That suggests the unique figure is lower, and records do not map one-to-one to individual customers. - For context, the company has about 7M customers. CyberSecureToday gives a different breakdown: 2.7M electric plus 4.7M gas customers, and it adds Louisiana to the service area.

Claimed data fields: - Listed by all reporting sources: names, phone numbers, service and billing addresses, and account numbers. - Billing amounts: BleepingComputer, with billing data also noted by CyberInsider. - Email addresses, plus account and premise identifiers: CyberInsider. - Social Security numbers: BleepingComputer says "partial" SSNs. SecurityPointBreak says the last four digits. - Driver's license numbers: SecurityPointBreak only.

Validity: SecurityWeek could not verify the 2.5 GB archive and notes that hackers often exaggerate. Even so, a confirmed breach combined with a public leak makes phishing and impersonation of utility staff very likely. Partial SSNs plus account numbers are exactly what social engineers use to get past customer-service identity checks.

Why It Matters

Critical infrastructure target: CenterPoint runs electric transmission and distribution plus gas distribution in several states. The data taken so far is IT-side customer data, and no source reports any effect on operational technology. However, the actor's threat to attack "main infrastructure" and the earlier access-broker interest in CenterPoint mean defenders should treat this as a possible first step, not just a one-off leak.
Notification gaps: The company found out from the attacker's post rather than its own monitoring. If the September 1 posting date is correct, the data was public for about two weeks before the 8-K. Enumeration at this scale that goes unnoticed suggests weak API telemetry.
Regulatory and legal exposure: This is another SEC Item 1.05/8.01-era filing where the company describes the incident as non-material. Meanwhile, according to one report, lawyers moved faster than the disclosure.
Low-effort technique: If the actor's account is accurate, this was not an advanced intrusion. It needed only an API that could be queried and had no meaningful controls.

The Attack Technique

CenterPoint has confirmed only that access came through "one of the Company's external-facing systems." It has not named the system, explained how it was abused, or said how long it was exposed.

According to the actor, as reported by BleepingComputer, CyberInsider and SecurityPointBreak: - The data was pulled through a public, company-managed API by iterating through millions of sequential or guessable IDs. This is a classic broken object-level authorization (BOLA/IDOR) pattern. - The endpoint reportedly had no rate limiting, no WAF protection, no protection against automated access, and, per CyberInsider and SecurityPointBreak, inadequate authentication or authorization checks. - CyberSecureToday calls it a customer account portal. It is the only source to name the system type, and it is OTHER-tier.

Until CenterPoint says more, treat this as a plausible account from the attacker, not a confirmed root cause.

What Organizations Should Do

Audit customer-facing APIs for BOLA/IDOR: Every object lookup (account, premise, meter ID) must be authorized against the authenticated session. Never trust an identifier because it is hard to guess, and replace sequential IDs with non-enumerable ones.
Enforce rate limiting and bot controls: Apply per-token, per-IP and per-account throttles, a WAF or API gateway with anomaly scoring, and alerts on high-cardinality ID access from a single client.
Build a complete API inventory: Find undocumented or legacy endpoints, especially mobile and portal backends, and include them in regular external attack-surface testing.
Monitor for your own data: Watch forums and leak sites for your brand. The fact that CenterPoint learned of this from a public post shows how late you can find out otherwise. Make sure attacker contact attempts sent to support or security inboxes are escalated rather than dismissed.
Harden identity checks against leaked data: If the last four SSN digits, account numbers and addresses are exposed, stop treating them as proof of identity in call centres. Move to out-of-band verification.
Treat customer-data breaches as IT/OT risk signals: For utilities, review IT-to-OT segmentation, remote access paths and credentials after any IT-side compromise, particularly when the actor explicitly threatens infrastructure.