La vulnerabilitat no era al teu web

Un web pot funcionar perfectament i, tot i així, estar exposat a una vulnerabilitat crítica.

Les pàgines es carreguen amb normalitat, els formularis responen, els usuaris poden accedir als seus comptes i els serveis continuen funcionant sense incidències aparents. No hi ha errors visibles ni indicis que assenyalin que alguna cosa necessita la nostra atenció immediata.

Fins que apareix un avís de seguretat que canvia completament la situació.

El 21 d’octubre de 2026, l’equip de desenvolupament de PHP va publicar actualitzacions urgents per corregir dues vulnerabilitats crítiques, identificades com a CVE-2026-109618 i CVE-2026-109619, totes dues amb una puntuació de 9,2 sobre 10 segons CVSS v4.0.

Les fallades estaven relacionades amb la gestió interna de la memòria i de l’estat de les peticions. En determinades condicions, podien permetre que un atacant executés codi de manera remota sense necessitat d’autenticar-se. La recomanació oficial va ser actualitzar immediatament les instal·lacions afectades que processessin peticions web, ja que les mesures temporals de mitigació no oferien una protecció completa.

La gravetat de l’incident no va trigar a transcendir l’àmbit estrictament tècnic. L’Agència de Seguretat Nacional dels Estats Units (NSA) va recomanar a les organitzacions que utilitzaven PHP preparar les actualitzacions i considerar la desconnexió temporal dels sistemes quan no fos possible corregir-los immediatament.

La resposta també va arribar des de les mateixes plataformes. Drupal.org i altres serveis relacionats van ser retirats temporalment de la xarxa mentre els seus responsables aplicaven les correccions. La Drupal Association va aclarir que el problema no era a Drupal, sinó a PHP, i que els seus mecanismes habituals de protecció no resolien aquesta vulnerabilitat.

El que resultava especialment preocupant no era únicament la gravetat de les vulnerabilitats, sinó el lloc on es trobaven.

No parlem necessàriament d’un error en un connector de WordPress ni d’una funcionalitat desenvolupada sense les precaucions necessàries. Les fallades es trobaven a l’intèrpret de PHP, una tecnologia de la qual depenen nombroses aplicacions web.

Això significa que una organització podia haver mantingut correctament la seva aplicació, aplicat les seves actualitzacions i seguit les recomanacions habituals de seguretat i, tanmateix, continuar exposada per una vulnerabilitat en un dels components que necessitava per funcionar.

Durant anys hem associat bona part de la seguretat web a mantenir actualitzat el nostre programari, corregir errors de programació i configurar adequadament les eines que utilitzem. Són pràctiques fonamentals, però incidents com aquest ens recorden que la seguretat d’una aplicació també depèn d’elements que no sempre veiem i sobre els quals no tenim un control directe.

Que un web funcioni correctament no significa que tot el que necessita per funcionar sigui segur.

Les vulnerabilitats publicades el 21 d’octubre ens conviden a examinar no només com es corregeix una fallada crítica, sinó què significa mantenir la infraestructura sobre la qual funciona una aplicació.

El codi que no escrivim també ens pot comprometre

Quan desenvolupem una aplicació web, solem concentrar bona part dels nostres esforços de seguretat en el codi que escrivim: validar les dades que rebem, controlar els permisos d’accés, protegir les sessions o evitar que una entrada maliciosa acabi executant-se com una instrucció.

Tanmateix, abans que la nostra aplicació pugui fer qualsevol d’aquestes operacions, intervenen altres tecnologies que s’encarreguen de rebre, interpretar i processar les peticions.

En una aplicació desenvolupada amb PHP, una part d’aquesta feina correspon al mateix intèrpret. És el component encarregat d’executar el nostre codi, però també fa operacions internes relacionades amb la gestió de la memòria, les sessions i el processament de les sol·licituds HTTP.

Les vulnerabilitats CVE-2026-109618 i CVE-2026-109619 afecten precisament aquest nivell.

La primera està relacionada amb el tractament dels errors quan s’esgota la memòria disponible. La segona, amb la reutilització incorrecta de determinats estats interns entre peticions. En tots dos casos, les fallades poden permetre que un atacant alteri el comportament de l’intèrpret i arribi a executar codi no autoritzat.

El que és especialment rellevant és que, segons l’anàlisi tècnica publicada per Datadog Security Labs, l’explotació es pot produir abans que PHP arribi a executar el codi de l’aplicació.

Podem haver desenvolupat correctament els nostres mecanismes d’autenticació, aplicat controls sobre els formularis i revisat les funcionalitats exposades a l’exterior. Però si una petició maliciosa aprofita una fallada en el processament intern de PHP, aquestes proteccions poden ni tan sols arribar a intervenir.

