Originally published by The Verge Social
A detailed pledge from the robot lawn mower company.
A detailed pledge from the robot lawn mower company.
Yesterday, I told you howa hacker ran me over with a robot lawn mower. We explained how thousands of these bladed Chinese robots, made by Yarbo, could be hijacked with ease — exposing people’s GPS coordinates, Wi-Fi passwords, email addresses, and more to any casual hacker who comes along.
Today, Yarbo has issueda thorough 1,200-word responsethat you can read in full below. The company is confirming the security researcher’s findings, apologizing, and providing a detailed plan to tackle many of its self-created security issues head-on. Yarbo writes that it’s already temporarily cut off remote access and is addressing many of its most head-smacking issues, like how root passwords were the same for every single robot and were left in easy places for hackers to find.
“In the future, each device will use its own independent credentials to prevent one affected device from impacting the entire fleet,” Yarbo writes. The company says its first wave of security updates should roll out within one week.
Importantly, though, Yarbo isnotyet committing to remove the single most troubling thing about these robots. The company writes that it will still have a remote backdoor into Yarbo’s robots, only now one that is “limited to authorized internal company personnel, may only be used after user authorization has been obtained, and will be gradually brought under audit logging.”
To be clear, Yarbo already previously claimed that its remote access was only available to authorized employees; our story proved that was not true.
But giving the company the benefit of the doubt: why not remove the tunnel entirely, or make it an opt-in installation? Why do Yarbo’s customers not get to decide whether their robots have a persistent backdoor? I’ve asked the company those exact questions, and we’ll update with its answer.
Yarbo’s statement also tries to suggest that the vulnerabilities we’ve seen are because of “historical” or “legacy” services, implying that perhaps some of the company’s robots were more secure. We’ve asked Yarbo what percent of its robots are on those historical services as opposed to current ones.
Security researcher Andreas Makris, who discovered the vulnerabilities, says he hasn’t yet been able to check whether he can still access them after Yarbo’s changes. It sounds like the company is taking him seriously, now, though. “Yarbo has initiated direct communication with me and has taken the positive step of establishing a dedicated security response center. We are currently in discussions regarding the remediation process, and they have assured me that these fixes are their highest priority,” he says.
Here is Yarbo’s full update to customers:
I’m writing this directly because the issues raised in the recent security report deserve a direct response, not a corporate one.On May 7, 2026, security researcher Andreas Makris published a detailed report identifying serious vulnerabilities in Yarbo’s remote diagnostic, credential management, and data-handling systems. The core technical findings are accurate. I would like to thank Mr. Andreas Makris for his work in identifying these issues and for his persistence in bringing them to our attention. I also recognize that our initial response did not adequately reflect the seriousness of the issues he identified. As co-founder, I’m accountable for what shipped on our products, and I’m accountable for the response.Our engineering, product, legal, and customer support teams are working on remediation as the highest priority. What follows is my account of what was found, what we’ve already fixed, what we’re actively fixing, and what we’re committing to change in how we operate going forward.Based on our preliminary review, the issues primarily relate to historical design choices in parts of Yarbo’s remote diagnostic, access management, and data handling systems.Specifically, certain legacy support and maintenance capabilities did not provide users with sufficient visibility or control, and some authentication and credential management mechanisms did not meet the security standards we expect for today’s products.We have also identified areas where access permissions, backend system configurations, and data flows between devices and cloud services require stronger protections and stricter controls.We recognize the seriousness of these issues and the concerns they may have caused for our customers and community. We sincerely apologize for the impact this situation has created, and we are committed to addressing these issues in a transparent and responsible manner.We are strengthening system security by reducing legacy access paths, tightening permissions, and moving toward fully auditable device-level credentials. To make our remediation progress clear, we are separating the actions already taken from the work that is currently in progress.What We Have Already DoneWe have temporarily disabled the relevant remote diagnostic tunnels to reduce the risk of unauthorized access.We have completed a reset of device root passwords to temporarily block the identified shared-credential risk and prevent further expansion of the issue.We have closed or restricted certain unauthenticated status-query and reporting endpoints.We have begun reducing unnecessary legacy access paths and tightening backend permissions.What We Are Working On NowWe are implementing an allowlist-based, user-authorized, and auditable remote diagnostic model. The first phase is expected to be completed within one week. Once implemented, remote diagnostic access will be limited to authorized internal company personnel, may only be used after user authorization has been obtained, and will be gradually brought under audit logging.We are using OTA updates to advance credential rotation and device-level independent credential mechanisms, gradually replacing the historical shared-password model. In the future, each device will use its own independent credentials to prevent one affected device from impacting the entire fleet.We are building and testing a robot credential management service so that device passwords are no longer hardcoded in firmware, scripts, or databases. Instead, credentials will be dynamically derived based on device identity. OPS access will also record the visitor, reason for access, work order, and timestamp.We are hardening other authentication services. These fixes are currently in the testing stage and will be released through upcoming OTA updates.We are adjusting topic permissions to reduce fleet-level shared access, limit the scope of each credential, and establish stricter boundaries around control commands.We are testing cleanup measures that include removing unnecessary reporting scripts, legacy cloud service dependencies, third-party agents, and non-essential DNS fallback configurations in order to reduce data flows that are not clearly visible to users. These changes will be rolled out through future OTA updates after testing is completed.Historical servers and legacy access channels will continue to be phased out one by one as part of this remediation process.We are also accelerating OTA security updates and additional server-side protections. The first wave of updates is expected to begin rolling out within one week.Important:A security firmware update is being pushed to all Yarbo devices. To receive this update, please connect your Yarbo to the internet. Once the update has been applied, you may return to your preferred network settings. If you prefer to keep your device offline in the meantime, you may do so without affecting your warranty or service coverage. We will notify you when the update is ready so you can connect briefly to apply it.This remediation effort is not limited to a single fix or software update. We are using this process to strengthen the long-term security architecture and governance standards behind our products.These efforts include strengthening access control standards, improving authentication and authorization models, increasing user visibility and control over remote diagnostic features, and further reducing unnecessary legacy support mechanisms across related systems and infrastructure.We will also continue expanding our internal security review, remediation, and governance processes to support stronger long-term security practices going forward. Our goal is to ensure that security, transparency, and user trust are built into the foundation of future Yarbo systems and services.Some items in the external report describe real security issues, while others require clarification because they do not apply to currently shipped Yarbo products or do not represent independent security vulnerabilities.FRP Auto-Restart and PersistenceThe report also mentions that the FRP client may restart through scheduled tasks or service recovery mechanisms. We acknowledge that this can make manual disabling of remote access channels more difficult, but the core issue lies in the existence, permissions, and policy of the remote tunnel itself. Our remediation focuses on disabling or restricting tunnels, introducing allowlisting and auditability, and removing unnecessary persistent remote access paths.File Monitoring and Self-RecoveryThe report mentions file monitoring behavior that can restore certain deleted files or services. This mechanism was originally designed as a defensive reliability measure to prevent critical service files from being accidentally deleted or corrupted. By itself, it was not intended to function as a remote access feature.That said, we recognize that any mechanism making remote-access-related components difficult for users to remove can create trust concerns. We are reviewing which files should continue to be protected and which components should be removed, simplified, or placed under user control.Historical or Non-Production ConfigurationsSome findings involve historical infrastructure, legacy cloud services, dealer-specific customizations, or internal test configurations. These remain under review and are being cleaned up where necessary, but they should be distinguished from the default behavior of currently shipped production units.Our goal is to be precise: we will not minimize confirmed security issues, but we also want users to understand which findings apply to production devices, which apply only to historical or customized configurations, and which are being addressed as part of broader hardening efforts.To improve security reporting in the future, we are launching a dedicated security response channel and security contact process for vulnerability reports and responsible disclosure:[email protected] public will also be able to find our security contact information on theYarbo Security Centerpage under the “Explore” section of our official website.We are also exploring the possibility of establishing a formal bug bounty program as part of our broader long-term security initiatives.We appreciate the role independent security researchers play in responsibly identifying potential issues, and we remain committed to strengthening the security, transparency, and trustworthiness of our products.As the investigation and remediation work continues, I will provide further updates as they become available.Kenneth KohlmannCo-founder, YarboNew York
I’m writing this directly because the issues raised in the recent security report deserve a direct response, not a corporate one.
On May 7, 2026, security researcher Andreas Makris published a detailed report identifying serious vulnerabilities in Yarbo’s remote diagnostic, credential management, and data-handling systems. The core technical findings are accurate. I would like to thank Mr. Andreas Makris for his work in identifying these issues and for his persistence in bringing them to our attention. I also recognize that our initial response did not adequately reflect the seriousness of the issues he identified. As co-founder, I’m accountable for what shipped on our products, and I’m accountable for the response.
Our engineering, product, legal, and customer support teams are working on remediation as the highest priority. What follows is my account of what was found, what we’ve already fixed, what we’re actively fixing, and what we’re committing to change in how we operate going forward.
Based on our preliminary review, the issues primarily relate to historical design choices in parts of Yarbo’s remote diagnostic, access management, and data handling systems.
Specifically, certain legacy support and maintenance capabilities did not provide users with sufficient visibility or control, and some authentication and credential management mechanisms did not meet the security standards we expect for today’s products.
We have also identified areas where access permissions, backend system configurations, and data flows between devices and cloud services require stronger protections and stricter controls.
We recognize the seriousness of these issues and the concerns they may have caused for our customers and community. We sincerely apologize for the impact this situation has created, and we are committed to addressing these issues in a transparent and responsible manner.
We are strengthening system security by reducing legacy access paths, tightening permissions, and moving toward fully auditable device-level credentials. To make our remediation progress clear, we are separating the actions already taken from the work that is currently in progress.
What We Have Already Done
We have temporarily disabled the relevant remote diagnostic tunnels to reduce the risk of unauthorized access.
We have completed a reset of device root passwords to temporarily block the identified shared-credential risk and prevent further expansion of the issue.
We have closed or restricted certain unauthenticated status-query and reporting endpoints.
We have begun reducing unnecessary legacy access paths and tightening backend permissions.
What We Are Working On Now
We are implementing an allowlist-based, user-authorized, and auditable remote diagnostic model. The first phase is expected to be completed within one week. Once implemented, remote diagnostic access will be limited to authorized internal company personnel, may only be used after user authorization has been obtained, and will be gradually brought under audit logging.
We are using OTA updates to advance credential rotation and device-level independent credential mechanisms, gradually replacing the historical shared-password model. In the future, each device will use its own independent credentials to prevent one affected device from impacting the entire fleet.
We are building and testing a robot credential management service so that device passwords are no longer hardcoded in firmware, scripts, or databases. Instead, credentials will be dynamically derived based
[Article truncated — read full article]
As an Amazon Associate, we earn from qualifying purchases at no extra cost to you.