CFSE.ai
Original researchCVE-2026-27510 — boschko.ca
CFSE retrospectiveCFSE.ai
CFSE
RETRO
SPECTIVE

→ This is a methodology demonstration, not a vulnerability disclosure. We modeled how CFSE would have structured the thinking around a publicly reported exploit. No new vulnerability is claimed. No original discovery is implied.

CFSE Retrospective 001 / Unitree Go2

How CFSE would have modeled the Go2 root exploit.

One public vulnerability. Five authority handoffs. This retrospective applies CFSE artifacts — Concepts, Entry Points, Invariants, Scenarios, Traces, Findings — to a vulnerability discovered and reported by others. The goal is not to claim the discovery. It is to show what CFSE makes inspectable that a prose report leaves implicit.

Follow the authorityRead the original report
Authority pathFive transformations

The vulnerability is not one bad function. It is authority changing meaning as it crosses the system.

Public evidence
Confirmed

The published technical report describes the complete tamper-to-execution sequence.

CFSE structure
Modeled

We reconstructed how CFSE would have represented the sequence — scenario, exploration, trace, and finding.

What CFSE adds
Visible

CFSE makes the authority handoffs, violated invariant, and evidence boundaries inspectable — things a prose report leaves implicit.

Local reproduction
Not executed

The current corpus has no live Go2 target or faithful local harness. The retrospective is a model, not an experiment.

The retrospective

What must be true for code stored on a phone to become trusted behaviour on a robot?

A database edit sounds local. A controller keypress sounds intentional. A Python file on the robot sounds like a different subsystem entirely. The security failure appears when we preserve the chain between them. The original researchers at boschko.ca discovered this chain. CFSE makes it inspectable.

The authority journey

Five ordinary operations. One extraordinary grant.

Each step looks legitimate in isolation. Below, each stage separates what the researchers found from how CFSE models it — showing the artifacts and invariants that make the authority handoffs inspectable.

Android phone#programme-record
What the researchers found

The content changes. Its identity does not.

A rooted phone modifies the stored Python programme text.

UPDATE dog_programme
SET programme_text.pyCode = <tampered_python_payload>
Source: boschko.ca/unitree-go2-rce
CFSE modeling

CFSE models this as a violation at the Entry Point layer. The programme record (C-GO2-PROGRAMME-RECORD) has an invariant INV-GO2-CONTENT-INTEGRITY that requires content identity to be verifiable. The first authority break is not execution — it is the loss of trustworthy content identity, and CFSE makes this inspectable by separating the Concept from its invariants.

C-GO2-PROGRAMME-RECORDConceptINV-GO2-CONTENT-INTEGRITYInvariant
Companion workflow#controller-binding
What the researchers found

The changed programme inherits a trusted gesture.

The stored programme is remapped to a physical controller hotkey.

REMAP stored_program → controller_keybinding
Source: boschko.ca/unitree-go2-rce
CFSE modeling

In CFSE terms, an Interaction (I-GO2-PROGRAMME-TO-CONTROLLER) carries unapproved content into a trusted pathway. The controller binding is modeled as an Entry Point (EP-GO2-CONTROLLER-BINDING) that should require content approval but doesn't. CFSE makes this gap explicit: the Interaction exists, but the invariant that should govern it is absent.

I-GO2-PROGRAMME-TO-CONTROLLERInteractionINV-GO2-BINDING-REQUIRES-APPROVALInvariant (missing)
Robot runtime#robot-materialization
What the researchers found

A record becomes an executable file.

The robot writes the Python payload and updates its hotkey list.

WRITE /unitree/etc/programming/<program>.py
WRITE /unitree/etc/programming/hotkey_list.txt
Source: boschko.ca/unitree-go2-rce
CFSE modeling

CFSE models this as a Flow crossing a trust boundary. The Flow (F-GO2-PROGRAMME-SYNC-TO-ROBOT) moves data from the companion domain into the robot domain. The Entry Points (EP-GO2-FS-WRITE) on the robot filesystem accept content without verifying its provenance. CFSE preserves this handoff as a traceable step rather than letting it dissolve into 'the robot received the programme.'

F-GO2-PROGRAMME-SYNC-TO-ROBOTFlowEP-GO2-FS-WRITEEntry Point
Controller#physical-trigger
What the researchers found

A normal keypress crosses the boundary.

The operator presses the controller key bound to the programme.

