Google ha arreglat 1.072 errors del Chrome amb IA: el coll d'ampolla ara ets tu

Google ha corregit 1.072 errors de seguretat en dues versions del Chrome, més que en les vint-i-tres versions anteriors juntes. El titular és espectacular i, per a la teva empresa, gairebé irrellevant: la immensa majoria d'aquests errors no els estava explotant ningú. El que sí que t'afecta és el ritme al qual començaran a caure't les actualitzacions a sobre —el Chrome està pilotant dues publicacions de seguretat per setmana, i des del setembre publica una fita cada dues setmanes—. Això no és una notícia sobre intel·ligència artificial. És una notícia sobre el teu calendari.

Els números es van publicar el 30 de juliol al blog de Google. El Chrome 149 i el Chrome 150, tots dos del juny, van sumar 1.072 errors corregits; TechCrunch xifra en 1.036 els de les vint-i-tres fites anteriors, repartits al llarg de dos anys. Amb el Chrome 151 al damunt, les tres últimes versions acumulen 1.442 correccions, i l'any ja va per sobre de les 1.800. La corba no ha pujat: ha canviat de forma.

La màquina que pentina el codi

No és un producte ni un anunci de fira: és una cadena d'eines ficada dins del procés d'enginyeria. Google fa servir models de llenguatge en recerca de seguretat des del 2023, però el que ha disparat la xifra, segons la seva pròpia explicació, és un agent construït a principis del 2026 sobre Gemini, entrenat amb una base de coneixement de CVE anteriors i amb l'historial complet de Git del Chrome. A això s'hi sumen Naptime (2024, amb Project Zero), Big Sleep (amb DeepMind i Project Zero, especialitzat en el motor JavaScript V8 i en gràfics) i CodeMender, que viu dins del sistema d'integració contínua. Els models no només busquen: reprodueixen l'error, li assignen severitat, l'enruten a l'equip, generen un pedaç candidat i escriuen la prova.

La dada que millor explica el canvi no és el 1.072, és aquesta altra: només al maig, aquest sistema va bloquejar més de vint vulnerabilitats abans que arribessin a producció, una de crítica. I la troballa estrella és una evasió del sandbox que permetia que un procés de renderitzat compromès enganyés el navegador per llegir fitxers locals, i que feia més de tretze anys que era al codi. SecurityWeek l'identifica com a CVE-2026-3545, amb CVSS 9,8, corregit a principis de maig al Chrome 145.

Tretze anys. Aquell error va sobreviure a Project Zero, a un programa de recompenses que paga bé, a les auditories de mitja indústria i a una quantitat d'ulls que cap altre projecte de programari lliure no té. Convé dir-ho sense èpica: l'interessant no és que la màquina sigui llesta, és que el llistó humà era molt més baix del que ens agrada creure. I hi ha una conseqüència que ja es nota a l'ecosistema: al març, Google havia rebut més informes de seguretat que en tot el 2025, i ha hagut de reorientar el seu programa de recompenses per prioritzar allò que aporti alguna cosa al que ja troba les seves pròpies eines. El caçador d'errors humà competeix ara amb una cosa que no dorm i que a més sap on mirar.

«Aplicant models com el Gemini estem corregint vulnerabilitats de manera preventiva, avançant-nos als nostres adversaris i fent el Chrome més segur amb cada actualització.» — Doug Turner, director d'enginyeria del Chrome.

1.072 no és una mesura de risc

Que hagin arreglat 1.072 errors no vol dir que el Chrome de la setmana passada fos 1.072 vegades més perillós. La immensa majoria d'aquests errors no els estava explotant ningú, i molts ni tan sols eren explotables tots sols. El que ha augmentat no és el risc: és la capacitat de trobar. Són dues gràfiques diferents i fa setmanes que es dibuixen l'una sobre l'altra.

La conseqüència pràctica és incòmoda per a molta gent que fa informes: comptar CVE ha deixat de mesurar res. Fa dues setmanes comptàvem 622 pedaços de Microsoft en un sol dimarts, un rècord absolut, i ja llavors el número tot sol no deia si la teva empresa estava millor o pitjor. Ara el soroll de fons torna a pujar. Si el teu quadre de comandament de seguretat té un gràfic de «vulnerabilitats del mes», aquest gràfic ja no informa: decora.

El que sí que continua mesurant són dues coses, i cap no surt a la nota de premsa: si un error s'està explotant de debò —per això hi ha el catàleg KEV de CISA, i per això prioritzem per explotació i no per CVSS— i quant trigues tu a portar el pedaç de l'anunci a la màquina. Google acaba d'accelerar la seva meitat d'aquesta equació. La segona la controles tu, i allà no hi ha cap agent que valgui.

La dada que sí que et canvia el calendari

