Quan algú ens diu que el seu parc de mòbils està al dia, la frase acostuma a voler dir que a Configuració hi apareix una data recent. Ahir es va publicar un treball que converteix aquesta data en una pregunta: Android pot portar dos nivells de pedaç el mateix mes, el segon és el que cobreix el mòdem, i el telèfon només mostra el que li hagin posat.
D'entrada, un avís: mantenim parcs informàtics i venem aquest servei, així que la part on diem que cal inventariar els terminals es llegeix amb la cella aixecada. La resta és a documents públics que qualsevol pot obrir, i hem posat els enllaços al final.
El que es va publicar el 17 d'agost
SSD Secure Disclosure va publicar el segon tram d'una cadena que va començar al març, quan el mateix investigador va ensenyar com executar codi al firmware del mòdem de diversos xips Unisoc enviant SDP mal format dins la senyalització SIP d'una videotrucada. El tram d'ahir va del mòdem al sistema: des del context del mòdem s'apaga la protecció de la primera regió de la unitat de protecció de memòria i a partir d'aquí hi ha lectura i escriptura sobre memòria física, inclòs el codi del kernel d'Android. La classificació és CWE-1189, «aïllament indegut de recursos compartits en un sistema en xip», i la frase de l'avís és tan seca com sona: des del context del mòdem no hi ha aïllament entre la memòria del mòdem i la del kernel.
Els xips que l'avís de març llista com a afectats són el T606, el T612, el T616 i el T7250. Per encadenar-ho sencer calen tres coses: el forat del març com a punt de partida, infraestructura de VoLTE controlada per qui ataca i que la víctima contesti la videotrucada. No hi ha pedaç ni mitigació publicada, i el mateix avís diu que han intentat contactar amb el fabricant «per correu electrònic i LinkedIn» sense rebre resposta.
Amb aquests requisits, això no és una campanya massiva. És material d'atac dirigit —exigeix presència a la xarxa de ràdio— contra algú que interessa molt. Nosaltres ens quedem amb una altra cosa, que és a la llista de telèfons amb què ho van provar.
Les dates dels tres telèfons de la prova
L'avís els enumera amb el seu nivell de pedaç: un Xiaomi Redmi A5 amb 2026-01-01, un Motorola E13 amb 2025-02-01 i un Realme C33 amb el pedaç de juliol del 2025. Els dos primers venen amb la data completa, i aquí hi ha el detall que gairebé ningú no mira: tots dos acaben en -01.
Aquest sufix no és el dia del mes. És el nivell. Google publica els butlletins complets amb dos —el 2026 els han portat els de març, abril i juny—, i explica el perquè sense embuts: «aquest butlletí té dos nivells de pedaç de seguretat perquè els socis d'Android tinguin la flexibilitat d'arreglar més ràpid un subconjunt de vulnerabilitats que són semblants a tots els dispositius Android». El primer nivell, el -01, cobreix les seccions Framework i System: allò comú a qualsevol Android, vingui d'on vingui el maquinari. El segon, el -05, hi afegeix el kernel i els components de proveïdor. Al butlletí de juny del 2026 aquesta llista és Imagination Technologies, MediaTek, Qualcomm i Unisoc.
Un nivell acabat en -01 és un terra, no un sostre. Per definició de Google declara Framework i System d'aquell mes més tot el dels butlletins anteriors, components de proveïdor inclosos; el que no declara és el kernel ni el mòdem d'aquell mes. I amb el Redmi A5 hi ha un detall encara millor: el butlletí de gener del 2026 no va arribar a publicar un nivell -01 amb contingut propi —només existeix el 2026-01-05—, i sobre aquesta cadena Google escriu que «en alguns dispositius amb Android 10 o posterior, l'actualització del sistema de Google Play tindrà una cadena de data que coincideix amb el nivell de pedaç 2026-01-01». És a dir: la data que mostra aquest telèfon pot no venir del butlletí en absolut.
Hi ha una segona lectura, més incòmoda, en aquestes mateixes dates. El Motorola E13 de la prova portava el nivell de febrer del 2025: divuit mesos abans del dia en què es va publicar el treball. El Realme, tretze. No sabem si el fabricant va deixar de publicar actualitzacions o si ningú no les va instal·lar, i les dues explicacions tenen el mateix efecte pràctic i el mateix propietari: algú que va comprar un telèfon i va donar la resta per feta.
Set al març, setze al juny
Aquí toca anar contra el titular fàcil, perquè Unisoc no està fora del sistema: té la seva secció als butlletins d'Android igual que Qualcomm i MediaTek. Al butlletí de març del 2026 hi ha set CVE d'Unisoc i els set són del subcomponent Modem, tots amb gravetat alta. Al de juny del 2026 en són setze, un altre cop tots del mòdem i tots alts. El mòdem es pedaça, encara que no cada mes: dels vuit butlletins del 2026, Unisoc apareix en dos, el de març i el de juny. Va per lots.
I precisament per això el cas d'ahir és interessant i no anecdòtic. Un forat amb CVE entra en un butlletí, té data, es pot buscar, apareix en qualsevol inventari de pedaços i algun dia es tanca sol. Un forat sense CVE, publicat per un tercer i amb el fabricant en silenci, no es creua contra cap catàleg, no dispara cap alerta i no té una versió que puguis exigir a ningú. Administrativament no existeix, i el que no existeix no es gestiona.
La solució ha de passar per tres mans
En un portàtil la cadena és curta: qui fa el sistema operatiu i qui fa l'equip. En un mòbil hi ha un esglaó més, i és el que mana aquí. Google recull i publica, però dels components de proveïdor diu literalment que «aquestes vulnerabilitats afecten components d'Unisoc i hi ha més detalls disponibles directament d'Unisoc» i que «la valoració de gravetat d'aquests problemes la proporciona directament Unisoc». Després, el fabricant del telèfon ha d'empaquetar això en una actualització i publicar-la. Tres mans, i n'hi ha prou que una no es mogui.
Hi ha una dada del butlletí que ajuda a calibrar terminis: Google avisa els seus socis de tots els problemes «almenys un mes abans» de publicar-lo. Aquest mes és la finestra en què el fabricant del terminal pot tenir l'actualització llesta el mateix dia. Quan no la té, el compte ja no es mesura en setmanes.
És la mateixa forma de problema que explicàvem amb qui pot apagar els teus servidors: l'empresa que decideix sobre el teu aparell no és la que et va vendre res. Allà era el propietari de la sala; aquí és qui fabrica un xip el nom del qual no apareix a la caixa del telèfon. En tots dos casos la palanca de pressió que un creu tenir —la factura— apunta a qui no pot resoldre.
Com entra aquest xip a la teva empresa sense que ningú ho decideixi
Ningú no tria un mòdem. Es tria un preu. Segons Counterpoint, Unisoc va pujar al 15 % del mercat mundial de xips de mòbil al quart trimestre del 2025, des del 14 % del mateix trimestre de l'any anterior, i va continuar creixent la primera meitat del 2026 mentre Qualcomm i MediaTek enviaven més d'un 25 % menys d'unitats que un any abans. L'explicació de la consultora és de manual de compres: la gamma d'entrada s'està desplaçant a plataformes 4G d'Unisoc per abaratir la llista de materials, i MediaTek va acusar el cop en 5G de gamma baixa per la crisi de preus de la memòria. Convé el context: el mercat sencer de xips va caure un 15 % interanual en aquell semestre.
Traduït a una empresa mitjana: el terminal de vuitanta o cent euros que es compra per a l'operari del magatzem, per a la furgoneta de repartiment, per al fitxatge o per al reforç de temporada. Aquest telèfon gairebé mai no passa per una decisió d'IT. Entra per una factura de material fungible, se li posa una línia i ja està treballant. I com que està treballant, té correu.
L'altra meitat de l'assumpte és per on va aquest telèfon. La cadena d'ahir necessita que qui ataca controli la infraestructura de VoLTE, i això empeny la conversa al mateix lloc on la vam deixar en parlar de l'APN privada de l'operador: la xarxa mòbil es contracta com si fos un cable i en realitat és una xarxa amb veïns, amb equips intermedis i amb configuració que algú va decidir per tu.
Abans que algú et vengui una auditoria
Si la flota són iPhone i gamma mitjana de Samsung, aquesta cadena concreta no et toca i no fingirem el contrari per vendre una revisió. Tampoc no et toca si els mòbils no porten res de l'empresa a dins. I si algú t'ofereix avui una auditoria de seguretat mòbil citant aquesta notícia, la pregunta correcta és què mirarà exactament, perquè contra aquest forat no hi ha pedaç per aplicar ni ajust per corregir: només hi ha saber què tens.
Tampoc no recomanaríem retirar telèfons en funcionament per això. L'escenari demana massa coses alhora. El que sí que recomanaríem és que el pròxim lot es compri mirant quants anys d'actualitzacions promet el fabricant, una dada pública que acostuma a ser a la mateixa pàgina que els megapíxels de la càmera i a la qual ningú no fa cas.
Cinc coses que sí que valen la pena
- 1.Mira la data sencera, no el mes. És a Configuració → Quant al telèfon → Versió d'Android → Actualització de seguretat d'Android. Si acaba en
-01, aquest terminal no declara res sobre el mòdem, el kernel ni la GPU d'aquell mes. - 2.I mira-ho a escala, no telèfon per telèfon. La propietat es llegeix amb
adb shell getprop ro.build.version.security_patch, i si hi ha gestió de dispositius la mateixa dada viatja com a camp d'inventari. Una columna en un full val més que trenta captures de pantalla. - 3.Afegeix a l'inventari de mòbils el model i la data de fi d'actualitzacions. La segona decideix quan es retira l'aparell, i és la que ningú no apunta el dia de la compra perquè aquell dia sembla una dada de fullet.
- 4.Decideix qui pot comprar un telèfon que portarà correu d'empresa. És una línia al procediment de compres, no una política de seguretat, i si un terminal pot entrar sense passar-hi, la resta d'aquesta llista sobra.
- 5.Separa els terminals de tasca dels de persona, i si algun fa servir un dels xips citats i viatja a llocs delicats, apaga-hi VoLTE i VoWiFi mentre no hi hagi solució. Un mòbil de magatzem no necessita bústia ni documents: el que no és al telèfon no s'ho endú qui hi entri.
La tercera llista
Fa uns dies escrivíem, arran d'un forat en la compartició de pantalla de macOS, que gairebé tota empresa té la llista dels seus equips i gairebé cap la de què escolta des de fora. Aquest cas n'hi afegeix una tercera, la més rara de totes: de què està fet el que tens. El xip abans que el model, i qui publica les seves correccions i fins quan abans que la marca de la caixa.
Ningú no mantindrà aquesta llista per a cada torradora de l'oficina, i no cal. Cal per al que porta una targeta SIM, una adreça IP pública o dades de clients, que acostuma a ser molt menys del que un tem i força més del que un recorda.
Fonts (verificades el 18 d'agost del 2026): la cadena publicada el 17 d'agost del 2026, la classificació CWE-1189, l'absència d'aïllament entre memòria del mòdem i del kernel, l'apagada de la protecció de la primera regió (ID 0) de la MPU, els xips T606, T612, T616 i T7250 llistats com a afectats, els dispositius de prova amb el seu nivell de pedaç (Xiaomi Redmi A5 amb 2026-01-01, Motorola E13 amb 2025-02-01 i Realme C33 amb el pedaç de juliol del 2025), el requisit d'infraestructura VoLTE controlada per l'atacant i que la víctima contesti la videotrucada, i la frase «hem intentat posar-nos en contacte amb el proveïdor a través de múltiples canals (correu electrònic i LinkedIn) però no hem pogut rebre resposta», dels avisos «UNISOC T612 LPE» i «UNISOC T612 RCE» (SSD Secure Disclosure), amb la cobertura de The Hacker News del 17 d'agost del 2026. Els dos nivells de pedaç i el seu contingut, la cita «aquest butlletí té dos nivells de pedaç de seguretat perquè els socis d'Android tinguin la flexibilitat d'arreglar més ràpid un subconjunt de vulnerabilitats que són semblants a tots els dispositius Android», l'avís als socis «almenys un mes abans» de la publicació, les setze entrades d'Unisoc del subcomponent Modem amb gravetat alta i les frases sobre que els detalls i la valoració de gravetat els proporciona directament Unisoc, del Android Security Bulletin de juny del 2026; les set entrades d'Unisoc del subcomponent Modem, del butlletí de març del 2026; i la frase «en alguns dispositius amb Android 10 o posterior, l'actualització del sistema de Google Play tindrà una cadena de data que coincideix amb el nivell de pedaç 2026-01-01», del butlletí de gener del 2026, que només va publicar el nivell 2026-01-05 (Android Open Source Project). El recompte de en quins butlletins del 2026 apareix Unisoc i en quins es van publicar els dos nivells és nostre, fet sobre aquestes mateixes pàgines. La quota del 15 % al quart trimestre del 2025 enfront del 14 % de l'any anterior surt del seguiment trimestral de quota AP-SoC de Counterpoint Research; el creixement d'Unisoc a la primera meitat del 2026, la caiguda de més del 25 % interanual en enviaments de Qualcomm i MediaTek, la migració de la gamma d'entrada a plataformes 4G d'Unisoc per abaratir la llista de materials i la caiguda del 15 % del mercat, de la seva anàlisi del primer semestre del 2026. La lectura del sufix -01 als dispositius de la prova, el càlcul dels divuit i tretze mesos de retard, la distinció entre un forat amb CVE i un sense, i totes les recomanacions són nostres. Les cites en català de textos originalment en anglès són traducció nostra. No hem trobat, a 18 d'agost del 2026, cap comunicat d'Unisoc sobre aquest treball ni un CVE assignat.
Saps de què estan fets els teus terminals?
Al manteniment informàtic que prestem, l'inventari és la font de veritat: model, versió i data en què cada cosa deixa de rebre correccions. I el lloc de treball modern inclou decidir què porta dins cada telèfon, no només quin es compra.
Parlar amb everyWAN