No significa que totes les instal·lacions siguin igualment vulnerables ni que qualsevol petició permeti comprometre un servidor. L’exposició efectiva depèn de les versions, les configuracions i les condicions d’execució.

La qüestió és que la seguretat del nostre codi i la seguretat de l’entorn que l’executa són responsabilitats diferents, encara que inseparables.

Podem controlar com desenvolupem una aplicació, però no sempre podem corregir directament els defectes de les eines sobre les quals funciona. En aquests casos depenem de les correccions publicades pels seus responsables i de la nostra capacitat per incorporar-les correctament.

I aquí apareix un nou repte: un cop el proveïdor publica una solució, encara hem d’aconseguir que aquesta correcció arribi de manera segura als nostres sistemes.

Actualitzar no és el mateix que estar protegit

Quan es publica una correcció per a una vulnerabilitat crítica, la recomanació acostuma a ser immediata: actualitzar com més aviat millor. Però entre la disponibilitat d’un pegat i la certesa que un sistema està protegit hi ha un procés que no sempre és tan senzill com sembla.

Un dels aspectes que pot generar confusió és la numeració de les versions.

Distribucions com Ubuntu mantenen determinades versions de PHP durant anys i hi apliquen correccions de seguretat mitjançant un procediment conegut com a backporting. Això permet incorporar pegats de versions posteriors sense necessitat de canviar tota la branca de l’intèrpret, una cosa especialment important en servidors de producció on les aplicacions depenen de versions concretes.

Així, per exemple, el PHP 8.1 distribuït per Ubuntu 22.04 pot rebre correccions específiques de seguretat encara que aquesta branca ja no rebi actualitzacions del projecte PHP. No hem de confondre el suport del fabricant de la distribució amb el del projecte original.

Una versió aparentment antiga no significa necessàriament que sigui vulnerable, de la mateixa manera que una versió més recent no garanteix per si sola que inclogui una correcció concreta.

En el cas de les vulnerabilitats del 21 d’octubre, Ubuntu va publicar paquets corregits per a les seves distribucions compatibles. La comprovació adequada no consistia únicament a consultar la versió de PHP, sinó també a verificar l’origen dels paquets i que les correccions corresponents als CVE s’hi haguessin incorporat efectivament.

Però la verificació no acaba en instal·lar els paquets. També cal comprovar quina versió utilitza realment el servei web, si els processos s’han reiniciat quan correspon i si les aplicacions continuen funcionant correctament.

Una actualització pot haver-se completat sense errors i, tot i així, deixar processos executant codi anterior o provocar incompatibilitats que no es detecten fins que algú utilitza una funcionalitat concreta.

Per això convé distingir entre tres situacions: tenir una correcció disponible, haver-la instal·lat i haver comprovat que està aplicada a l’entorn que realment presta servei.

La seguretat no hauria de basar-se únicament en la confiança d’haver actualitzat, sinó en la capacitat de demostrar què s’ha corregit i què continua funcionant.

I aquesta comprovació necessita una cosa que no sempre podem improvisar durant una emergència: temps per intervenir, verificar els resultats i reaccionar si apareixen problemes.

La seguretat també és una qüestió de temps

Un dels aspectes més rellevants d’aquest incident és el paper de la intel·ligència artificial en la investigació. Segons OpenAI, Calif va identificar una de les fallades amb l’ajuda de GPT-5.6 Sol; Wiz, de manera independent, va descobrir i comunicar tots dos problemes, utilitzant també models d’IA en la seva investigació, segons Google Cloud. Aquestes eines van contribuir a l’anàlisi tècnica i a la comprovació de les correccions.

No significa que la intel·ligència artificial hagi substituït els investigadors de seguretat. El descobriment, l’avaluació dels riscos i la coordinació amb els responsables de PHP van continuar requerint intervenció humana. Però sí que demostra com aquestes eines poden ampliar la capacitat d’analitzar grans quantitats de codi i identificar problemes difícils de detectar mitjançant els procediments tradicionals.

Si cada vegada podem descobrir vulnerabilitats amb més rapidesa, estem preparats per corregir-les al mateix ritme?

Identificar una fallada no significa que tots els sistemes afectats es puguin actualitzar immediatament. Les correccions s’han de desenvolupar, distribuir i aplicar en infraestructures amb característiques molt diferents. Algunes organitzacions disposen d’equips especialitzats i processos de desplegament automatitzats. D’altres depenen d’intervencions manuals, proveïdors externs o aplicacions antigues que requereixen comprovacions addicionals.

La intel·ligència artificial pot ajudar a reduir el temps necessari per descobrir una vulnerabilitat, però no elimina automàticament la feina necessària per corregir-la en producció. I aquesta acceleració també pot beneficiar aquells que busquen explotar les fallades abans que les organitzacions hagin aplicat les actualitzacions.

