Critical Vulnerabilities in Pudu Robotics’ Service Robots Exposed and Remediated

CyberSecureFox 🦊

An independent security researcher known as BobDaHacker disclosed critical weaknesses in the Pudu Robotics ecosystem that could allow attackers to redirect robots, alter jobs, and issue arbitrary commands within the managed runtime of deployed devices. Given Pudu’s significant footprint in restaurants and offices, the impact potential was substantial.

Service robot security under scrutiny: why this matters

Pudu Robotics builds commercial service robots such as the food-delivery BellaBot and the building-integrated FlashBot (elevator interaction). According to Frost & Sullivan, Pudu held about 23% of the global market for such systems last year, which amplifies the systemic risk when core administrative controls are exposed.

Attack vector: weak admin controls and token misuse

The researcher found that administrative access to the management software was insufficiently restricted. Exploitation required a valid authorization token, which could be obtained via cross-site scripting (XSS)—a web flaw that lets attackers run malicious scripts in a victim’s browser—or by creating a test account intended for pre-sales evaluations.

Lack of layered access control and RBAC enforcement

Once authenticated, the platform did not consistently enforce role-based access control (RBAC) or additional guardrails such as granular permission checks, device scoping, or step-up verification for sensitive actions. This enabled changes to orders, reassignment of robots, and even renaming devices—complications that can delay recovery of normal operations across a fleet.

Operational and business impact for restaurants and offices

In practice, an attacker could reroute meals, degrade guest service, or disrupt an entire restaurant robot fleet. In office environments, where robots integrate with building systems (e.g., elevators), the risk extends to operational disruption and potential exposure of configuration data and intellectual property.

Disclosure timeline and vendor response

According to the researcher, the first responsible disclosure attempt on August 12 received no response. After a second attempt on August 21 and outreach to Pudu clients in Japan (Skylark Holdings and Zensho), the company engaged within approximately 48 hours. The initial reply included a template string containing “[Your email address],” which drew public attention to the handling process.

On September 3, the researcher clarified that earlier emails had not reached their intended recipients. Pudu had reportedly received the report through alternate channels and started remediation before direct contact was established. The company states it has fixed the vulnerabilities and created a dedicated security contact at [email protected], apologizing for the template oversight.

Expert analysis: lessons for IoT and robotics cybersecurity

This incident reflects common issues in IoT and robotics platforms: excessive privileges after basic login, missing RBAC, lingering test accounts, and insufficient XSS defenses (contextual output encoding, Content Security Policy, strict domain isolation, and secure token handling). Adopting defense-in-depth is essential for fleets that blend physical and digital operations.

Recommended controls include the principle of least privilege, MFA for administrative tasks, short-lived tokens bound to device and session, step-up authentication for critical changes, comprehensive audit logging of robot commands, network segmentation, and a zero trust posture. These align with recognized guidance from frameworks such as NIST SP 800-53, NIST SP 800-63 (digital identity), and ETSI EN 303 645 for consumer IoT security baselines.

On disclosure maturity, organizations should formalize coordinated vulnerability disclosure (CVD), publish a security.txt, maintain a dedicated intake channel, and consider a bug bounty to incentivize early reporting. These steps reduce time-to-mitigate and improve trust with researchers and customers.

With Pudu’s market share and broad deployment in hospitality and offices, timely remediation and a predictable security communications channel are critical to protecting operations and preserving confidence. Service-robot vendors should audit administrative consoles, retire or lock down test accounts, enforce strict RBAC, harden against XSS, and publicize clear reporting paths for security issues.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.