Convé ser honestos amb la cronologia, perquè bona part de la cobertura l'ha barrejat. La cadència de dues setmanes no es va anunciar el 30 de juliol: es va anunciar el 3 de març i arrenca amb el Chrome 153, el 8 de setembre del 2026. I les actualitzacions de seguretat setmanals existeixen des del 2023. El que és genuïnament nou d'aquest anunci és una altra cosa, i va justament en la direcció que a un administrador li importa: Google està pilotant dues publicacions de seguretat per setmana per estrènyer la finestra entre que l'error es corregeix i tu el tens posat. Per a un usuari domèstic tot això és transparent: el navegador s'actualitza sol i ja està. Per a qui gestiona un parc de dos-cents llocs de treball, no.

Perquè una actualització de navegador en una empresa no s'acaba quan es descarrega el binari: s'acaba quan l'usuari reinicia. I l'usuari no reinicia. Té quaranta pestanyes obertes, l'ERP en una d'elles i una comanda a mig fer. Hi ha una política del Chrome Enterprise per forçar-ho, RelaunchNotification, i a la majoria de parcs que ens arriben de fora està sense configurar, de manera que el navegador està pedaçat al disc i sense pedaçar a la memòria. Aquest matís, que sona a detall d'administrador, és literalment la diferència entre estar protegit i creure-ho.

I aquí cal donar-li a Google el que és de Google, perquè és la part de l'anunci que menys s'ha explicat: aquesta meitat també l'estan atacant. Des del Chrome 150 al macOS, el navegador es pot reiniciar sol per aplicar una actualització pendent quan fa estona que és de fons i sense finestres obertes. I l'objectiu declarat va més enllà: pedaçat dinàmic, és a dir, aplicar l'actualització sense reiniciar el navegador, més una millor restauració de sessió. Si se'n surten, el problema del reinici s'acaba. Dins del Chrome. Que és justament on s'acaba el favor: ningú no farà pedaçat dinàmic del teu ERP, del teu client VPN ni del microprogramari dels teus punts d'accés.

Google també ofereix el canal Extended Stable, pensat per a entorns sensibles que necessiten anar més a poc a poc, i que continua amb el seu cicle de vuit setmanes també després del setembre. Aquest contrast resumeix el dilema millor que cap paràgraf: vuit setmanes d'una banda, dues publicacions de seguretat per setmana de l'altra. És una eina legítima quan cal. Però convé dir per a què serveix i per a què no: és un botó de «vaig més a poc a poc», no un botó de «no m'actualitzo». Si l'actives perquè tens una aplicació interna que només funciona amb una versió concreta del navegador, no has resolt un problema de seguretat: has ajornat un problema de desenvolupament, i li has posat data de caducitat. I si la teva política és «el navegador es revisa al manteniment trimestral», amb dues publicacions de seguretat per setmana això ja no és una política: és un deute amb interessos.

L'asimetria que ningú no t'arreglarà

Aquí hi ha, al nostre parer, el que de debò cal endur-se d'aquesta notícia. Google es pot permetre una flota d'agents revisant el seu propi codi, amb la seva pròpia integració contínua, el seu historial de gairebé dues dècades i la seva base de coneixement de CVE. És de les poquíssimes empreses del món que pot. El programari que sosté el teu negoci, no.

L'ERP vertical que fa servir el teu sector i que mantenen quatre persones. El programari del fabricant de la màquina de producció, que s'actualitza quan ve el tècnic. El visor de l'escàner, el plugin del CRM, l'aplicació de fitxatge, el microprogramari de la impressora d'etiquetes. Ningú no passarà un agent amb Gemini a aquell codi. El llistó de seguretat està pujant, molt de pressa, exactament on ja era alt —navegadors, sistemes operatius, cloud dels grans— i no es mou ni un mil·límetre on era baix. El teu risc no baixa: es desplaça.

I hi ha un detall del mateix anunci que ho resumeix millor que cap metàfora: el Chrome arrossega més de 2.300 dependències de tercers, de les quals unes 1.700 es distribueixen als usuaris. Ni tan sols Google executa només codi de Google. Bona part d'aquestes biblioteques també són dins de les teves aplicacions, empaquetades pels teus proveïdors, i allà no hi ha cap flota d'agents mirant.

L'altra cara ja la vam escriure fa una setmana: l'atacant té les mateixes eines. Ni ell ni Google han inventat classes de vulnerabilitat noves; tots dos han comprimit el temps. Si el temps de trobar es comprimeix als dos bàndols, el temps d'aplicar s'ha de comprimir també, i aquest és l'únic dels tres que depèn de tu.

La feina avorrida que sí que canvia el resultat

Res d'això és glamurós i gairebé tot cap en una tarda de feina ben feta. És el que fem als parcs que mantenim, i és literalment la feina del manteniment informàtic quan es fa de debò i no a cop d'avís.

