Mobile-app database tampering to root code execution

1. Summary

The Unitree Go2 quadruped robot runs an actuator_manager.py service that executes user-authored Python “programs” as root without any integrity or content validation [2][5]. Those programs originate from an SQLite database inside the companion Android app (com.unitree.doggo2), where an attacker with local access to a rooted phone can rewrite the stored Python before it reaches the robot [1][3]. When the operator triggers the associated controller keybinding, the injected code runs as root on the robot and persists across reboots [3]. The same trust gap enables a supply-chain variant in which a trojanized program shared through the app’s community marketplace executes as root on any robot that imports and runs it [2].

2. Affected products & versions

3. The vulnerability in detail

The defect lives at the boundary between the Go2’s Android companion app and the robot’s on-board program-execution pipeline. On the robot, a service named actuator_manager.py is responsible for running “programs” — small blocks of Python that operators author in the mobile app to script the robot’s behavior. Program scripts are staged on the robot under /unitree/etc/programming/, and when a program is invoked, actuator_manager.py executes it by spawning subprocess.Popen(['python3','program_uuid.py']) as root, with no restrictions, no timeouts, and no resource limits [3]. Critically, the robot performs no integrity verification and no content validation on the Python it receives before running it. It implicitly trusts the Android app — and, transitively, the app’s local storage and the community marketplace — as an authenticated, trustworthy source of code [2][5]. This is the root cause: an execution path that treats attacker-influenceable data as trusted code and runs it at the highest privilege on the device.

The program content originates on the Android side. Programs authored in the Go2 app are stored as JSON in the programme_text column of the dog_programme table inside the SQLite database at /data/data/com.unitree.doggo2/databases/unitree_go2.db [3]. Within that JSON is a pyCode field holding the actual Python to run [3]. Programs are bound to persistent controller hotkeys — L1+Y, L2+Y, and R1+Y — via a hotkey_list.txt mapping, and those bindings survive reboots [3]. The SQLite store has no integrity protection of its own, so any modification of the pyCode field is silently accepted and later trusted by the robot [1]. The weakness is classified CWE-345, Insufficient Verification of Data Authenticity: the system consumes data (here, executable Python) from a source whose authenticity and integrity it never checks, so it cannot distinguish an operator’s legitimate program from an attacker’s tampered one [1]. Because the untrusted data is code executed as root, the impact is maximal.

Two distinct trust failures compound here, and it is worth separating them. The first is on the Android app: it persists executable Python in a plain SQLite database with no signing, checksum, or tamper detection, so the pyCode payload is fully rewritable by anyone with file access [1][3]. The second is on the robot: actuator_manager.py never re-establishes trust in the payload before running it — there is no signature check, no allowlist, no sandbox, and no privilege drop, so whatever Python arrives is executed verbatim as root [2][5]. Either failure alone would be serious; together they form an unbroken path from “attacker can edit a database row on a phone” to “attacker runs arbitrary code as root on a physical robot.” The marketplace vector exploits exactly the same robot-side failure from a different origin: instead of tampering with a local database, the attacker publishes malicious pyCode upstream, and the robot still runs it without validation once an operator imports it [2].

It is worth being precise about where the trust boundary is crossed. The Android app is, in effect, an untrusted code-authoring surface that the robot treats as trusted: the app never establishes that the pyCode it forwards is the same code the operator legitimately authored, and the robot never re-checks it on receipt. Sources describe the pyCode payload as “transmitted” to and “received” by actuator_manager.py, but the exact protocol/channel between app and robot is not specified in the available material; what is documented is that whatever arrives is run without validation [2][3][5]. This matters because it means the vulnerability is not narrowly about SQLite — SQLite is merely the most convenient tampering point on the local vector. The invariant that is missing is authenticity of executable content at the moment of execution on the robot, and that invariant is absent regardless of whether the malicious code arrived via a locally edited database row or a marketplace download.

The primary exploitation chain (local tampering) proceeds as follows [3]:

1. The attacker obtains access to a rooted Android phone running the Unitree Go2 app. In the research this was a Magisk-rooted device with USB debugging / ADB enabled.
2. The app’s SQLite database is extracted via ADB: adb shell su -c 'cp /data/data/com.unitree.doggo2/databases/unitree_go2.db /sdcard/unitree_go2.db' followed by adb pull.
3. The pyCode field inside the programme_text JSON of the dog_programme table is rewritten using the researcher’s modify_db_v1.1.11_rce.py utility (which takes --db, --programme, and --pycode arguments), injecting an arbitrary payload — for example a Python reverse shell built from socket connect, os.dup2, and pty.spawn('bash') calling back to the attacker host on port 1337.
4. The tampered database is pushed back and its ownership/permissions restored so the app accepts it: adb push, copy into the databases directory, chown u0_a215:u0_a215, chmod 660, and remove the stale -wal write-ahead-log file.
5. The operator later triggers the associated controller keybinding (L1+Y / L2+Y / R1+Y), at which point actuator_manager.py executes the injected Python as root on the robot. The malicious binding persists across reboots.

