Mercury Energy NZ API Exposed Customer Data Through Authorisation Bypass

A critical API vulnerability at Mercury Energy New Zealand allowed unauthorised access to potentially hundreds of thousands of customer records before being patched following a tip off by a private security researcher. But how much data was accessible, which clients have had their data compromised, what specific data was accessed and who likely has your data now?

The Mercury Energy API Vulnerability Discovery

The security flaw was discovered by a cybersecurity professional who became suspicious after receiving scam calls that referenced specific details from their Mercury Energy account. Rather than dismissing these as typical phishing attempts, the researcher decided to investigate Mercury Energy’s API infrastructure to understand how scammers might have obtained legitimate customer information.

Advertisement

Technical Details of the Flaw

The vulnerability centered on a fundamental failure in Mercury Energy’s API authorization controls. This API seems to have been used for customers to setup smart home assistant tools such as OPower with Home Assistant, but the security researcher specifically did not specify publically the API to avoid threat actors actively going out and taking advantage of the vulnerability while Mercury Energy IT security engineers worked to patch the API – however it appears Mercury took a long time to acknowledge the concerns as we can see here.

This API appears to have been around for a number of years, so has the API security flaw been around since then with hackers farming your data?

The system failed to properly verify whether API requests were authorised to access specific customer data, effectively allowing anyone with knowledge of the API endpoints to query customer information without authentication. It’s unclear how long this security flaw has been leaking customer data but it could have been years.

This type of vulnerability is classified as a Broken Object Level Authorisation (BOLA) flaw, where the API fails to validate that a user should have access to the specific data object they’re requesting. In Mercury Energy’s case, this meant:

• API endpoints were accessible without proper authentication tokens
• No validation occurred to ensure requesters were authorised for specific customer data
• The system relied on security through obscurity rather than proper access controls
• Customer data could be accessed by manipulating API parameters

Scope of Data Exposure

The compromised API endpoints likely exposed comprehensive customer information including:

• Personal identifiers: Names, addresses, phone numbers
• Account information: Customer account numbers, service addresses
• Billing details: Account balances, payment history, billing addresses
• Service data: Energy usage patterns, tariff information
• Payment / license details – it’s unclear if any payment data or license data was accessed. Given it’s an API it’s unlikely this data would have been accessible.

This represents essentially all customer data maintained in Mercury Energy’s customer relationship management system, making it a complete customer database exposure rather than a limited data leak – if determined.

Evidence of Active Exploitation

The researcher’s investigation was triggered by receiving scam calls where callers possessed accurate Mercury Energy account details that should not have been publicly available. This suggests the vulnerability was being actively exploited by cybercriminals who had discovered the API flaw and were harvesting customer data for fraudulent purposes.

The timing and specificity of the scam calls indicated that:

• Cybercriminals had discovered the API vulnerability independently
• Large-scale data harvesting was likely occurring
• The extracted data was being used immediately for social engineering attacks
• The vulnerability had been exploitable for an unknown period before discovery

Scale of Potential Impact

Mercury Energy serves approximately 500,000 customers across New Zealand, meaning the vulnerability potentially exposed personal and financial information for half a million individuals. The comprehensive nature of the exposed data made this particularly valuable for cybercriminals, as it provided everything needed for convincing impersonation attacks.

The API structure suggested that complete customer database dumps would have been technically feasible, allowing threat actors to:

• Extract entire customer lists with contact information
• Correlate billing and usage data with personal identifiers
• Build detailed profiles for targeted attacks
• Sell comprehensive datasets on criminal marketplaces

Discovery and Disclosure Timeline

The security researcher followed responsible disclosure practices:

1. Initial suspicion: Researcher received scam calls with accurate account details
2. Investigation phase: API testing revealed the authorisation bypass vulnerability
3. Vulnerability confirmation: Researcher verified the scope and impact of the flaw
4. Responsible disclosure: Mercury Energy was notified directly about the security issue – didn’t reply so was posted on Reddit.
5. Slow to react; Initially it would appear Mercury chose to ignore him or at least didn’t seem to take it seriously, until it was posted on Reddit when it became public knowledge
6. Coordinated response: Company worked with researcher to understand and fix the problem
7. Vulnerability patched: Mercury Energy implemented fixes to close the security gap
8. Public awareness: Researcher shared information to warn potentially affected customers
9. Disclosure – Mercury have not publically disclosed anything to customers or the news outlets.

Technical Resolution

Mercury Energy’s response involved implementing proper authorisation controls on their API endpoints. While specific technical details of the fix weren’t disclosed, standard remediation for this type of vulnerability typically includes:

• Implementation of proper authentication requirements for all API endpoints
• Addition of authorisation checks to verify user permissions for specific data requests
• Input validation to prevent parameter manipulation attacks
• Access logging to monitor and detect unauthorised access attempts
• Rate limiting to prevent bulk data extraction

Verification of Fix

The researcher confirmed that Mercury Energy had successfully resolved the vulnerability, indicating that proper testing was conducted to ensure the authorization controls were functioning correctly. This suggests Mercury Energy took the disclosure seriously and implemented comprehensive fixes rather than superficial patches.

Classification and Severity

This vulnerability represents a critical security flaw that would likely receive a high CVSS score due to:

• High impact: Complete customer database exposure
• Low complexity: Simple to exploit once discovered
• No privileges required: Accessible without authentication
• Remote exploitation: Attackable over the internet
• Large scope: Affecting hundreds of thousands of customers

The combination of ease of exploitation and high impact makes this the type of vulnerability that can result in massive data breaches if not promptly addressed.

Root Cause Analysis

The fundamental issue appears to be inadequate security architecture in Mercury Energy’s API design. The vulnerability suggests:

• Design flaw: API was built without proper authorisation frameworks
• Testing gaps: Security testing failed to identify the authorisation bypass
• Architecture review: Insufficient security review of API access controls
• Development practices: Lack of secure coding practices for API development.

Industry Context

This type of API vulnerability is unfortunately common in enterprise systems where:

• Legacy systems are connected to modern API interfaces
• Rapid development prioritises functionality over security
• Internal systems are exposed to external access without proper security controls
• Organisations assume internal network security is sufficient protection.

Mercury Energy’s case demonstrates how fundamental security principles like authorisation and authentication remain critical even as technology evolves.

Conclusion

The Mercury Energy API vulnerability represents a textbook example of broken authorisation controls leading to massive data exposure. While the company responded appropriately once notified, the incident highlights how critical API security has become as organisations increasingly expose internal systems through web interfaces.

The researcher’s responsible disclosure and Mercury Energy’s cooperative response resulted in a rapid fix, but the unknown duration of the vulnerability means customer data was potentially exposed to cybercriminals for an extended period. This case serves as a clear reminder that API security cannot be an afterthought in modern system design.

But how much data has been stolen? We reached out to Mercury to ask. Do they know? If no logs are kept of API calls, we may never know, therefore we have to assume all customer data may have been compromised.