• Un inventari que no sigui l'Excel. Quin programari corre a cada lloc i a cada servidor, amb versió. Sense això, «estem afectats?» només es pot respondre arronsant les espatlles.
• Actualització automàtica per defecte a navegadors i clients. Amb aquesta cadència, deixar que s'actualitzi sol és la decisió conservadora; retenir-lo per «controlar» és l'arriscada. S'ha girat la truita i moltes polítiques internes encara no se n'han assabentat.
• Forçar el reinici. RelaunchNotification en mode obligatori, amb RelaunchNotificationPeriod ajustat —per defecte són set dies, que amb aquesta cadència és massa— i RelaunchWindow perquè el reinici forçat caigui de matinada i no a mig matí. Un pedaç que espera que l'usuari tanqui el navegador el divendres és un pedaç que no existeix de dilluns a dijous.
• Excepcions amb data i amb responsable. Tota màquina que no es pot actualitzar necessita les dues coses escrites. Una excepció sense data és una decisió permanent presa per accident.
• Prioritzar per explotació, no per volum. El catàleg KEV de CISA primer, la resta per finestra de manteniment. Intentar arribar a tot és la manera més eficaç de no arribar al que importa.
• Mesurar el temps, no la quantitat. La mètrica útil és quants dies passen entre que el fabricant publica i el parc ho té posat; i sobretot la cua: aquell grapat de màquines que sempre es queda enrere. L'incident viu a la cua, mai a la mediana.
• Compensar el que no es pot pedaçar. El PC del taller amb un Windows que no es toca perquè controla una màquina de producció que va costar sis xifres existeix a gairebé totes les empreses. No es pedaça: s'aïlla a la seva VLAN, se li limita amb qui parla i es vigila amb EDR/MDR. Això sí que es pot fer avui.

I quatre coses que no fem

• Desactivar l'actualització automàtica per «controlar els canvis». Amb fites cada dues setmanes, això ja no és control: és acumular versions fins que el salt sigui tan gran que faci por fer-lo.
• Mesurar la seguretat pel nombre de CVE. Ni a l'alça ni a la baixa. Un mes amb 1.072 correccions pot ser el mes més segur de l'any.
• Comprar res pel titular. Cap eina que es vengui aquesta setmana amb la paraula «IA» al davant et reduirà el temps entre que surt el pedaç i el tens posat. Això és procés, no producte.
• Confondre «el fabricant ja ho ha arreglat» amb «ja està arreglat a la meva empresa». La distància entre aquestes dues frases, mesurada en dies, és la teva superfície d'atac real.

El pedaç existeix des del minut zero

Ens agrada aquesta notícia, i no per la xifra. Ens agrada perquè ensenya una cosa que fa anys que diem amb menys dades: el problema del pedaçat mai no va ser que faltessin pedaços. Els pedaços existeixen des del minut zero. El risc viu en els dies que hi ha entre que existeixen i que estan posats, i aquests dies no els posa el fabricant, els poses tu. Si la teva part continua sent «ja ho mirarem el mes que ve», el resultat net de tota'aquesta meravella tecnològica a la teva empresa és exactament zero.

I si en llegir això no saps quants dies triga un pedaç a arribar a l'última màquina de la teva empresa, aquesta és la pregunta amb què començaríem. No cal cap eina nova per respondre-la; cal mirar-s'ho. Si vols que ho mirem amb tu, ja saps on som.

Fonts (verificades): les xifres de correccions (1.072 al Chrome 149 i 150, més que en les 23 fites anteriors juntes), les eines (Naptime amb Project Zero el 2024, Big Sleep amb DeepMind, l'agent sobre Gemini de principis del 2026, CodeMender a la integració contínua), les més de 20 vulnerabilitats bloquejades abans de producció al maig, la fuita de sandbox de més de 13 anys, el canvi del programa de recompenses, les més de 2.300 dependències de tercers (unes 1.700 distribuïdes) i la nova cadència de fites cada dues setmanes amb el pilot de dues publicacions de seguretat per setmana, de l'anunci de Google «Chrome: stronger with every update» (blog.google, 30 de juliol del 2026). La comparativa de les 23 fites anteriors (1.036 errors en dos anys), les dates del Chrome 149 i 150 i la citació de Doug Turner, de TechCrunch (30 de juliol del 2026). La identificació de la fuita de sandbox com a CVE-2026-3545 (CVSS 9,8, corregit al Chrome 145 a principis de maig) i l'acumulat de més de 1.800 errors el 2026, de SecurityWeek. El total de 1.442 correccions a les tres últimes versions, de The Hacker News. Els 622 pedaços de Microsoft del juliol són els del butlletí que vam cobrir al seu moment. No hem verificat de manera independent el recompte intern de Google.