#authenticationbypass

Read Time:3 Minute, 16 Second

Fortinet has disclosed a critical authentication-bypass vulnerability in the FortiSandbox web interface. The issue, CVE-2026-107656, can allow a remote attacker to reach protected functionality without valid credentials and potentially execute unauthorized code or commands.

The vulnerability carries a CVSS v3 score of 9.6. Its attack vector is particularly concerning: exploitation can occur over the network, with low complexity, no prior privileges and no user interaction. Fortinet’s advisory currently lists known exploitation as “No,” but exposed systems should still be upgraded promptly because a security appliance can become a high-value foothold.

Alternate path bypasses GUI authenticationCVE-2026-107656 is classified as CWE-288, authentication bypass using an alternate path or channel. In practical terms, the FortiSandbox GUI does not enforce the expected authentication boundary for certain crafted HTTP requests. A remote attacker could use those requests to gain unauthorized access to functions that should require a signed-in administrator.

The public advisory does not identify the vulnerable URL paths, include a proof of concept, or explain the complete post-bypass attack chain. That limited detail reduces the opportunity for defenders to build precise request signatures from the advisory alone. It should not be interpreted as reducing the underlying risk.

Fortinet says the potential result includes unauthorized code or command execution. Because FortiSandbox analyzes suspicious content and can be integrated into wider security workflows, compromise could place both the appliance and connected environments at risk. Actual impact will depend on deployment architecture, network access and the privileges available to the affected service.

Versions that require attentionFortiSandbox 5.0.0 through 5.0.6 are affected and should be upgraded to 5.0.7 or a later supported release. FortiSandbox 4.4.0 through 4.4.9 require version 4.4.10 or later. The 5.2 branch is not affected by this vulnerability.

The hosted FortiSandbox PaaS offering has a similar version split. Releases 5.0.0 through 5.0.6 require an upgrade to 5.0.7 or later. All 4.4 PaaS versions are listed as affected, so customers should migrate to a fixed release. FortiSandbox PaaS 5.2 is not affected.

No virtual patch is listed in the advisory. Administrators should verify the exact product type and installed release before scheduling work, since appliance and PaaS guidance differs. They should also avoid assuming that a previous FortiSandbox web-interface fix protects against this newly disclosed bug; separate flaws can affect separate components and demand their own updates.

Practical mitigation and monitoringIdentify every FortiSandbox appliance and PaaS tenant, then compare its exact version with advisory FG-IR-26-185.

Install 5.0.7, 4.4.10, or another applicable fixed release following Fortinet’s supported upgrade path.

Limit GUI access to trusted management networks and approved administrators wherever the architecture permits.

Review web and appliance logs for unusual unauthenticated requests, command activity or unexpected configuration changes.

Watch connected security and identity systems for activity that originates from the FortiSandbox environment but does not match normal workflows.

Network restrictions are useful risk reduction while an upgrade is being tested, but they are not a substitute for the fix. Organizations should also confirm that controls are applied to every interface that can reach the GUI, including routes available through VPNs, administrative jump hosts or partner networks.

Disclosure contextFortinet credited Adham El Karn of its Product Security team with internal discovery and reporting, and also acknowledged Jason McFadyen of TrendAI Research for responsible disclosure. The vendor’s statement that it has seen no exploitation is reassuring, but it represents current knowledge rather than a guarantee that no attacker has investigated the issue.

As summarized by Cyber Security News, the combination of remote reachability, no credential requirement and possible command execution is what drives the critical rating. Security teams should prioritize version verification now, complete upgrades quickly and retain relevant logs in case technical details or evidence of exploitation emerge later.

Read Time:3 Minute, 45 Second

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 ProcessSungrow 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 DoneJakkaru 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 InfrastructureThis 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 StepsJakkaru 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.