Category Archives: Vulnerability Disclosure

SolaX inverter’s Pocket WiFi using poor authentication

CVE-2023-35835, CVE-2023-35836, and CVE-2023-35837
SolaX Pocket WiFi v3
At time of writing believed to affect all known firmware versions
Tested up to and including v3.009.03_20230504
No known plans to distribute patches to existing owners of SolaX equipment

These three vulnerabilities are all in relation to the Pocket WiFi v3 hardware module that can be used with SolaX inverters for solar panels and batteries. The three CVEs represent three different but related vulnerabilities for the same device. Between the three vulnerabilities, an attacker could trivially write a script that detects SolaX Pocket WiFi networks, connects to them, and then issues potentially damaging ModBus commands to the inverter. Additionally, the attacker could use this access to further infiltrate the victim’s WiFi network that the Pocket WiFi device is simultaneously connected to.

CVE-2023-35835: Persistent Open WiFi Access Point

The device maintains a permanent open WiFi access point. It is intended to be used for initial configuration and it lacks any form of network authentication. This access point persists even after setup is complete and provides access to a web-based configuration utility and an unauthenticated ModBus protocol interface. It is possible to send standard ModBus messages to the inverter using this unauthenticated WiFi access point. The ModBus service facilitates reading and writing data to the inverter which could change its configuration and therefore cause disruption to its standard functioning. Though not tested, owing to a limited number of test devices, it is anticipated that this service could be attacked in order to cause physical damage to the inverter and potentially other connected components.

CVE-2023-35836: Network Configuration Disclosure

Attackers within radio frequency range can obtain a cleartext copy of the device’s network configuration, including the Wi-Fi Pre-Shared Key (PSK), during setup and reconfiguration of the Pocket WiFi device. This means that an attacker could access the victim’s Wi-Fi network using the obtained PSK and therefore could perform attacks on machines and services that were otherwise not exposed.

CVE-2023-35837: Web admin uses predictable password

The web interface authentication relies on an unauthenticated WiFi access point, and the administrative password is the device’s registration ID, which is also the WiFi SSID. This means that an attackers could gain unauthorized access to the Pocket WiFi web interface, reconfigure the device, or upload malicious firmware. This then potentially leads to Denial of Service, code execution, or Privilege Escalation.

SolaX’s response to the disclosure

After persistent communication from myself, SolaX informs me that they are going to:

  • “hide the SSID”, which might mean turning off SSID beacons
  • add a “local encryption strategy”, which I think means adding TLS to the web interface, but this is a guess
  • add a “default password modification strategy”, which I hope means alerting users to default passwords
  • add a PSK to the WiFi access point

SolaX have been unable to identify a strategy for getting any security patches distributed to existing owners of their Pocket WiFi modules. They have indicated that they could perform the updates remotely. I asked them for further details but none were forthcoming. At the time of writing there has been no update pushed to the Solax Pocket WiFi device I can access. In all fairness to them, there has been an extra option appear in the smart phone app that suggests it may now be possible to toggle on and off the WiFi access point. This feature doesn’t work though, presumably because I don’t have a corresponding firmware version.

The below summarises my communication with SolaX. As you can see, some of it was hugely encouraging, whilst at other times it was lacking altogether. Above all else, I think this demonstrates how important it is that organisations have a vulnerability disclosure process in place. It was hard to get to talk to anyone in the first place, and even then it wasn’t the right person and during the whole period communication was patchy.


On May 11th, I sent an initial email expressing my concerns about the cybersecurity issues I discovered with their product. I offered to help them improve their product through responsible disclosure.

After receiving no response, I decided to follow up on May 17th. I reiterated the importance of responsible disclosure and mentioned my intention to request official CVE IDs with a 90-day disclosure period.

Still not hearing back from SolaX, I reached out to their telephone helpdesk on May 24th and sent another email, hoping for a response.

On May 25th, I received a call from a SolaX UK representative who understood my concerns and advised me to apply for CVE IDs whilst they investigated internally.

I informed SolaX on June 8th that I had submitted the CVE request and also requested their GPG key for encrypted communication.

Unfortunately, I received no response to my request for the GPG key or any subsequent emails I sent.

On July 17th, I sent a reminder about the impending public disclosure of the vulnerabilities on September 15th. I asked for cooperation from SolaX to work on security patches.

SolaX provided me with firmware images on July 20th, and communication resumed.

I asked SolaX about their plans to address the vulnerabilities, the timeline for implementation, and whether they had third-party security testing in mind on July 25th.

On 04 September 2023 after having received no response to several emails I decided to gather all the contacts I could find for company globally from their website and forward the email chain to date to them all asking for a response.

I got a flurry of emails starting on the 13th September, two days before the planned publication date. These were generally quite promising, they were looking at engineering solutions that would make the situation better and though needed a little direction to deal with the issues correctly, they seemed to be taking it all seriously. Then the emails stopped again.

Since I didn’t receive a response, I decided to follow up on September 20th. I wanted to understand when they expected to complete the corrective actions and distribute them to customers. I also proposed a delayed publication date of January 1st, 2024 in an attempt to give them some breathing room.

On September 25th, SolaX confirmed their planned security measures and mentioned a tentative completion date for corrective actions in December. They appeared to be unfamiliar with Coordinated Vulnerability Disclosure (CVD) so I gave them a brief explanation and pointed them to some online articles on the subject.

I reached out again on October 23rd to offer assistance and check on SolaX’s progress but heard nothing back.

On December 21st, I sent a final reminder regarding the impending publication date and requested information on SolaX’s distribution plan for security patches to their customers. As I didn’t hear back and I wanted to be as fair as possible to them, I have delayed publication until today.

