El 21 d'octubre, CISA va publicar una recomanació que no s'escriu a la lleugera: qui no pugui pedaçar immediatament hauria de «retirar de la xarxa els sistemes basats en PHP fins que es puguin pedaçar o actualitzar». Apagar el web. Com a mínim un govern europeu ho va fer. Aquest web que estàs llegint també corre sobre PHP, així que l'avís ens va arribar a casa igual que a tothom. El que ve a continuació no discuteix si cal pedaçar —cal pedaçar, i punt—. Va del que va passar en les dues hores següents a una d'aquelles intrusions, perquè en aquelles dues hores ja no fallava PHP.
Les dues hores
La Unitat 42 de Palo Alto Networks explica un cas concret: una entitat governamental europea, compromesa a través d'aquestes fallades. El que van fer els atacants dins de les dues primeres hores des de l'explotació inicial va ser fer-se amb hashes de contrasenyes i secrets d'MFA, aixecar un túnel de retransmissió NTLM cap a l'Active Directory i intentar escalar a administrador de domini. Dues hores des de «algú ha entrat pel web» fins a «algú està provant de ser l'amo del directori».
Hi ha un detall del mateix informe que mereix una lectura a part, i no és decoratiu: els operadors van fer servir plataformes d'IA agèntica durant la post-explotació, amb ordres que portaven delimitadors del tipus ==SHELLUSER== perquè la sortida fos fàcil de llegir per un model, en tasques curtes i espaiades amb canvis ràpids de rumb després de cada fallada. Dit sense dramatisme: la part lenta d'un atac —provar, llegir, decidir el pas següent— és justament la que millor s'automatitza. Si el teu pla de resposta assumeix que entre l'entrada i el moviment lateral hi ha una nit de marge, aquest supòsit s'acaba de quedar obsolet.
I ara la pregunta que dona títol a aquest post, que és la que ens interessa de debò: per què un servidor web podia arribar a l'Active Directory? Aquesta part no la va obrir la fallada de PHP. Ja estava oberta abans.
Què són CVE-2026-109618 i CVE-2026-109619
Els dos avisos estan publicats pel mateix projecte PHP, tots dos amb CVSS v4.0 de 9,2 i el mateix vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Els va batejar PHP2Shell watchTowr i el nom ha arrelat; els noms no pedacen res, però ajuden a cercar.
- CVE-2026-109618 — execució de codi per corrupció en quedar-se sense memòria. PHP fa servir
longjmp()quan s'exhaureix la memòria. Si la reserva falla durant la inicialització de la petició, la sortida anticipada deixa l'estat a mig muntar, i el procediment de tancament processa aquesta memòria corrompuda. Les vies d'atac que descriu l'avís són peticions multipart sense longitud declarada que se saltenpost_max_size, seccions amb capçaleres il·limitades que exhaureixen elmemory_limiti controls de fitxer buits que esquivenmax_file_uploads. - CVE-2026-109619 — execució de codi per estat global ranci. Estat que pertany a una petició sobreviu al procés treballador i el llegeix una petició posterior, abans que la inicialització normal el reposi. L'avís ho diu sense embuts: «una disposició de l'heap estratègicament preparada pot produir execució remota de codi completa». Cal una operació que desi aquest estat i una altra que el consumeixi.
Un matís honest, dels que gairebé mai no es citen perquè resten titular: aquest vector porta AC:H i AT:P, és a dir, complexitat alta i condicions d'atac que s'han de donar. No és un curl i a dins. Això no canvia la conclusió —es pedaça igual, i de pressa—, però sí que canvia el to amb què se'n parla en una reunió: no és màgia instantània, és feina d'explotació amb premi molt alt.
La cronologia va al revés
El normal és: el fabricant pedaça, després es publiquen els detalls, després apareix l'exploit. Aquí l'ordre va ser un altre. El 20 d'octubre els detalls es van filtrar abans de la divulgació coordinada, amb el pedaç encara inexistent; watchTowr va ser dels primers a confirmar públicament que la filtració era genuïna. Aquell mateix dia l'equip de seguretat de PHP va anunciar una publicació d'emergència per al 21 d'octubre a les 14:00 UTC. El 21 van sortir les versions corregides, i aquell mateix 21 la xarxa d'esquers de watchTowr va observar explotació de totes dues fallades.
Convé dir en veu alta una tensió entre fonts, perquè sortirà en qualsevol conversa seriosa sobre això. CISA, en la seva alerta del 21 actualitzada el 23, afirma que no ha observat explotació reeixida en el moment de la publicació. Unit 42, en canvi, documenta el cas del govern europeu amb post-explotació detallada, i watchTowr veu intents als seus esquers. No són necessàriament contradictòries —veure intents en un esquer no és el mateix que confirmar una intrusió reeixida, i les finestres d'observació no coincideixen—, però tampoc no les maquillarem: ningú de fora no les pot resoldre, i qui escriu la política de pedaços no hauria d'esperar que algú ho faci. A data d'avui, 24 d'octubre, per cert, cap dels dos CVE no figura al catàleg KEV de CISA. Si el teu procés d'urgència es dispara només amb el KEV, aquest és el dia de descobrir que aquest disparador arriba tard.
El pedaç existeix per a quatre branques
Les versions corregides són 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Quatre branques. Ni una més. I aquí és on l'incident deixa de ser una notícia de seguretat i passa a ser una factura de deute tècnic, perquè segons les dades de W3Techs del 24 d'octubre del 2026, de tots els llocs que fan servir PHP el 26,8% corre la branca 7, el 7,7% la branca 5 i un 0,1% encara la 4. Són com a mínim 34,6 de cada 100 llocs amb PHP en una branca que no té pedaç ni en tindrà, i el gruix d'aquest 26,8% és 7.4: el 73,4% dels PHP 7 mesurats. Diem «com a mínim» perquè el compte real és pitjor. Dins del 65,4% que corre la branca 8, un 15,1% és a 8.1 i un 5,8% a 8.0, totes dues sense suport: són gairebé 14 punts més. Sumat, prop de la meitat del parc de PHP no té una versió corregida per instal·lar.
Aquesta és la forma que més ens trobem i de la qual ja vam escriure al seu dia: la teva política de pedaços no contempla que no hi hagi pedaç. El procediment sencer assumeix que existeix un paquet per instal·lar. Quan no existeix, el document es queda mut i la decisió puja a direcció en calent, un dimecres, amb el rellotge en marxa. Escriure aquesta branca del procediment un dia tranquil costa una hora.
Actualitzar el paquet no és haver pedaçat
La segona fallada viu en l'estat que el treballador conserva entre peticions; la primera, en la inicialització d'una de sola. Però totes dues comparteixen una conseqüència pràctica que s'oblida cada vegada: mentre els treballadors vells segueixin en memòria estan executant el codi vell, de manera que continuen sent vulnerables encara que el paquet nou faci mitja hora que és al disc. L'avís de CVE-2026-109619 ho repeteix a les dues mitigacions de configuració que proposa —aplicar l'ajust i reiniciar els treballadors—. Si gestiones una flota, la comprovació posterior no és «quina versió diu el paquet», és quina versió està executant el procés que atén el port 443, i des de quan és viu.
L'exposició tampoc no és igual a tot arreu, i convé llegir els dos avisos per separat perquè no diuen el mateix. Al primer, amb Apache i mod_php la cosa està confirmada: el tancament s'invoca encara que l'arrencada hagi fallat, i allà hi ha l'execució de codi; amb PHP-FPM el fill acaba si falla a l'arrencada, però un exhauriment de memòria posterior continua sent potencialment explotable, i FrankenPHP és probablement susceptible per analogia amb mod_php. Al segon, el cas confirmat torna a ser mod_php —pel rastreig d'error fatal i pel progrés de pujada de sessió—, mentre que l'FPM queda exposat de manera condicional: quan el frontal li passa paràmetres PHP_VALUE o PHP_ADMIN_VALUE que generen un diagnòstic abans d'inicialitzar la petició. De FrankenPHP diu que no va trobar un consumidor equivalent en la seva configuració per defecte, i afegeix, amb una honestedat que agraïm, que això no el fa immune; LSAPI hi figura com a candidat condicional. Quin servidor fas servir deixa de ser una preferència d'administrador i passa a ser una dada de l'avaluació de risc, igual que l'exposició real la decideix el teu php.ini quan parlem de WordPress.
Les mitigacions que no mitiguen
Aquí hi ha una perla que mereix un minut. La mitigació temporal que proposa l'avís de CVE-2026-109618 és posar memory_limit=-1: treure el límit de memòria. Justament l'ajust que fa quinze anys que recomanem estrènyer. El motiu és que aquest límit predictible per petició és el que fa còmoda l'explotació, i sense ell l'atacant perd el seu rellotge. I no n'hi ha prou: l'avís ho diu amb aquestes paraules —«això no és una mitigació completa», perquè si falla mmap() o una altra reserva de baix nivell, PHP pot tornar a usar longjmp() amb memòria de petició incompleta a l'abast—. Actualitzar és, literalment, «l'única mitigació completa». El mateix avís demana a més un post_max_size conservador al frontal, abaixar max_input_nesting_level i acotar variables, parts, capçaleres i pujades. I aquí ve el que remata la lliçó: diu que NO es facin servir RLIMIT_AS ni RLIMIT_DATA, perquè fan fallar mmap() en arribar al límit i disparen justament el camí vulnerable. Dos controls que qualsevol auditoria puntuaria com a bons, jugant a favor de l'atacant. Un enduriment no és bo en abstracte; és bo contra un atac concret, i de vegades juga en contra.
Per a la segona fallada l'avís ofereix fatal_error_backtraces=0 a PHP 8.5 i session.upload_progress.enabled=0, tots dos amb reinici de treballadors, i adverteix que cadascun cobreix només el cas demostrat. I després hi ha la frase que hauria de tancar el debat a qualsevol comitè: «no hi ha una mitigació de configuració genèrica completa», perquè diferents rutes d'aplicació o d'extensió poden produir o consumir estat ranci de manera impredictible. Traduït: si algú proposa aguantar amb ajustos fins a la finestra de manteniment d'aquí a tres setmanes, el mateix fabricant ja ha contestat que no.
On corre PHP sense que ho sàpigues
Cortex Xpanse, de Palo Alto, xifrava en més de 22,6 milions les instàncies exposades potencialment vulnerables en el moment de publicar el seu informe. Aquest número no surt dels servidors web que tu i jo tenim apuntats en un full: surt de tota la resta. Un tauler d'administració d'allotjament. Un sistema de tiquets heretat que ningú no toca des que va marxar qui el va muntar. La interfície web d'una cabina, d'un SAI, d'una impressora departamental. Un contenidor amb una imatge base del 2021 que es reconstrueix només quan algú canvia el codi, i el codi no es toca des de fa dos anys. Aquell és l'inventari que decideix la teva exposició real, i gairebé mai no coincideix amb l'inventari oficial.
Per què un web arriba al directori
Tornem a les dues hores, que és el que de debò cal arreglar. Perquè un servidor web compromès tregui hashes del domini i aixequi una retransmissió NTLM, s'han de donar coses que no són vulnerabilitats: són decisions. En el que ens trobem, gairebé sempre són aquestes tres. Una, el frontal està unit al domini —normalment perquè la gent entri amb les credencials de sempre, que és una raó bona amb una conseqüència dolenta—. Dos, el frontal comparteix segment amb servidors interns, així que arriba al 445 i al 389 del controlador sense que ningú l'hi hagi autoritzat explícitament. Tres, hi ha credencials desades en text en un fitxer de configuració que el procés web pot llegir, perquè llegir-les és literalment la seva feina.
Cap de les tres no apareix en un escàner de vulnerabilitats. Les tres són el motiu pel qual l'hora dos va ser molt pitjor que l'hora zero. I les tres s'arreglen amb feina d'arquitectura avorrida: un compte de servei sense privilegis al directori, un segment propi per al frontal amb regles de sortida explícites cap als ports que de debò necessita, i els secrets fora del disc del servidor web. No és glamurós i no surt en cap alerta vermella. És, exactament, la diferència entre una fallada i una avaria.
Quan NO apagar el web
El consell de CISA és correcte i està ben dirigit, i convé llegir-lo sencer abans de repetir-lo en una reunió, perquè té dos destinataris: qui no pot pedaçar immediatament i, textualment, qui continuï a PHP 8.1 o anterior, sense suport. Aquest segon grup és el 20,9% de la branca 8 que acabem de comptar, i per a ells no és un consell temporal: mentre no canviïn de branca, no hi ha pedaç per esperar. El que no és la frase és una recomanació general d'apagar per si de cas. Desconnectar té la seva pròpia factura: una botiga aturada no ven res, un portal de clients caigut genera trucades que també costen diners i, si l'apagada dura, apareixen dreceres —«passa'm la comanda per correu»— que obren forats pitjors que el que volies tancar. La nostra manera de decidir-ho és mirar dues coses abans del botó vermell: si pots pedaçar en menys d'una hora, pedaça i no apaguis res; si no pots, apaga el que estigui exposat a Internet i no calgui per facturar avui, que gairebé mai no és tot. Entre «tot encès» i «tot apagat» hi ha un inventari amb prioritats, i aquest inventari s'escriu abans, no a les nou del vespre d'un dimecres.
La comprovació de vint minuts
Set passos, en aquest ordre. Els quatre primers són d'avui; els tres últims són els que eviten l'hora dos de la pròxima fallada, que arribarà amb un altre nom.
- Pregunta a la versió que atén peticions, no al paquet. Una pàgina amb
phpversion()darrere d'autenticació, ophp-fpm -val servidor, diuen la veritat;php -va la línia d'ordres de vegades és un altre binari. Si no comença per 8.5.12, 8.4.27, 8.3.36 o 8.2.35, no has acabat. - Reinicia els treballadors i comprova que han mort de debò.
systemctl restart php*-fpmi després mira l'antiguitat dels processos: si continuen vius des d'abans del pedaç, continuen sent vulnerables. Amb mod_php, qui ha de reiniciar és l'Apache. - Escombra els teus rangs abans de fiar-te de l'inventari. Una passada cercant capçaleres
X-Powered-By, galetesPHPSESSIDi rutes.phpa tot el que escolta, incloses les xarxes de gestió. El que aparegui i no fos al full és, precisament, el que ningú no pedaçarà. - Si la teva branca no té pedaç, decideix avui i escriu-ho. Amb 8.1 o anterior no hi ha actualització menor que et salvi: o saltes de branca —i això es prova, perquè trenca coses—, o aïlles aquest sistema d'Internet mentrestant. El que no val és deixar-ho a l'aire i anomenar-ho «pendent d'avaluar».
- Mira amb quin compte corre el teu servidor web al domini. Si és un compte de domini, revisa què pot fer: pertinença a grups, permisos de lectura al directori, si es pot autenticar contra altres servidors. El que no necessiti, fora.
- Comprova què arriba el teu frontal cap a dins. Des del mateix servidor web, intenta obrir el 445 i el 389 d'un controlador de domini. Si connecten, acabes de reproduir el primer pas del moviment lateral amb les teves pròpies mans i un dia tranquil. Les regles de sortida d'aquest segment són l'arranjament.
- Decideix qui mira el servidor web a les tres de la matinada. Dues hores de marge no les cobreix un informe setmanal. O hi ha algú de guàrdia amb capacitat d'aïllar la màquina, o el pla consisteix a assabentar-se'n el dijous. Les dues opcions són legítimes; només una sol estar escrita.
On encaixa això en el que fem
Nosaltres mantenim infraestructura d'altri, i aquest web corre en PHP: el dimecres 21 va ser un dia de feina com el de qualsevol que llegeixi això. El que posem a ciberseguretat no és un producte que tapi forats de PHP —això no existeix—, és la part avorrida: saber quina versió corre cada cosa, tenir manera de pedaçar una flota el mateix dia sense trencar res, i que el frontal web no sigui un veí amb clau del directori. La capa d'infraestructura i cloud és on es decideix això segon, i es decideix el dia del disseny, no el dia de l'incident.
Si vols que fem junts l'escombrat del pas 3 i la prova del pas 6 a casa teva —quin PHP tens de debò i què arriba el teu frontal cap a dins—, en parlem. És mig matí. Si surt que estava tot pedaçat i ben segmentat, t'ho diem i tan contents.
Fonts. Les identificacions, la puntuació CVSS v4.0 de 9,2, el vector, les versions afectades i corregides (8.2.35, 8.3.36, 8.4.27 i 8.5.12), la descripció tècnica de totes dues fallades, la susceptibilitat per SAPI (mod_php confirmat; PHP-FPM condicional amb execució confirmada pel cicle de vida de sessió; FrankenPHP probable; LSAPI candidat condicional), les mitigacions temporals i els seus límits (memory_limit=-1 i l'advertiment que «això no és una mitigació completa»; actualitzar com «l'única mitigació completa»; post_max_size conservador, max_input_nesting_level i l'advertiment de NO fer servir RLIMIT_AS ni RLIMIT_DATA; fatal_error_backtraces=0 i session.upload_progress.enabled=0 amb reinici de treballadors) i la frase sobre que no hi ha una mitigació de configuració genèrica completa procedeixen dels avisos publicats pel projecte PHP: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) i GHSA-6wmf-4rv5-p3rp (CVE-2026-109619). La recomanació d'actualitzar o retirar de la xarxa els sistemes basats en PHP —adreçada textualment a qui no pugui actualitzar immediatament «o que continuï fent servir PHP 8.1 o versions anteriors sense suport»—, l'afirmació de no haver observat explotació reeixida en el moment de la publicació i la comprovació que cap dels dos CVE no figura al catàleg KEV (versió 2026.10.23) són a l'alerta de CISA del 21 d'octubre del 2026, actualitzada el 23. El cas de l'entitat governamental europea (hashes de contrasenyes i secrets d'MFA, túnel de retransmissió NTLM cap a Active Directory i intent d'escalada a administrador de domini dins de les dues primeres hores; ús de plataformes d'IA agèntica i delimitadors del tipus ==SHELLUSER==), la xifra de més de 22,6 milions d'instàncies exposades mesurada per la telemetria de Cortex Xpanse —telemetria pròpia d'un fabricant, com la de W3Techs és una mostra— i el fet que com a mínim un govern europeu retirés el seu web de manera preventiva són a l'informe de la Unitat 42 de Palo Alto Networks. La cronologia de la filtració del 20 d'octubre abans de la divulgació coordinada, l'anunci de la publicació d'emergència per al 21 a les 14:00 UTC i l'observació d'explotació a la seva xarxa d'esquers són a l'anàlisi de watchTowr. Les dates de suport i de fi de vida de cada branca procedeixen de php.net/supported-versions i php.net/eol. Els percentatges d'ús per branca (65,4% la 8, 26,8% la 7, 7,7% la 5, 0,1% la 4; 73,4% de 7.4 dins de la branca 7; i 15,1% de 8.1 i 5,8% de 8.0 dins de la branca 8), mesurats el 24 d'octubre del 2026 sobre els llocs que fan servir PHP, són de W3Techs; com tota mesura d'aquest tipus, depèn de la seva mostra i convé llegir-la com a ordre de magnitud. Les traduccions de les citacions són nostres. Són criteri nostre, i no afirmacions de cap d'aquestes fonts: la lectura de les dues hores com a problema d'arquitectura i no de PHP, les tres causes habituals que un frontal arribi al directori, el matís sobre la complexitat alta del vector, la manera de decidir si apagar o no, i la comprovació de vint minuts. everyWAN presta serveis gestionats d'infraestructura i seguretat, i aquest web corre sobre PHP: el conflicte d'interès queda declarat. Foto de portada: armari de comunicacions mural amb commutador, router i mòdem, domini públic (CC0), banc de mitjans de WordPress Photos.
Microsoft 365
ES 
CAT 
EN