There is an alternative supply-chain path that does not require rooting anyone’s phone: an attacker publishes a trojanized program to the app’s community marketplace, and any robot whose operator imports and runs that shared program executes the attacker’s Python as root [2][5].

Preconditions differ by vector. The local-tampering vector requires physical access to the operator’s phone, that phone being rooted, ADB/USB debugging access, read/write access to the database file, and — importantly — the operator subsequently triggering the modified program via a controller keybinding (user interaction is required; this is not a fully unattended exploit) [3]. Network connectivity is needed only for the reverse-shell callback, not for the code injection itself [3]. The marketplace vector requires only that a victim imports and runs a malicious shared program [2].

Proof-of-concept status is public. The Boschko researcher writeup publishes the working modify_db_v1.1.11_rce.py database-tampering utility and a demonstrated reverse-shell payload [3].

4. Discovery & timeline

The vulnerability was discovered by Olivier Laflamme (Boschko) and Ruikai Peng [2]. Per the researcher writeup, the database-modification RCE was discovered on 2025-10-30; Unitree validated and reproduced the exploit on 2025-11-18; and a patch was deployed in V1.1.13 on 2026-02-24, at which point Unitree also added strict review criteria to vet uploaded marketplace scripts [3]. The VulnCheck CNA advisory was published 2026-02-26, and the NVD record was published 2026-02-26 (last modified 2026-06-17) [2][1].

5. Technical reference

• CVE: CVE-2026-27510 [1]
• CWE: CWE-345 — Insufficient Verification of Data Authenticity [1]
• CVSS (as published by each source):
• NIST (NVD): CVSS v3.1 8.8 HIGH [1]
• VulnCheck (assigning CNA): CVSS v3.1 9.6 CRITICAL and CVSS v4.0 6.4 MEDIUM [1]
• GitHub Advisory (GHSA-c2p8-28pf-f3mr): Moderate, CVSS 6.4 [4]
• Metric-terminology note (not a severity argument): the v3.1 records use UI:R (“user interaction required”) to capture that the operator must trigger the keybinding. CVSS v4.0 does not have UI:R; it replaces the binary with UI:N/P/A (None/Passive/Active), so the operator-triggered action maps to the Active value (UI:A) rather than UI:R. The two versions are therefore not directly comparable on the user-interaction axis. The severity-weighting question — how much the local-access and user-interaction preconditions should lower the score, and why the published numbers range from 6.4 to 9.6 — is deferred to §6, which is where consequence and severity reasoning belong.
• Code / commit refs: no vendor commit hashes published. Researcher PoC tooling: modify_db_v1.1.11_rce.py [3]. Key on-device artifacts: actuator_manager.py, /unitree/etc/programming/, hotkey_list.txt [3]. Key app artifacts: unitree_go2.db → dog_programme → programme_text (JSON) → pyCode [3].
• Assigning CNA: VulnCheck [1].

6. Consequence & CFSE path analysis

Real-world consequence: a successful exploit gives the attacker root code execution on a physical legged robot. That has two distinct real-world effects. First, root control of actuator_manager means control over motion and actuation — the robot can be driven to move or actuate in unsafe ways, which can endanger bystanders near the device. Second, that same root foothold exposes the robot’s live camera feed and spatial-sensor state, revealing the people and physical environment around the robot.

Why the CFSE Path Score differs from CVSS: CVSS collapses everything into one severity number keyed to the access mechanics of the bug (attack vector, privileges, user interaction). That access-centric framing is exactly why the published CVSS numbers span 6.4 to 9.6: the disagreement is over how heavily to weight the local-access and user-interaction preconditions, which pull the score down, versus the root-level code-execution impact, which pushes it up. The CFSE analysis instead decomposes the vulnerability into distinct consequence paths and scores each by what it does in the world, then takes the worst path as the verdict. That is why CFSE lands on CRITICAL even though CVSS opinions range from 6.4 to 9.6: the dominant CFSE path is the privacy consequence, which CVSS’s access-centric scoring does not foreground.

Legend for the CFSE seed-band factor codes used below (each is a per-path band the verdict is derived from):

• EC — Exploitation Complexity / precondition burden (higher = more preconditions, harder).
• PH — Physical/access proximity required (higher = more physical or local access needed).
• AT — Attacker capability/tooling required (higher = more skill/tooling).
• DP — Data/privacy exposure magnitude (higher = more sensitive exposure).
• SR — Systemic root-cause severity (higher = deeper/more structural defect).
• SX — Spread/wormability (higher = more self-propagating; 1 = per-device).
• OR — Operational recovery burden (higher = more coordinated recovery needed).
• LS — Lifecycle state (e.g. PATCH_AVAILABLE = a fix exists).

CFSE consequence bands and verdict:

