Hardcoded Keys Exposed Every Rabbit R1 Device
On this page
Every device shared the same secrets, because the secrets were sitting in the code.
| When | June 2024 |
|---|---|
| Target | Rabbit R1 (AI device) |
| Researcher | 'rabbitude' collective |
| Cause | Hardcoded third-party API keys in the codebase |
| Impact | Access to every device's TTS history; ability to alter responses / brick units |
- 1Researchers obtain and read the Rabbit R1 codebase
- 2They find hardcoded API keys for ElevenLabs, Azure, Google Maps and more
- 3The keys give access to every device's data and the ability to tamper with it
What happened
In June 2024, the 'rabbitude' collective reported finding hardcoded API keys — ElevenLabs, Azure, Yelp and Google Maps (Rabbit later confirmed a SendGrid key too) — embedded in the codebase of the Rabbit R1 AI device. The access was broad enough to read every device's text-to-speech history and to alter responses or brick units. Rabbit began rotating the keys on 25 June and said no customer data was exposed; it later said an employee had leaked the code, and that the only abuse it found was emails sent to staff and journalists.
How it happened
The R1, like many AI products, stitches together several hosted APIs (voice, maps, email). Their credentials were embedded directly in source code rather than a secrets store, so anyone who read the codebase held keys that worked against the whole fleet.
Root cause
Third-party secrets hardcoded in source code — turning one leaked repository into a fleet-wide exposure.
What a review would have caught
Secret-scanning the repository, and a basic threat model of 'what can someone with a copy of our code do?', surfaces embedded credentials before they leak.
How to prevent it
- Keep third-party secrets out of source code; load them from a secrets manager at runtime.
- Scope and rotate keys; scan builds for embedded credentials.
- Assume source code can leak — Rabbit says an employee leaked this one.
FAQ
What could the exposed keys do?
They reached core third-party services the device depends on — e.g. the ElevenLabs voice API, exposing every R1's text-to-speech history — and gave enough control to tamper with responses or brick devices.
Why is this an AI-specific lesson?
AI hardware and apps stitch together many hosted model/voice/map APIs, and their keys often end up hardcoded in source. One leaked key can compromise the entire fleet's data and behaviour.
How do you prevent it?
Keep third-party secrets out of source code and load them from a secrets manager, scope and rotate keys, and scan repositories for embedded credentials.