How Hardcoded Credentials and JWT Manipulation Compromised Millions of Solar Inverters

TLDR: Researchers at DEF CON 2024 exposed a critical vulnerability in the Deye and Solarman cloud platforms that allowed for full account takeover. By manipulating the user_id and email fields in a POST request, an attacker could generate a valid JWT token for any account without authentication. This flaw highlights the massive security risks inherent in centralized IoT management platforms that control critical infrastructure.

The rapid adoption of smart, internet-connected energy management systems has outpaced the security maturity of the vendors building them. When we talk about the power grid, we often focus on high-level network architecture, but the real-world risk is frequently found in the mundane, consumer-grade IoT devices that act as the bridge between local hardware and the cloud. The research presented at DEF CON 2024 regarding the Deye and Solarman platforms is a masterclass in why centralized management is a double-edged sword. When a single platform manages millions of inverters, a single authentication failure doesn't just leak data; it grants an attacker the ability to manipulate energy flow at a massive scale.

The Anatomy of the Authentication Bypass

The core of the issue lies in how the Deye and Solarman platforms handled session management and user identification. During their investigation, the researchers used Burp Suite to intercept traffic between the mobile application and the backend. They quickly identified a suspicious login request that relied on hardcoded credentials. This is a classic OWASP A07:2021 – Identification and Authentication Failures scenario, but the rabbit hole went much deeper.

The application used JSON Web Tokens (JWTs) for authorization. However, the implementation was fundamentally broken. When a user logged in, the server would generate a token based on the data provided in the request body. The researchers discovered that the backend did not properly validate the integrity of the claims within the token or the request. By simply modifying the user_id and email address in the POST request, they could force the server to issue a valid JWT for any arbitrary account.

POST /api/v1/login HTTP/2
Host: api.solarmanpv.com
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=targetuser@email.com&password=123456&user_id=12345678

Because the server failed to perform signature checks or enforce strict authorization, the attacker didn't even need to know the victim's password. They only needed the user_id, which was easily discoverable through other API endpoints. This is a textbook case of OWASP A01:2021 – Broken Access Control, where the lack of server-side validation allows an attacker to act as any user in the system.

From Data Leak to Grid Disruption

For a pentester or bug bounty hunter, this finding is significant because it demonstrates how a low-complexity vulnerability can lead to high-impact results. In a typical engagement, you might find an IDOR or a broken authentication flow and report it as a data privacy issue. Here, the impact was compounded by the nature of the target. These platforms manage the settings and operational status of solar inverters.

An attacker with this level of access could theoretically send commands to the inverters, causing voltage oscillations or forcing a mass shutdown. Given that these platforms serve millions of users and account for a substantial portion of global solar generation capacity, the potential for large-scale disruption is not just theoretical. The researchers noted that they could obtain sensitive information like last login IP addresses and physical addresses, which could be used to further target specific high-value installations.

Why Centralized IoT is a Security Nightmare

The transition of Deye to its own data center, while still relying on the same underlying code base as Solarman, illustrates a common problem in the IoT space: code reuse without security auditing. When vendors migrate users to new infrastructure, they often carry over the same legacy vulnerabilities. The researchers found that the same JWT manipulation technique worked across both platforms because the backend logic remained largely unchanged.

Defenders must treat these IoT management platforms as critical infrastructure components. If you are managing these systems, the first step is to ensure that your vendor has a functional and responsive Vulnerability Disclosure Program. If they don't, you are flying blind. Furthermore, organizations should implement strict network segmentation for IoT gateways. These devices should never have direct, unrestricted access to the internet if they can be avoided, and their communication with cloud platforms should be monitored for anomalous patterns, such as unexpected API calls or mass authentication requests.

What Comes Next

The researchers were able to work with the vendors to get these issues patched, but the sheer scale of the exposure serves as a warning. We are connecting more of our critical infrastructure to the internet every day, often using platforms that were built for convenience rather than security.

If you are hunting for similar bugs, stop looking for complex exploits and start looking at the authentication flow. How does the server verify that you are who you say you are? Does it trust the client-provided data too much? The next time you see a "smart" device with a cloud-based management app, don't just look at the device itself. Look at the API that controls it. You might find that the entire system is held together by nothing more than a poorly implemented JWT and a lack of server-side validation. The next big vulnerability in our infrastructure might be just one intercepted POST request away.