Researcher gets a shell on Meta Ray-Ban smartglasses, reports it to Meta's bug bounty

An anonymous security researcher who blogs at p0pcycle.com describes how they achieved arbitrary code execution and an interactive shell on Meta smartglasses. The project started in July, when the author wanted to check that year's Pwn2Own targets and, since the rules had not been published yet, looked at the prior year's targets instead. A friend warned that these glasses are usually well hardened and that nobody had attempted them at Pwn2Own the year before; the author's reply was simply "Watch me." The glasses used for testing were borrowed for a few weeks from the author's brother-in-law, who did not use them much; a section heading jokes that the glasses cost around €500, which the author did not pay.

Rather than opening the hardware, the author obtained the firmware by reverse-engineering the companion Meta AI app, which handles pairing, photo and video syncing, and firmware updates. By instrumenting the app with the Frida dynamic-instrumentation tool, the author was able to intercept the app's internal update logic and recover the download link for the firmware package from Meta's content delivery network. The first package obtained this way was only a partial, incremental update of around 156 MB, tied to the specific device's existing software version. Further analysis of the app uncovered an internal option that, when toggled, caused the app to request the full firmware image instead of an incremental one; extracting and unpacking that full image yielded the underlying Android system files needed to continue the research.

The actual route to running custom code on the glasses went through Meta's Device Access Toolkit (DAT), a developer framework that lets authorized apps install a companion application on the glasses to interact with them. The author found that, through firmware version 126 inclusive, the glasses did not verify that this companion application was actually signed by Meta, which meant any app, including a self-signed one created by the author, could be installed and executed on the device. Getting that custom application to run reliably was complicated by the glasses having no screen, console or error output, so the author used the device's tone generator to encode debugging information as audible beep patterns, distinguishing stages such as a listener starting, a network peer being found, a shell connection being established, or an error occurring. The custom application ultimately opened a listening port that the author could connect to over the glasses' local Wi-Fi Direct network, dropping into a command shell running with ordinary app-level privileges, not root. The author had this access for about five days while searching, unsuccessfully, for a way to escalate privileges, before the access stopped working; the author speculates this was either their own lapse in operational security or that Meta had detected and patched the issue.

Meta later shipped firmware version 127, which began enforcing the missing signature check on the companion application, closing the original route. The author then found a second weakness: feature flags for the glasses are delivered in a configuration file that the glasses' companion phone app fetches from Meta's servers and relays to the glasses, and the glasses only check that this file is structurally valid, not that it has not been altered in transit from the phone. That meant the specific flag controlling signature enforcement could itself be modified by anything with control of the phone side of that relay, which the author used to re-enable the original bypass and reinstall a self-signed application even on the patched firmware.

The author reported the findings to Meta through its bug bounty program. After some back and forth over the payout, the author accepted Meta's offer. Meta subsequently approved publication of the blog post, which the author takes as a sign that the underlying issues have since been fixed, though the post does not state this as confirmed. The author notes that, having obtained shell access, further mapping of the glasses' attack surface followed, but says that is a story for another post.

Key facts

A researcher got arbitrary code execution and an app-level interactive shell on Meta smartglasses, reachable by connecting to a port the implanted app opened over the glasses' local Wi-Fi Direct network.
Through firmware 126 inclusive, the glasses did not verify that the installable companion application (via Meta's Device Access Toolkit) was actually signed by Meta, letting a self-signed app run on the device.
Firmware 127 added that signature check, but the author found a separate weakness in how the glasses' configuration file is relayed from the paired phone, letting the signature check itself be disabled again.
The shell access, obtained with no screen or logs on the device (the author debugged by encoding progress as audible beeps), ran at app-level privilege for about five days before it stopped working; root access was never achieved.
The findings were reported through Meta's bug bounty program; after disputing the payout, the author accepted Meta's offer, and Meta approved the blog post, which the author takes as an informal sign of a fix.

Why it matters

The case shows that even a device with no screen, no accessible console and a hardened reputation can still be probed and compromised through its software update and companion-app channels rather than through hardware teardown, and that a signature check added to close one hole can be undermined if the configuration data feeding that check is itself trusted without integrity checks.

Who it affects

It affects Meta and owners of its smartglasses, since the flaws concerned how the device's firmware and companion applications were verified; it is also a cautionary example for any company shipping a wearable or IoT device paired with a companion phone app that relays configuration or update data to the device.

How to use it

There is no product or service to adopt here; this is a disclosed security finding, reported through Meta's bug bounty program, with no payout figure, CVE number or patch date given in the account.

How solid is it

The account comes directly from the researcher who did the work and reported it to Meta, with Meta reportedly approving the post for publication; however, the researcher is not named, no CVE or Meta advisory is cited, and the claim that the issue is now fixed is the author's own inference from Meta's approval of the post rather than a confirmed statement from Meta.

Risks and caveats

The access achieved was limited to an ordinary app-level user, not root, and the author's attempt to escalate privileges did not succeed before access was lost; the method also required a paired phone running a hooked version of the Meta AI app and a Wi-Fi Direct connection to the glasses, rather than any remote or drive-by attack, and the source does not say whether firmware after version 127 or the configuration-relay weakness have since been fixed.

“ooof good luck. These are usually pretty hardened and no-one attempted them last year at p2o.”

— the author's friend, quoted in the blog post