• DEVICE_CONTROL_SAFETY (safety) path — banded HIGH. Tampering the companion-app SQLite database to inject Python that runs as root via actuator_manager yields motion control and unsafe actuation that can endanger bystanders. It is not a demonstrated injury and requires a rooted operator phone plus the operator triggering the modified keybinding (EC:2, PH:3, AT:3).
• PERCEPTION_PRIVACY (privacy) path — banded CRITICAL, dominant. The same root execution grants access to the robot’s live camera feed and spatial-sensor state (DP:4), exposing people and places around the device.
• Shared factors: both paths share the systemic root cause of missing robot-side content validation (SR:3), are per-device rather than wormable (SX:1), and require coordinated operational recovery with a vendor patch available (OR:3, LS:PATCH_AVAILABLE).

Overall path_verdict: CRITICAL, taken from the worst (dominant privacy) path, with direction SIDEWAYS.

7. Remediation & mitigations

• Apply the firmware update. Update to V1.1.13, which the researcher writeup states was deployed on 2026-02-24 [3]. (Note the fixed-version claim is not uniformly corroborated — so verify availability directly with Unitree for your device.)
• Marketplace review criteria. With V1.1.13 Unitree added strict review criteria to vet uploaded marketplace scripts, reducing the supply-chain vector [3].
• Interim workarounds (specific to this bug):
• Use only locally created programs on trusted, non-rooted devices; do not run programs imported from the community marketplace until patched [5].
• Verify the app’s SQLite database (unitree_go2.db, dog_programme table) has not been tampered with before triggering stored programs [5].
• Restrict physical/ADB access to any phone paired with a robot: disable USB debugging, keep the device non-rooted, and treat a rooted paired phone as a compromised program source since the local vector hinges on write access to unitree_go2.db [3].
• Watch for unexpected new or altered persistent hotkey bindings (L1+Y, L2+Y, R1+Y) in hotkey_list.txt, since a tampered program installs a binding that survives reboots and is the trigger the attacker relies on [3].
• The structural fix: the robot must perform integrity/authenticity validation of program content before executing it as root — e.g., signing/verifying program payloads and/or refusing to run app-supplied Python at root privilege (dropping privileges or sandboxing actuator_manager.py’s subprocess.Popen execution) — since the defect is that actuator_manager.py trusts unauthenticated code [2][5].
• Detection specific to this flaw: look for unexpected modifications to pyCode in the dog_programme table, unexpected persistent hotkey bindings in hotkey_list.txt, unexpected scripts under /unitree/etc/programming/, and outbound connections from the robot (the demonstrated payload calls back to an attacker host on port 1337) [3].

8. Sources

[1] NVD — CVE-2026-27510 — NVD / NIST — https://nvd.nist.gov/vuln/detail/CVE-2026-27510 — Authoritative CVE record: CWE-345, dual CVSS v3.1 scores (NIST 8.8, VulnCheck 9.6) and v4.0 6.4, affected version range, confirms VulnCheck as CNA. Credibility: primary advisory.

[2] Unitree Go2 Mobile Program Tampering Enables Root RCE — VulnCheck Advisory — VulnCheck (assigning CNA) — https://www.vulncheck.com/advisories/unitree-go2-mobile-program-tampering-enables-root-rce — CNA advisory describing actuator_manager.py executing supplied Python as root without validation, the marketplace vector, CVSS v4.0 6.4, and affected firmware. Credibility: primary advisory.

[3] Unitree Go2 Robot RCE (CVE-2026-27509 & CVE-2026-27510) — Olivier Laflamme (Boschko) and Ruikai Peng — https://boschko.ca/unitree-go2-rce/ — Original researcher writeup and PoC: exact DB path, table/column/field, ADB extract-modify-reinstall workflow, hotkeys, modify_db_v1.1.11_rce.py, reverse-shell payload, and the disclosure timeline / fixed version. Credibility: researcher-primary.

[4] GHSA-c2p8-28pf-f3mr — Unitree Go2 firmware advisory — GitHub Advisory Database — https://github.com/advisories/GHSA-c2p8-28pf-f3mr — GHSA mirror: affected versions 1.1.7–1.1.11 with the Android app, Moderate (CVSS 6.4), missing-integrity-protection description, persistence and marketplace-propagation details. Credibility: primary advisory.

[5] CVE-2026-27510: Unitree Go2 Firmware RCE Vulnerability — SentinelOne Vulnerability Database — https://www.sentinelone.com/vulnerability-database/cve-2026-27510/ — Aggregated summary of the actuator_manager root-execution mechanism and remediation notes; states no official patch existed at its publication and advises avoiding marketplace programs. Credibility: reputable press.

[6] CVE-2026-27510 — Tenable — https://www.tenable.com/cve/CVE-2026-27510 — Independent vendor record reproducing NVD description and CVSS scoring for corroboration. Credibility: reputable press.

[7] Unitree Go2 — The robot dog that obeys everyone — Korben — https://korben.info/en/unitree-go2-robot-dog-security-vulnerabilities-cve.html — Technical press contextualizing this CVE alongside CVE-2026-27509 and the real-world safety/marketplace risk. Credibility: reputable press.