There's some vulnerability in some Yealink service exposing device and user information.


I contacted the author directly this morning and identified myself as a service provider looking for details. He could not share if this was an issue with RPS, DPMS Enterprise, the services or the websites. He also would not give any technical details as to scope or impact.


I am cautiously optimistic for the reason that we don't require the storage of any authentication information in RPS. It's simply the MAC address and the provisioning server address. Assuming even a full compromise, the attackers would have those pieces of information and nothing else. The prescient concern is that they could use those two pieces to pull configurations from our NDP.


We left it that the author was going to forward my contact information directly to VT (the organization that found the bug). I am also working with other NetSapiens providers to get further details. Finally, I have also reached out to Yealink directly. But they are still celebrating Chinese New Year and have not yet responded.

Additionally, we will be setting up alerting and more closely monitor the provisioning logs to identify requests that are out of the ordinary. We will also re-examine our existing security posture to determine if any further steps are necessary.

As always, I will update everyone as we learn more information. If you have any questions or concerns please contact support.

Update: Response from Yealink

This is Leah from Yealink technical support team.

Regarding the content from the article, I have to correct something, when Yealink received this information, it drawn the highly attention inside, and we contacted VTrust immediately, and we are currently working together.

The security flaw came from our Redirect Provision Server, and it’s confirmed to be a bug on a part of the MAC addresses during the authentication. After the devices has been provisioned successfully, if the RPS server receives request from these MAC addresses again, it will be cheated and the info leaks afterwards. Therefore, if the MAC addresses are not registered in our RPS server, it won’t be influenced by this security flaw.

As you might know, Yealink has our first action on the server side before Chinese New Year Holiday, which forbidden these MAC addresses to access our server completely to avoid the info leaks. After first action to be done, the security vulnerability is almost fixed, and could work as usual.

Furthermore, we already have the second action under developed, due to the holiday has been extended, it has been postponed unfortunately. More details regarding our second action, we will keep enhancing the authentication method, and ask for SN check as well, that means for these MAC addresses, when access request received by the server, the phone would popup a window to ask user to input the SN, if it’s correct, then authentication passes. The hacker should not be able to get the MAC address match with its SN, so when the second action finishes, this Redirect Provision Server security flaw will be fixed completely, and secure.