Exploits

SolarEdge CSRF OOB Injection Compromises Monitoring

Eng. Donya Bino Published  ·  10 min read

An essential flaw within the SolarEdge monitoring platform's business logic permits the takeover of an operator's session by an attacker, which will allow them to compel SolarEdge's internal systems to have communications with outside malign infrastructures, or servers. These vulnerabilities are present at the endpoint /solaredge-web/p/initClient.

The SolarEdge CSRF Out Of Band (OOB) injection vulnerability (CSRF) was discovered by the security researcher nu11secur1tyAI. The SolarEdge monitoring platform has both a CSRF and OOB injection vulnerability via the X-Forwarded-For and Referer headers.

SolarEdge Technologies Ltd. provides photovoltaic system monitoring platforms and a compromise of this system will allow unauthorized control over physical solar installations.

CSRF Vulnerability

The SolarEdge CSRF OOB injection vulnerability allows an attacker to initiate an action on behalf of an operator without their knowledge by forcing the operator's web browser to perform unauthorized functions through the CSRF mechanism.

The vulnerable endpoint is /solaredge-web/p/initClient, and the compromised system allows the creation/overwriting of session parameters through the sending of POST requests without proper checking of their origin.

One of the commands that can be executed through the above methods is the createCookie command. This is particularly dangerous because it permits an attacker to create or modify session cookies that will result in the hijack of sessions.

Out-of-Band Injection Issue

Researchers found an out-of-band injection issue introduced by the X-Forwarded-For and Referer headers in the CSRF vulnerability in SolarEdge. If an attacker sends a request with modified headers that force the internal infrastructure of SolarEdge to send requests to an external domain (i.e., an attacker-controlled domain), it demonstrates a lack of proper filtering at the framework level.

The CSRF out-of-band injection vulnerability in SolarEdge allows for both data exfiltration through DNS and HTTP callbacks and for attackers to map a company's internal network infrastructure using this method.

How the Attack Works

The attack chain for the SolarEdge CSRF Out-of-Band injection vulnerability is quite straightforward. 

1. The attacker crafts a request by creating a POST request to the URL /solaredge-web/p/initClient, with the following parameters: cmd=createCookie, which is the command to create a cookie; and with malicious headers, X-Forwarded-For and Referer, that point to the attacker's domain.

2. The attacker then tricks the operator into executing the request by hosting it on a web page or sending it via email. When the SolarEdge operator who is currently logged in clicks the link, the request will be executed automatically.

3. The attacker will then be able to hijack the session by taking advantage of the SolarEdge CSRF Out-of-Band injection vulnerability to overwrite the session parameters, and thus gaining access to the operator's account.

4. The attacker will then be able to exfiltrate the data from the SolarEdge OOB Out-of-Band authentication by using the malicious headers to cause SolarEdge's internal network to make requests to the attacker's domain, with either sensitive information or confirmations of successful exploitation of the attack.

The Vulnerability Exploit Showcase

A proof-of-concept HTML form has been provided by the research to show how the SolarEdge CSRF out-of-band (OOB) injection flaw can be exploited.

The form sends a POST request to the vulnerable endpoint when it submits automatically from a victim's browser via their client capabilities browser fingerprinting data.

Additionally, an automated submission of the form via JavaScript takes place and the victim does not perform any clicks after loading.

The Impact on Solar Monitoring

The SolarEdge platform allows the monitoring of solar systems that consist of photovoltaic panels, inverters, and battery energy storage systems to track their energy produced and health for the operator.

The SolarEdge CSRF OOB injection vulnerability could allow an attacker to:

1. Hijack an operator’s session - An attacker could gain access to a legitimate operator’s account and view a large amount of sensitive information related to the photovoltaic system, including details about energy production and configuration.

2. Modify the operation - If the attacker’s account has been accurately hijacked, he/she could modify parameters in the Inverter, battery discharge rates, and grid connection; this could result in alterations to either the production of electricity or present safety issues.

3. Shut down the system - The SolarEdge CSRF OOB injection vulnerability would allow an attacker to disable the system from monitoring or to send a shut down signal; this would stop production of electricity for either the operator or customer.

4. Exfiltration of customer information - The OOB injection presents an opportunity for exfiltration of customer data to an attacker controlled domain; potential customer data includes customer’s names and addresses, energy consumption history, and information specific to the operation of the photovoltaic system.

X-Forwarded-for Header

X-Forwarded-For (Xff) is widely used by web applications to identify the end client's actual ip when connecting to the application via a load balancer or proxy, as such, it is trusted implicitly.

The SolarEdge CSRF OOB vulnerability exploits that trust and allows an attacker to inject an external domain into the X-Forwarded-For header whereupon SolarEdge will attempt to connect to that external domain using its internal infrastructure.

This method of injecting an external domain into the X-Forwarded-For header is generally referred to as server-side request forgery (ssrf) via header injection and can be leveraged to gain access to a target's internal network, or exfiltrate data from a target's internal network.

Referer header injection

The Referer header provides information to web servers about the page that referred a request and is used in CSRF OOB injection vulnerabilities by SolarEdge as an out-of-band method for injecting malicious requests into their monitoring platform using this same header by sending an attacker controlled Referer Header value to their server.

An attacker can leverage this vulnerability by using a Referer Header pointing to their own domain (e.g., oastify.com), and when SolarEdge processes the request, it will eventually hit oastify.com due to SolarEdge’s use of external domains for logging or statistics.

