Remote Firmware Injection in Popular Solar Inverters

Following our findings published last year, which exposed data leaks, including WiFi credentials, location, and energy data in solar inverters from Sunways and APsystems, we now present a critical vulnerability in APsystems inverters: a remote firmware injection that allows for total system compromise.

APsystems Microinverters

APsystems offers a wide range of microinverters, alongside residential and C&I battery storage solutions and monitoring utilities. The EZ1-M is one of the most popular microinverters and is still available through resellers. APsystems also supplied the EZ1-M as a white-label product to Anker, known as the Anker Solix Mi80.

EZ1-M Hardware Analysis

During the drafting of our initial report from last year, we contacted Valentin Conrad from TU Darmstadt, who had dumped the EZ1-M firmware for his master's thesis on microinverter security. He provided us with the opened inverter and firmware for analysis.

The front view highlights the ESP32C2 microcontroller. Its primary function is to collect and transmit energy data to the cloud via MQTT. It also controls whether the inverter feeds electricity into the grid.

The back view reveals a TI C2000 microcontroller, which is connected to the ESP32C2 and controls the gate drivers. These are responsible for the DC-to-AC conversion process. Below the APsystems logo, the text “DS3” can be seen, suggesting the EZ1-M uses the same hardware as the DS3 inverter series.

EZ1-M Firmware Analysis

Using Ghidra to analyze the firmware, we found out the MQTT broker URI being used was data.mqtt.apsystemsema.com:9005. In the function where this string was referenced, we also found two random strings: uh345IeTf)(&*rrr and CCPUsadQQi!@&#$p. Initially, we thought these were the MQTT credentials, but connection attempts were unsuccessful.

Reverse engineering this firmware image was rather challenging, so we tried a novel approach: We extracted the disassembled C code of the MQTT function and utilized Gemini Pro for interpretation. This worked surprisingly well and allowed us to understand the connection process. The authentication mechanism is summarized as follows:

First, the serial number of the device is encrypted using the strings mentioned above. Once for the username and a second time (using the second string) for the password. Afterwards, the encrypted blobs are encoded using Base64 and used as MQTT credentials. 

Given the absence of key negotiation and that the broker only receives the Base64 strings, we presume that the keys are static and identical across all devices. This means an attacker only requires knowledge of the device's serial number to authenticate with the server. While this alone might not be a severe issue if serial numbers were random, they are unfortunately predictable, operating essentially as a counter (e.g., E17000032722, E17000032723, etc.).

EZ1-M MQTT Analysis

Before connecting to the MQTT server, we attempted to locate topic strings within the firmware, but the strings were concatenated and difficult to trace in the disassembled view.

Seeing that the topics were regularly outputted to UART, we bought an ESP32C2 development board and flashed the firmware onto it. This provided us with the topics, which included several interesting ones, especially the OTA topics, indicating a remote firmware update capability.

Once connected to the MQTT server, we checked if we can subscribe and publish to arbitrary topics. This was not possible; access was restricted only to topics associated with the device's authenticated serial number. We were unable to subscribe to arbitrary serial numbers. Also, the server enforces a single-connection policy per serial number. If a device is already connected, an attacker connecting with the same serial number will automatically disconnect the legitimate device, which severely limits the feasibility of our initial attack scenario.

Bypassing The Restrictions

Fortunately, an MQTT feature allows us to bypass both restrictions simultaneously: Retained Messages. A message with the retained flag set to true is delivered instantly and persistently to any client upon connection. This feature can be exploited in the following way:

1. Connect to the MQTT broker, which forces the target inverter to disconnect.

2. Publish a retained OTA update message (for our own serial number).

3. Disconnect, allowing the inverter to automatically reconnect.

The inverter will consume the retained message and initiate the OTA update.

Crafting An OTA Payload

Analysis of the UART log reveals the following structure for an OTA update message:

For successful exploitation, we need to adapt the URL and device ID. The URL must link to a valid ESP32C2 firmware image, which can easily be built locally and must be served over HTTP.

We developed a proof of concept payload designed to change the firmware version visible in the management app to “pwned by jakkaru” and prevent future OTA updates by patching the OTA topic.

Proof-of-Concept Exploitation

Putting everything together, the following proof-of-concept video was created. The top left corner displays the exploit script, the bottom left shows the UART output, and the right side features a real-time recording of the AP EasyPower app displaying the device information.

C2000 Patching

Initially, we were only able to patch the ESP32C2 firmware. However, during testing and monitoring of the UART log, we noticed another OTA payload being transmitted to the development board with a different configuration. The linked firmware was significantly smaller, and the module value in the OTA structure was set to “dsp” instead of “dcm.” Analysis of this binary revealed it was the C2000 firmware being sent for patching. This implies that an attacker could patch the C2000 chip to control the gate drivers, enabling much more severe attack scenarios.

Attack Scenarios

While many attack scenarios are possible, the following list outlines the most feasible attacks:

• Exploiting the inverter as a proxy to pivot into the connected network.
  
  

• Orchestrating a synchronized shutdown of a massive fleet of inverters to disrupt local power grid stability.
  
  

• Joining compromised devices into a network for DDoS attacks.
  
  

• Intentionally corrupting the firmware or hardware logic to destroy the device.
  
  

• Stealing WiFi credentials and other information saved on the device.

Our telemetry scan identified approximately 100,000 accessible and vulnerable EZ1-M units. The total attack surface is likely significantly larger when considering other product lines utilizing the same MQTT broker. We tested additional serial number formats and strongly suspect that other inverters and even the residential battery storage solutions are affected. According to apsystemsema.com, there are approximately 600,000 total installations.

Responsible Disclosure Timeline

14. November 2025 - Notified APsystems about the vulnerability with a 90-day deadline.
21. November 2025 - APsystems estimated 3 months for fixing because a complete infrastructure overhaul was needed. 
16. January 2026 - Reminded APsystems about the disclosure date mid-February. 
18. January 2026 - APsystems requested a disclosure late February because of rollout tests.
4. March 2026 - Disclosure of vulnerabilities.