Sungrow is one of the leading solar inverter manufacturers worldwide, next to Huawei. As of December 2025, Sungrow has installed over 1000 GW of power electronic converters worldwide, with a large market share in Europe. We have identified a critical vulnerability that allowed for administrative compromise of their management platforms, with destructive results if abused.  

Architectural Overview

Sungrow's user and management platform is called iSolarCloud. At the time of writing, they have four cloud systems accessible from different domains. Each one is responsible for a specific region. Currently, there exists a European, Chinese, Australian and International server. Each only stores the data for the respective region. The disclosed vulnerability affects the business logic of the cloud and therefore exists in all four servers.  

What makes the iSolarCloud unique and more difficult to review from a security perspective is their application layer encryption. They use asymmetric encryption on the application layer during REST calls. Each POST body to the API is encrypted. Additionally, they verify signatures and custom header data on each request. This makes it harder to review, trace and manipulate requests for testing.

Finding The Vulnerability

In the last year we spent a significant amount of time analysing cloud-connected inverter systems with a focus on device communication, mostly done through MQTT. And while we made some critical findings there, we wanted to approach Sungrow differently. Given that both normal user accounts and administrative user accounts share the same management platform, an account takeover or authentication bypass could lead to a dangerous scenario. 

First we focused on the password reset functionality and the “Login By Email Code” service. Unfortunately (or fortunately) they used an aggressive rate limiting that prevented an account takeover through this method. We were also unlucky finding IDOR (Insecure Direct Object Reference) vulnerabilities or missing authorization checks, let alone SQL injections. But this was to be expected given their strong public security posture. Besides the main vulnerability we will talk about in a second, we also found an information disclosure and a reflected cross-site scripting vulnerability on a subdomain (which is out of scope for this article).    

After unsuccessfully trying to bypass the rate limiting, we took a more in-depth look into the login request, which (after decrypting) looks like the following:

{ "user_account": "marlon.starkloff@jakkaru.de", "user_password": "Password123!", "login_type": "1", ... }

There are a few more fields someone can play with, but the most interesting one for us was login type. Mostly because switching to the email code login method set the login type to eight. So there seems to be eight (or more?) different ways to log in. We started iterating through the numbers and when we hit five, we were immediately logged in. Our first thought was we messed something up, like an incorrectly invalidated session. But testing with other accounts revealed that setting the login type to five automatically logged us into the account of the user specified in the user account field. The password field is ignored. This was a critical finding. What made it worse, was the fact that no notification was sent to the user. No login notification by email or similar. We just found a silent authentication bypass that could be escalated to an account takeover using the password reset functionality once logged in. 

Figuring out valid email addresses of administrators was more or less straight forward. One valid method is going up the organisation chain. Because users and organisations are structured hierarchically, a user can see the email and username of their parent organisation. With this information and the shown vulnerability a user can escalate their privileges. The second and more straightforward method that we used was an undisclosed information leak, which revealed email addresses of support and sometimes administrator accounts. 

Impact

Access to the administrative management platform allows complete control of all plants associated with the specific server. An attacker can list, modify, start or stop solar plants, inverter and battery storage systems. They can access all organisations and users registered on the platform. Including management accounts from known German solar distributors like  1KOMMA5° or Enpal. New and custom firmware images can be installed on all devices at an attacker's will, as long as they are connected to the cloud. Sungrow's market share in Germany and Europe reached a critical tipping point, where unauthorized access to these systems through vulnerabilities are a matter of national security and can lead to local blackouts on the whole continent. 

Prevention

Consumers should reconsider the cloud connectivity of their solar systems. If possible, a solar plant should only be connected to the internet to fetch firmware updates. For any other moment in time, it shouldn’t be connected to any cloud. On the other hand, manufacturers should consider splitting user and administrative platforms apart. A user platform should only have the necessary functionalities, that in theory, cannot be exploited to cause widespread damage if compromised.  

Responsible Disclosure

We immediately notified Sungrow regarding the vulnerabilities and within a day they published a patch, hotfixing the issue. A thorough analysis was started to find the root cause and to fix related issues. The communication with the Sungrow PSIRT was great and better than we had experienced with other solar manufacturers in the past.