Per això, el veritable repte no consisteix únicament a detectar més problemes i fer-ho abans. També necessitem reduir el temps que passa entre conèixer una vulnerabilitat i aconseguir que els sistemes afectats tornin a operar amb les correccions necessàries.

La velocitat del descobriment està canviant. La nostra capacitat de resposta també haurà de canviar.

El dia de l’emergència no és el moment de descobrir què tenim

Quan s’anuncia una vulnerabilitat crítica, una de les primeres preguntes hauria de ser relativament senzilla: quins sistemes tenim afectats?

Tanmateix, respondre-la no sempre és fàcil.

En moltes organitzacions, la infraestructura tecnològica ha evolucionat durant anys. S’han migrat aplicacions, contractat nous proveïdors, incorporat serveis i mantingut servidors antics perquè encara allotgen alguna funcionalitat necessària. Una part d’aquesta informació està documentada, però una altra depèn del coneixement de les persones que van participar en cada projecte.

Mentre tot funciona, aquesta situació pot passar desapercebuda. El problema apareix quan hem d’intervenir amb urgència.

Identificar quins servidors utilitzen una versió concreta de PHP, quines aplicacions en depenen o quins repositoris subministren les actualitzacions es pot convertir aleshores en una investigació que consumeix un temps especialment valuós.

També necessitem saber si hi ha còpies de seguretat recuperables, si podem provar els canvis abans d’aplicar-los en producció i quin procediment seguirem si una actualització provoca una incompatibilitat. Fins i tot aspectes aparentment secundaris, com ara l’espai disponible al disc, poden condicionar una intervenció urgent.

La diferència no rau únicament a disposar d’eines de monitoratge o a comptar amb un equip especialitzat. També es troba en decisions molt més bàsiques: mantenir actualitzat l’inventari tecnològic, documentar les configuracions rellevants, definir responsabilitats i comprovar periòdicament que els mecanismes de recuperació funcionen.

Aquestes tasques poques vegades tenen la visibilitat d’un nou desenvolupament o d’una funcionalitat que millora la experiència d’usuari. El seu valor sol fer-se evident precisament quan alguna cosa falla.

Durant aquest incident, algunes organitzacions també van optar per desconnectar temporalment determinats serveis mentre aplicaven les correccions de seguretat. És el cas d’ICANN i de l’Oficina Europea de Patents. Aquestes decisions mostren que respondre a una vulnerabilitat no sempre consisteix a mantenir-ho tot funcionant: en determinades circumstàncies, interrompre temporalment un servei pot ser l’opció més prudent per reduir l’exposició mentre s’aplica una solució.

Per això, una organització preparada no és aquella que pot garantir que mai tindrà problemes de seguretat. És aquella que, quan apareix una amenaça, no necessita començar per esbrinar com funciona la seva pròpia infraestructura.

La capacitat de respondre davant d’una vulnerabilitat no es construeix durant l’emergència. És el resultat del manteniment i de les decisions que hem pres molt abans que aparegui.

Conclusió

Les vulnerabilitats de PHP ens recorden que cap sistema pot garantir l’absència absoluta de fallades. Les bones pràctiques de desenvolupament i el manteniment redueixen els riscos, però no eliminen la possibilitat que apareguin vulnerabilitats desconegudes en tecnologies consolidades.

Per això, potser hauríem de deixar d’entendre la seguretat com un estat que assolim després d’instal·lar determinades eines o completar una sèrie de comprovacions.

La seguretat no és una cosa que aconseguim una vegada i puguem donar per acabada. És una responsabilitat que hem de mantenir al llarg del temps.

Això implica assumir que, tard o d’hora, alguna de les tecnologies que utilitzem necessitarà una correcció urgent. I que la nostra capacitat per identificar el problema, avaluar-ne l’abast, intervenir i comprovar els resultats serà tan important com les mesures preventives que hàgim adoptat.

Una infraestructura fiable no és aquella que mai necessita una intervenció, sinó aquella que pot afrontar els canvis i les incidències sense perdre el control sobre el seu funcionament.

Al final, no podem garantir que cap tecnologia falli, però sí que podem decidir fins a quin punt estem preparats per respondre quan passi.

I aquesta és la pregunta que convé fer-se fins i tot quan els nostres sistemes no s’han vist afectats:

Conheixem prou bé la nostra infraestructura per respondre quan una tecnologia de la qual depenem deixa de ser segura?

Saps en quin estat es troba la teva infraestructura web?

Una vulnerabilitat crítica no hauria de ser el moment en què descobreixes com estan configurats els teus servidors o qui s’encarrega realment de mantenir-los.

A ITDO podem ajudar-te a revisar la teva infraestructura, identificar possibles riscos i definir una estratègia de manteniment i actualització adaptada a les necessitats del teu projecte.

Parlem del teu projecte