Sungrow is one of the largest makers of solar inverters in the world, and iSolarCloud is the platform its installations report to and are managed from. Researchers at the German firm Jakkaru found that its login endpoint would authenticate whoever a request named, without checking the password.

The identifier is CVE-2026-107194, scored 9.2, filed as CWE-288 — authentication bypass using an alternate path.

The mechanism

Logins to iSolarCloud carry a login_type field. The documented values do what you would expect: 1 is a normal password login, 8 is a login by emailed code.

Setting it to 5 logged the researcher straight into the account named in the request. In their own description, the password field is ignored.

Three things were needed to use it: a valid target email address, knowledge of the parameter, and the ability to encrypt the request, since Sungrow's REST API uses asymmetric encryption. That last requirement is a real step and most coverage has dropped it — but it is an implementation detail of the client, not a secret, and it does not survive contact with anyone willing to read their own traffic.

Finding the email was not hard either. A user can see the email and username of their parent organisation, which walks the hierarchy upward. Jakkaru also reports a separate, undisclosed information leak that surfaced support and administrator addresses belonging to two large German installers.

All four regional clouds — Europe, China, Australia and International — were affected. It was not a firmware bug in a particular inverter; it was the platform every inverter talks to.

What the account is worth

An ordinary account shows one site. An administrator account was considerably more: Jakkaru lists enumerating and modifying plants, starting and stopping inverters and battery storage, reaching every organisation and registered user, and in some cases installing firmware on connected devices.

The detail with the longest reach is the quietest one. No login notification was sent — no email, nothing. An account taken this way did not announce itself to its owner, so the only record is in logs nobody outside Sungrow could read.

The blackout line is the researcher's, and it is now in the CVE

Here is where this story becomes two stories.

The official MITRE CVE description for CVE-2026-107194 reads, in part, that the flaw potentially leads to "local blackouts on the whole continent" in Europe — with the quotation marks in the record itself.

That phrase comes from the researcher's own write-up, where it appears as an argument about market share: that Sungrow's position in Germany and Europe has reached a point where unauthorised access becomes a question of national security. It is a reasoned opinion. It is not a modelled result, and no grid operator is cited.

A CVE description is the text that propagates. It goes into scanners, dashboards, ticket queues and briefing notes, usually stripped of the context around it. A speculative clause about continental blackouts, wrapped in quotation marks and placed in the field that everything downstream reads as impact, will be repeated far more often than the paragraph it came from.

The flaw is serious without it. A password check that can be skipped on a platform controlling fleets of grid-connected hardware needs no amplification.

What Sungrow says, and the timeline that does not settle

Sungrow's account, via trade coverage, is that it reviewed platform logs for the period the flaw existed and found no evidence that anyone other than the reporting researcher had used it, and no sign of customer data leaks, service interruption or unauthorised manipulation.

The timeline is where accounts diverge. The researcher writes that Sungrow published a patch within a day of being told. Trade reporting gives dated steps instead: reported 22 August, emergency patch 25 August, a follow-up test in mid-September confirming the fix. Public disclosure came in early October, and the CVE was published on 7 October.

Those are not the same story. Three days is still a fast vendor response, and the gap may be the difference between a hotfix and a root-cause fix — but nobody has said so, and we are not going to assume it.

What to do

  • If you operate Sungrow equipment through iSolarCloud, the fix is server-side and already deployed; there is nothing to patch on your own hardware. The question worth asking your installer is whether anything in your account changed between August and now.
  • Treat no login notification as the finding to act on generally. Any platform that manages physical equipment and does not tell an account holder about a new session has removed the one control the account holder has.
  • For fleet operators: ask who in your supply chain can reach your plants through a vendor cloud, and what that vendor's account recovery and notification behaviour actually is.
  • Read a CVE description as a summary written by somebody, not as a measurement.

What is not established

  • Whether the patch came in a day or in three. The researcher and the trade reporting disagree, and neither explains the other.
  • Whether anything approaching a grid impact was ever demonstrated. The blackout phrasing is an argument about market share, repeated inside the CVE record.
  • How many installations were reachable. The widely quoted figures of roughly 470,000 in Europe and 250,000 in Germany come from secondary reporting; the researcher's own figure is the company's claim of more than 1,000 GW of converters shipped worldwide as of December 2025, which counts something else entirely.
  • What the undisclosed information leak that exposed installer addresses actually was.
  • Whether Sungrow's log review could have detected this method, given it generated an ordinary authenticated session and no notification.