EXECUTE controller_keypress → bound_hotkey
Source: boschko.ca/unitree-go2-rce
CFSE modeling

CFSE's Scenario (S-GO2-RUNTIME-TAMPERED-PROGRAM-EXECUTION-GRANT-001) frames the keypress as a confused deputy: a legitimate physical input activates content whose integrity was never bound to the approval decision. The controller's Entry Point (EP-GO2-CONTROLLER-KEYPRESS) is governed by no invariant that checks the content it triggers. CFSE makes the absence of that invariant — not just the keypress — the security finding.

S-GO2-RUNTIME-TAMPERED-PROGRAM-EXECUTION-GRANT-001ScenarioINV-GO2-EXECUTION-REQUIRES-APPROVED-CONTENTInvariant
Programming actuator#root-execution
What the researchers found

Programme authority becomes root authority.

The Python payload launches with root-level execution.

LAUNCH root_python_payload
Source: boschko.ca/unitree-go2-rce
CFSE modeling

The Finding (FD-GO2-RUNTIME-UNSIGNED-PROGRAMME-RECORD-CAN-REACH-EXECUTION-001) captures the culmination: modified content arriving at a root-level interpreter. CFSE traces the full authority lineage — from the phone's local database through five transformations to root execution. The repair binds three invariants together: content digest, controller mapping, and runtime context. Change any one and the approval no longer applies.

FD-GO2-RUNTIME-UNSIGNED-PROGRAMME-RECORD-CAN-REACH-EXECUTION-001FindingPATCH-GO2-CONTENT-ADDRESSED-APPROVALPatch

The violated invariant

The rule that broke

Execution authority must follow the exact approved programme—not merely its name.

A staged programme may receive execution capability only when an explicit approval decision exists for that exact content and runtime context.
approvedigest(programme) + controller mapping + runtime contextgrant

Why it matters

The exploit crossed three kinds of authority.

01

Approval drift

The system preserves the programme's recognizable identity while losing integrity over the content that identity represents.

02

Confused physical authority

A legitimate controller input becomes the trigger for content that was never bound to a trustworthy approval decision.

03

Privilege collapse

A companion-side data edit crosses multiple trust boundaries and arrives at a root-level robot interpreter.

Claim by claim

Evidence ledger

CFSE does not turn a published report into a local experiment. It makes the boundary between those things inspectable.

Public reportCVE-2026-27510 technical report
PUBLISHEDPrimary evidence

Describes the tamper, remap, robot file writes, controller trigger, and root-level result.

ScenarioS-GO2-RUNTIME-TAMPERED-PROGRAM-EXECUTION-GRANT-001
DRAFTFalsifiable question

Asks whether tampered content can receive execution capability without trustworthy approval.

ExplorationE-GO2-RUNTIME-TAMPERED-PROGRAMME-RECORD-001-01
BLOCKEDValidation runbook

Not executed: the current workspace has no live Go2 or local harness.

TraceT-GO2-RUNTIME-PROGRAMME-RECORD-TO-EXECUTION-CAPABILITY-001
DRAFTOrdered reconstruction

Structures the event order distilled from the public report; it is not a local capture.

FindingFD-GO2-RUNTIME-UNSIGNED-PROGRAMME-RECORD-CAN-REACH-EXECUTION-001
DRAFTBounded conclusion

Documents the public evidence posture and explicitly disclaims local re-confirmation.

Repair the authority chain

Make approval content-addressed.

A trustworthy grant binds all three facts. Change any one of them and the approval no longer applies.

01

Exact programme digest

Approve the immutable content that will actually execute.

02

Controller mapping

Bind the approved content to the intended physical trigger.

03

Bounded runtime context

Grant only the execution authority the programme was approved to receive.

Only thenExecution granted

From retrospective to investigation

What would complete this as a live CFSE investigation?

  1. 01Provision a faithful harness or an authorized live Go2 target.
  2. 02Capture the approved baseline programme path — the legitimate Exploration baseline.
  3. 03Repeat with mutated content and preserve the resulting Trace.
  4. 04Re-evaluate both invariants from captured evidence and promote the Finding to CONFIRMED.

Until then, the CFSE exploration remains BLOCKED. The public report is evidence. The CFSE model is a reconstruction. Neither is a local experimental result.

Have a Go2 or a comparable robotics target? Bring it to an Attify CFSE workshop and run the exploration for real.

Train with CFSE