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 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 Persistence
The 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-Recovery
The 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 Configurations
Some 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:
security@yarbo.com
The public will also be able to find our security contact information on the Yarbo Security Center page 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 Kohlmann
Co-founder, Yarbo
New York