The SolarEdge CSRF OOB injection vulnerability demonstrates how "harmless" headers can become attack vectors when trust is placed in headers by applications.

Why No Patch Was Mentioned

The researcher did not mention in the vulnerability disclosure if SolarEdge had made available a patch to the SolarEdge CSRF OOB injection vulnerability, but stated the SolarEdge CSRF OOB injection vulnerability is "MEDIUM - HIGH" severity and has no patch version information.

Users of the SolarEdge Monitoring Platform should contact SolarEdge support for inquiries regarding patches for the SolarEdge CSRF OOB injection vulnerability; in the interim, they need to consider the potential risks associated with the SolarEdge CSRF OOB injection vulnerability.

The SolarEdge Computers and Server monitoring service at monitoring.solaredge.com is vulnerable to the SolarEdge CSRF OOB injection vulnerability; thus, any customers using this service are susceptible.

How to Protect Yourself

Until a patch is available for the SolarEdge CSRF OOB injection vulnerability, here is what you can do:

1. When not in use, you should log out of the monitoring platform. Since a CSRF attack can only occur when you are logged in (i.e., there is an active session), logging out of the monitoring platform will minimize the opportunity for this type of attack to happen.

2. You should only use modern browsers that are equipped with CSRF protection to monitor your SolarEdge account. There are browsers that come with built-in features to protect you against CSRF by blocking cross-origin requests; however, these measures do not provide complete protection from the SolarEdge CSRF OOB injection vulnerability.

3. You should monitor for unauthorized changes made to your SolarEdge account. You should keep an eye out for unexpected changes made in your configuration and check that the logged-in sessions are familiar to you. If there are any changes that you don't recognize, you should report them to SolarEdge.

4. You should only click links that you trust whenever you are logged into your SolarEdge account. Since a CSRF attack can only occur when the attacker can convince the victim to visit an attacker's website, a good way to limit your exposure to CSRF attacks would be to never click on links or open attachments from people that you don't know while logged into SolarEdge.

5. Contact SolarEdge Technical Support. Ask SolarEdge for information regarding the SolarEdge CSRF OOB injection vulnerability and find out if a patch is available. You should also request that they notify you when a patch is made available.

Researcher Background

nu11secur1tyAI has identified and released numerous flaws in many different platforms through public disclosures, while this particular researcher has focused specifically on business logic and injection vulnerabilities.

At the time of writing this article, the researcher had published information on his Patreon page about the SolarEdge CSRF OOB injection vulnerability as well as provided the exploit code that would allow others to exploit the CSRF and OOB injection vulnerabilities together.

Conclusion

The SolarEdge CSRF OOB injection vulnerability is an example of how even enterprise monitoring systems can have basic vulnerabilities.

The fact that both vulnerabilities allow an attacker to take over an existing session and to steal data from that session makes it quite dangerous, especially in this case because the SolarEdge CSRF OOB injection vulnerability allows for the monitoring of a piece of physical solar power generation equipment.

If compromised, the SolarEdge monitoring system has the potential to disrupt energy production or to create unsafe conditions for the physical operation of the equipment; therefore, this is not merely a data breach issue but also a potential physical safety issue.

If you are using SolarEdge's monitoring system, operate under the assumption that you are at risk for session hijacking until the patch has been applied, log out when you are not using the system, will watch for unapproved changes to the system, and will report the issue to SolarEdge.

FAQ Section

What is the SolarEdge CSRF Out-Of-Band (OOB) injection vulnerability?

This vulnerability provides two opportunities for malicious entities to take advantage of the SolarEdge API.  The first avenue is a CSRF vulnerability that permits the attacker to overwrite API session parameters through the /solaredge-web/p/initClient endpoint.  

The second avenue is an OOB injection vulnerability that permits an attacker to create communications between the SolarEdge internal infrastructure and attacker-controlled domains through the manipulation of the X-Forwarded-For and Referer headers. 

What types of actions can be taken by an attacker using the aforementioned vulnerabilities?

Using these vulnerabilities, an attacker can hijack operator sessions to gain native access to the monitoring platform, view sensitive system configuration data, modify solar inverter operational settings, and exfiltrate identity/commerce customer data from the cloud using out-of-band (OOB) call-back communication.

Is there currently a patch available for the SolarEdge CSRF OOB injection vulnerabilities?

The researcher did not specify in their disclosure if there is a patch available, therefore users should contact SolarEdge support to obtain current information about this vulnerability and to obtain status updates.

Does this vulnerability affect physical solar panels?

The SolarEdge out-of-band CSRF vulnerability affects the fact that it allows attacks on the monitoring platform responsible for controlling and monitoring the photovoltaic systems; unauthorized access could create configuration changes affecting energy production or equipment safety.

How can I protect my SolarEdge account against this vulnerability?

Log out of the monitoring platform when not in use, do not click on links from unknown sources when you are logged in, ensure that you monitor your account for unauthorized changes, and contact SolarEdge support for patching information.

Source: Exploit DB
Professional Services

Explore Our Cybersecurity Services

Our insights are backed by hands-on service delivery. If your business needs professional cybersecurity support, our UK-based specialists are ready to help.

© 2016 – 2026 Red Secure Tech Ltd. Registered in England and Wales — Company No: 15581067