Yarbo security disclosures: the May and June remediation record
Yarbo acknowledged the findings and published two follow-up notices. Distinguish the vendor’s remediation claims from an independently verified device outcome.
AI-assisted, source-linked analysis. Product testing is only claimed when explicitly documented. How we work.
Yarbo's 2026 security disclosures concerned particular remote-diagnostic, credential and messaging systems. They should not be turned into either a blanket verdict on every robot mower or a claim that the original vulnerabilities remain unchanged after subsequent remediation notices.
This account was checked November 10 against the manufacturer's May and June statements. It distinguishes the reported problem, the vendor's stated changes and what UnliveNews has not independently tested. The earlier generic buying guide, network recipes and physical-modification advice have been removed.
The initial story concerned a specific connected robot
The May 9 WIRED security roundup summarized reporting about researcher Andreas Makris's findings in Yarbo systems. It described risks involving remote control and access to sensitive owner information, and an initially inadequate company response.
That is attributed reporting about this incident, not a survey of all mower brands or proof of an attack against every owner's device. It also does not establish whether a particular owner's unit is running a later update. Those distinctions are necessary when revisiting a security headline months after publication.
The former article expanded the story into unsupported claims about particular radio configurations, offline operation, certification labels and the lifespan of batteries and blades. None of those claims was established by the brief incident item in the roundup.
May 8: acknowledgement and immediate restrictions
Yarbo's initial security response acknowledges the core technical findings in the researcher's May 7 report. It describes temporarily disabling relevant diagnostic tunnels, resetting device root passwords and closing or restricting some unauthenticated endpoints.
The response separates actions already taken from work still being developed, including individually scoped credentials and a more controlled diagnostic process. That distinction matters: a promised architectural change should not be reported as already deployed merely because it appears in the same announcement as an immediate restriction.
These are manufacturer statements. UnliveNews has not reproduced the vulnerability or audited the affected backend services. No exploit procedure, credential or device address is provided here.
May 15: further changes and work still in progress
In its first remediation progress update, Yarbo says historical root and remote-access credentials were retired, relevant legacy access paths disabled and unnecessary components removed. It describes remaining work on per-device credentials that can be independently rotated and revoked.
The company also says applicable updates were delivered to connected devices automatically. That statement concerns its rollout process; it does not verify the update state of a machine that this article has never inspected.
An implementation notice can therefore update the historical record without proving a universal outcome. The useful reading is which component the statement addresses, what it says changed and which work remained open at that stage.
June 10: messaging authentication and device-specific credentials
Yarbo's Phase II update describes authentication and topic-based authorization for messaging between devices and cloud services. It says shared firmware connection credentials were replaced with dynamically issued device-specific credentials and app connections were associated with signed-in user identities.
The notice identifies device firmware 3.13.11 and app 3.18.6 for that phase. Those are dated release references, not a claim that they are the newest versions available in November. The company directs customers to current app and firmware updates; this article does not substitute an archived version number for current support guidance.
The Security Center dates the three announcements May 8, May 15 and June 10. Reading the sequence avoids treating an early work-in-progress statement as the last public update.
A remediation claim is not a safety guarantee
The notices document the vendor's response and its asserted deployment scope. They do not establish an independent audit result, absence of other vulnerabilities or the physical safety of operating a particular robot. A lack of such evidence should remain an explicit limitation rather than a reassurance.
The recovered account removes generic instructions to factory-reset devices, block update traffic, mask cameras or disable navigation-related radios. Applying such advice without model-specific documentation could alter operation while failing to address a service-side problem.
For this historical incident, the dependable record keeps three fields separate: the disclosed issue, the vendor's dated remediation statement and the verification actually performed. The last field here is documentary review. It is not a hands-on security test, a product recommendation or a declaration that every affected device is now secure.