Athom Homey Security Review | Transmits unencrypted WiFi credentials (CVE-2020-9462)


TL;DR: All Athom Homey and Athom Homey Pro devices, up to the current version (v4.2.0) transmit their initial configuration in the clear which includes your WiFi password. At the time of writing, Athom have no plans to fix this.


I will preface this with the fact that this vulnerability is not the most exciting in history, however, it is a vulnerability and the company should be doing better. The Athom Homey device is a smart-hub and can connect with other devices using a lot of different protocols.

In principle, the device is great as it means you should only have one place to orchestrate your smart home.

Despite it’s flaws, I actually really like this device.

Essentially, when setting up the device it has to connect to your WiFi network. The device has no exposed Ethernet port which is a shame, but, on the most part, this doesn’t seem to be a problem.

Athom Homey Security Vulnerability

The vulnerability only exists when going through the setup routine. The vulnerability exists because the device creates a temporary WiFi hotspot that is unencrypted which the user must connect to in order to perform the initial configuration. Crucially this means that when you configure the devices WiFi connection, you send the WiFi password in an unencrypted link to the device.

I sent Athom an email which contained the following:

The security vulnerability I wish to report to you today is the fact
that during sign up, your devices receive the WiFi security key without
being protected by any form of encryption. This means that an attacker
who is physically within range would be able to receive a copy of the
encryption key and therefore be able to gain unauthorised access to the
victim’s WiFi network. This is the same vulnerability that Amazon’s Ring
Doorbell made international news about in November 2019:

Read more about ring doorbell WiFi vulnerability

Which got the following response:

Thank you for your effort and letting us know your findings!

We are aware of the security risk involved in sending the credentials in plain text during setup of Homey.

We have made the decision back when this feature has been designed that while the process is in theory insecure, in practice it has a very low risk attack vector. In fact, there are many smart devices that use a similar way to set-up said devices.

Because the user must manually enable Wi-Fi Setup on Homey by turning it physically upside down, and another hacker must be present at the same time with equipment that’s not available to most, we have decided to focus our security efforts on more pressing matters. I am happy to say that 3rd party penetration tests have been performed on Homey and no one was able to gain access.

On a technical note, there is no secure way to set-up devices over a Wi-Fi hotspot without an out-of-band key. Homey does not have this printed in a manual, sticker etc. so we cannot simply issue an update. All other mechanisms are by definition unsafe because they rely on a shared secret, which is always crackable for any determined hacker.

We take the security and privacy of our users very seriously.

Not a bad response, though it got me to thinking…

It is true that other devices use a similar WiFi configuration routine, but, as demonstrated by Amazon’s Ring, it isn’t considered good enough on those devices either. It is also true that devices using completely different protocols, such as ZigBee, also have a similar type of key-exchange flaw. Again, it isn’t considered good enough here either.

I also don’t think it is fair to suggest that this configuration process only happens once. I’ve had this device for a while and I use it a fair bit and during that time I have ended up having to reset it and reconfigure it.

Nevermind that, but, it doesn’t take much to realise that an attacker could easily create a circumstance that would encourage the victim user to start this reconfiguration process even when it wasn’t needed.

So I sent them another email:

Thank you for your response an, but I respectfully disagree.

There are methods in a closed ecosystem to perform key exchange. For example, the software on the Homey could be instructed to use knowledge of an Athom internal Root Certificate Authority to perform Homey to Smart-phone authentication, and the user’s smart-phone could be issued with an identity that is cryptographically derived from Athom’s internal CA and as such can be trusted by the device.

This then provides encrypted comms between Homey and the Smart phone which is already a big step-up. In theory though, this could be subjected to a Man-in-the-Middle attack. For example, where another user with a legitimate certificate could trick the victim Homey and the victim smart-phone into communicating with the attacker. To prevent this circumstance it would be best to have mutual authentication, but that is very difficult to achieve with devices that have already been deployed. There is a solution though – either Diffie Hellman key exchange (DH KX) which reveals an active attacker the moment they stop intercepting communications, or a variant of DH KX called STS (Station to Station)…

Furthermore, the Homey does have the ability to perform out of band key validation – amongst other methods, it speaks! This would allow key exchange and validation to be completed in the same manner as Bluetooth key exchange is completed with a PIN number.

I’m also worried about your analysis of the risk involved – just because this only happens during setup and that there must be user interaction does not make it immune to problems. For example, it is perfectly possible for an active attacker within RF range to perform a de-authentication attack against the device until the user chooses to reset it. Granted that when calculating its CVSS, having user interaction does reduce the score, but, I would suggest the result is still relatively high at approximately 5.0, with a vector of CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. This is owing to the ability of the attacker to not only intercept the communications which reveals the WiFi network key that in turn changes the scope of the attack, but also, because there is also the possibility of an integrity issue, such that at attacker could get the Homey device to connect to a malicious WiFi network and thus be able to perform other attacks against the device.

And finally, I don’t consider your assertion that “other people do this too” an adequate defence to your own lack of security. Just because it is done elsewhere does not make it right.

Please reconsider your position. I would be delighted to be of further help.

They were gracious enough to send me another response:

I do agree with some of the points you make, however, at this time we do not have the capacity to change Homey’s behavior during Wi-Fi setup. While you are technically right, we deem the attack vector to be small enough to be acceptable.

In any future products we will consider your findings.

As of this date, no fix for this is in place which is disappointing. You can find The official CVE for this issue by clicking here:

Learn how YGHT can help you imrpove your cybersecurity