A now-patched vulnerability in Sungrow’s iSolarCloud management platform could have let an attacker log into any customer’s account without knowing their password, exposing remote control over solar inverters, battery systems, and entire solar plants across Europe, China, Australia, and other regions. The flaw was disclosed by security researchers at Jakkaru and fixed by Sungrow within roughly a day of being reported — but the scope of what it could have enabled makes it worth a closer look.

A Business-Logic Flaw in the Login Process

Sungrow is one of the largest solar inverter manufacturers in the world, with the company reporting more than 870 gigawatts of power electronic converters deployed globally as of June 2025; Jakkaru’s own estimate puts that figure above 1,000 GW today. Its iSolarCloud platform is the remote management layer that lets customers and administrators monitor and control solar assets from anywhere.

Despite the platform’s use of encrypted REST API calls, request signatures, and custom headers — defenses designed to make tampering difficult — Jakkaru’s researchers found a logic error sitting in the authentication flow itself. While reviewing a login parameter called login_type, they discovered that submitting one specific value caused the system to authenticate the account tied to the supplied email address while completely disregarding whatever was entered in the password field. In other words, knowing a target’s email address alone was enough to get into their account.

The flaw was especially dangerous because it left no trace: iSolarCloud did not send an email alert or any other login notification when an account was accessed this way, meaning an intruder could get in, quietly use account-recovery options to lock in longer-term access, and the legitimate owner might never know.

What an Attacker Could Have Done

Jakkaru found that regular customer accounts and administrative accounts lived inside the same shared management environment, which raised the stakes considerably — compromising the right account could mean escalating straight to administrative control over an entire regional cloud deployment. According to the researchers, that level of access would have allowed an attacker to:

• View and modify details of connected solar plants.
• Remotely start or stop inverters and battery storage systems.
• Access registered organizations and user accounts tied to the platform.
• Push custom firmware to cloud-connected devices.

That last capability is the one that should concern grid operators most. A malicious firmware push could alter how a device behaves at a fundamental level, and coordinated action across many compromised systems at once could cause a sudden, simultaneous drop in solar generation — a real concern as inverters take on a bigger share of national energy infrastructure. This goes well beyond a typical data-exposure bug; it’s a pathway to operational disruption of physical energy equipment.

Part of a Recurring Pattern in Solar Infrastructure

This isn’t an isolated incident for the inverter industry. Cybersecurity News has previously reported on a separate study that uncovered 46 distinct flaws spread across major inverter vendors, including weaknesses tied to communication dongles, insecure direct object references, and hard-coded credentials — with Sungrow systems among those implicated. Other reporting has flagged tens of thousands of internet-exposed solar devices, including dashboards and data loggers left reachable directly from the public internet. Taken together, this disclosure reinforces a pattern that security researchers have been warning about for a while: the rapid buildout of distributed solar infrastructure has outpaced the security hardening of the cloud platforms managing it.

Sungrow’s Response and Recommended Next Steps

Jakkaru reported the issue directly to Sungrow’s Product Security Incident Response Team, and the company shipped a hotfix within a day — a response the researchers characterized positively. That said, Sungrow has not published a CVE identifier, a list of affected firmware versions, or a customer-facing patch version number for this specific issue, which makes independent verification harder for asset owners. Solar plant operators and administrators relying on iSolarCloud should take these precautions regardless:

• Confirm that iSolarCloud accounts and connected devices are running current, updated software.
• Change account passwords and enable multi-factor authentication wherever it’s supported.
• Audit user and administrator accounts for old installers or third parties that no longer need access.
• Avoid exposing inverter management interfaces, gateways, or data loggers directly to the public internet.
• Separate administrative tooling from standard customer-facing portals to limit the blast radius of any single compromised account.

As solar capacity continues to scale, incidents like this one are a reminder that the cloud platforms coordinating distributed energy resources deserve the same security scrutiny traditionally reserved for the grid itself.