Exploiting Solar Inverters: From Cloud IDORs to Grid Destabilization

TLDR: Researchers at Black Hat 2025 demonstrated a critical exploit chain targeting solar power management platforms, enabling remote code execution and account takeover across major vendors like SMA, Growatt, and Sungrow. By chaining IDORs to harvest serial numbers with hardcoded MQTT credentials, attackers can gain unauthorized control over inverter fleets. This research highlights the severe security risks of internet-connected operational technology and the potential for large-scale grid disruption.

Solar power is no longer just a residential trend. It is a massive, distributed, and increasingly interconnected component of the global energy grid. As these systems scale, the attack surface has expanded from local hardware to the cloud-based management platforms that monitor and control millions of inverters. The research presented at Black Hat 2025 by the team at Vedere Labs serves as a wake-up call for anyone who assumes these systems are air-gapped or inherently secure.

The Anatomy of the Exploit Chain

The researchers focused on the intersection of cloud-based management platforms and the communication dongles that bridge the gap between physical inverters and the internet. The goal was to determine if an attacker could move from a cloud-based vulnerability to full control over a fleet of devices.

The exploit chain begins with Insecure Direct Object References (IDOR) in the vendor APIs. By querying endpoints like /v1/powerStationService/getPowerStationInfo, the researchers could enumerate power station IDs. Because these IDs are often predictable, an attacker can harvest thousands of valid serial numbers for communication dongles.

Once the serial numbers are in hand, the next step involves hardcoded credentials found in the firmware of the communication dongles. Specifically, the researchers identified CVE-2024-50692, which allows an attacker to authenticate to the MQTT broker used by the vendor. With these credentials, an attacker can publish crafted messages to the specific MQTT topics associated with the harvested serial numbers.

The final stage of the chain leverages CVE-2024-50694, a stack-based buffer overflow in the MQTT message handler. By sending a malformed JSON payload to the settime command topic, the researchers achieved remote code execution on the dongle.

Technical Hurdles: The Tensilica Xtensa Architecture

Exploiting the buffer overflow was not a simple matter of appending a NOP sled and a shellcode payload. The dongles run on an ESP32 microcontroller, which utilizes the Tensilica Xtensa architecture. Unlike standard x86 or ARM architectures, Xtensa uses a sliding register window.

The calling convention rotates the register window, meaning the return address is not stored on the stack in the way a pentester might expect. Instead, it is stored in a specific register. To bypass this, the researchers had to carefully craft a payload that accounted for the register window rotation and the specific memory layout of the ESP32.

The stack on the ESP32 is non-executable, which forced the researchers to use return-oriented programming (ROP) to redirect execution to a memcpy gadget. This allowed them to copy their shellcode into an executable RAM area (IRAM). The following snippet illustrates the logic of the vulnerable settime handler:

// Simplified representation of the vulnerable handler
void handle_settime(char *json_payload) {
    char buffer[128];
    // ... extraction of data from JSON ...
    // The size calculation is flawed, leading to a buffer overflow
    memcpy(buffer, extracted_data, calculated_size);
}

If the calculated_size exceeds the 128-byte buffer, the stack frame is corrupted. By precisely controlling the overflow, the researchers could overwrite the saved return address and hijack the control flow.

Real-World Applicability for Pentesters

For those performing security assessments on IoT or industrial control systems, this research provides a blueprint for testing similar cloud-to-device architectures. When testing these platforms, do not stop at the web interface. Look for the underlying communication protocols—often MQTT or CoAP—that the devices use to talk to the cloud.

If you find an API that returns device metadata, check for IDORs. If you find firmware for a communication module, extract it and look for hardcoded secrets. The combination of cloud-side enumeration and device-side exploitation is a powerful pattern that is likely present in many other IoT ecosystems.

Defensive Considerations

Defending against these attacks requires a multi-layered approach. Manufacturers must move away from hardcoded credentials and implement robust authentication for MQTT brokers. Furthermore, they must adopt a secure development lifecycle that includes rigorous fuzzing of message handlers to catch buffer overflows before they reach production.

For operators, the most immediate mitigation is to ensure that these devices are not directly exposed to the internet. Use VPNs or dedicated management networks to isolate the communication dongles. If a device does not need to be reachable from the public internet, it should not be.

The security of our energy infrastructure depends on moving past the "set it and forget it" mentality that has plagued the IoT industry for years. As these systems become more critical, the cost of a single vulnerability increases exponentially. Pentesters and researchers have a vital role in identifying these gaps before they are weaponized by those looking to destabilize the grid. Keep digging into the firmware and the APIs, because the next critical vulnerability is likely sitting in a publicly accessible endpoint, waiting to be found.