Una setmana de vulnerabilitats crítiques: què ha passat amb PHP, GitLab, Node.js i Linux

En pocs dies s’han acumulat diversos avisos de seguretat importants. Dues vulnerabilitats crítiques en PHP, una actualització urgent de GitLab, diversos errors en Node.js, una vulnerabilitat en el nucli de Linux i un incident que ha compromès una versió de LiteLLM.

Són tecnologies molt diferents, però tenen alguna cosa en comú: formen part de la infraestructura digital que utilitzem cada dia, sovint sense que ens n’adonem.

Per què han aparegut tants avisos en tan poc temps? Quins riscos representen? I què hauries de revisar si utilitzes alguna d’aquestes tecnologies?

Anem per parts.

PHP: dues vulnerabilitats crítiques que ja hem corregit a cdmon

El 21 d’octubre de 2026, l’equip de seguretat de PHP va publicar dues vulnerabilitats crítiques, identificades com CVE-2026-109618 i CVE-2026-109619, amb una puntuació de gravetat de 9,2 sobre 10.

Totes dues podien permetre l’execució remota de codi sense autenticació. Dit de manera senzilla: en determinades condicions, un atacant podia aprofitar aquests errors per executar instruccions malicioses en un servidor sense disposar de credencials d’accés.

El problema afectava diferents formes d’executar PHP en servidors web, inclosos PHP-FPM, Apache amb mod_php, php-cgi, FrankenPHP i LiteSpeed.

Com vam actuar a cdmon?

Quan es va conèixer la gravetat d’aquestes vulnerabilitats, el nostre equip va començar a treballar per reduir l’exposició dels serveis afectats.

El 21 d’octubre, a les 07:30 AM, vam aplicar una mitigació temporal mentre esperàvem la publicació de les correccions oficials.

Aquella mateixa tarda, després de la publicació de les noves versions de PHP, vam aplicar les actualitzacions de seguretat corresponents a les 7:00 PM.

La diferència entre ambdues actuacions és important. Una mitigació temporal permet reduir determinats riscos mentre es desenvolupa o publica una solució definitiva, però no substitueix una actualització de seguretat.

Per això, des del primer moment, el nostre objectiu va ser aplicar les versions corregides tan aviat com estiguessin disponibles.

Les vulnerabilitats de PHP que vam comunicar el 21 d’octubre ja estan corregides en els serveis de cdmon. Els clients no han de fer res per aplicar aquestes actualitzacions.

Si administres una instal·lació pròpia de PHP en un servidor, has de comprovar que utilitzes una versió corregida.

Quines versions de PHP solucionen aquestes vulnerabilitats?

L’equip de PHP va publicar aquestes versions:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Si administres la teva pròpia instal·lació, comprova quina versió tens i consulta les actualitzacions disponibles per al teu sistema.

Pots trobar els detalls d’ambdós errors en l’avís oficial de seguretat de PHP.

Una altra data important: PHP 8.2 deixarà de rebre suport al desembre

Encara que PHP 8.2 ha rebut les correccions d’aquestes vulnerabilitats, el 31 de desembre de 2026 arribarà al final del seu cicle de vida.

A partir d’aquesta data deixarà de rebre actualitzacions oficials de seguretat. Això significa que les noves vulnerabilitats que es descobreixin podrien quedar sense corregir per part del projecte PHP.

Si la teva pàgina web encara utilitza PHP 8.2, és recomanable començar a planificar l’actualització a una versió amb suport.

Abans de fer-ho, comprova que el teu CMS, plugins i altres components siguin compatibles. A cdmon pots utilitzar el nostre entorn de Staging per fer proves sense afectar directament la teva pàgina web en producció.

Pots consultar les dates de suport a la web oficial de PHP.

GitLab: una vulnerabilitat crítica en instal·lacions autogestionades

GitLab és una plataforma utilitzada per equips de desenvolupament per gestionar repositoris de codi, automatitzar proves i organitzar desplegaments.

El 21 d’octubre va publicar una actualització urgent per corregir diverses vulnerabilitats, entre elles CVE-2026-110264, amb una gravetat de 10 sobre 10.

Aquest error podia permetre que un atacant sense autenticar executés codi en el servidor sota determinades condicions.

La vulnerabilitat afectava instal·lacions autogestionades de GitLab, per la qual cosa és especialment rellevant per a organitzacions que executen aquesta eina en la seva pròpia infraestructura.

Què hauries de fer?

Si administres una instal·lació de GitLab, comprova si has instal·lat una de les versions corregides: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 o 18.11.13, segons la branca que utilitzis.

GitLab recomana actualitzar com més aviat millor i ha publicat informació addicional per ajudar a identificar possibles intents d’explotació.

Pots consultar les versions i recomanacions en l’avís oficial de GitLab.

Node.js: diverses vulnerabilitats que requereixen actualització

Node.js permet executar JavaScript fora del navegador i s’utilitza en aplicacions web, serveis backend, eines de desenvolupament i processos automatitzats.

El 21 d’octubre, el seu equip va publicar actualitzacions per corregir deu vulnerabilitats, quatre d’elles de gravetat alta.

Entre els problemes detectats destaca CVE-2026-111497, una vulnerabilitat en el descodificador Brotli que podria permetre l’execució remota de codi.

Brotli és una tecnologia de compressió que ajuda a reduir la mida de les dades transmeses. Un error en la manera com es processen aquestes dades pot convertir-se en un problema de seguretat si permet manipular la memòria d’una aplicació.

Quines versions estan corregides?

Les actualitzacions publicades són:

• Node.js 22.23.4
• Node.js 24.22.1
• Node.js 26.12.1

Si utilitzes Node.js en les teves aplicacions o servidors, comprova la versió instal·lada i actualitza-la seguint les indicacions oficials.

Tingues en compte que Node.js també pot formar part d’eines de desenvolupament i aplicacions que inclouen la seva pròpia versió. Actualitzar la instal·lació principal no garanteix que tots aquests components estiguin actualitzats.

Trobaràs més informació en l’avís de seguretat de Node.js.

Nucli de Linux: una vulnerabilitat que afecta l’aïllament de màquines virtuals

Un altre dels avisos rellevants d’aquests dies afecta el nucli de Linux, el component central del sistema operatiu que gestiona els recursos de l’equip i la comunicació entre el maquinari i el programari.

La vulnerabilitat CVE-2026-99999, coneguda com PwnEscape, afecta determinats entorns virtualitzats.

En determinades condicions, podria permetre que un procés executat dins d’una màquina virtual accedís a memòria del servidor físic que l’allotja.

Això és especialment rellevant en entorns on diverses màquines virtuals comparteixen un mateix servidor físic, ja que l’aïllament entre elles és una part fonamental de la seguretat.

No obstant això, no significa que qualsevol usuari pugui accedir directament al servidor físic. L’explotació requereix determinades condicions prèvies, entre elles que l’atacant aconsegueixi executar codi dins de la màquina virtual.

Quines mesures són necessàries?

La resposta depèn del nucli, la configuració i la plataforma de virtualització utilitzats.

Els administradors han de comprovar si els seus sistemes estan afectats, revisar les actualitzacions publicades pels seus proveïdors i aplicar les correccions corresponents.

També és important recordar que algunes actualitzacions del nucli requereixen reiniciar el sistema perquè la nova versió entri en funcionament.

Pots ampliar la informació a l’anàlisi tècnica de CVE-2026-99999.

LiteLLM: quan el problema no està en el codi, sinó en allò que descarregues

El cas de LiteLLM és diferent dels anteriors.

LiteLLM és una eina utilitzada per connectar aplicacions amb diferents models i proveïdors d’intel·ligència artificial.

El 21 d’octubre es va detectar que la versió 1.107.0 havia estat distribuïda amb programari maliciós a través de repositoris de paquets i imatges de contenidors.

No es tractava d’una vulnerabilitat convencional que pogués aprofitar-se mitjançant una sol·licitud especialment dissenyada. El problema era que una versió aparentment legítima del programari contenia codi maliciós.

Aquest tipus d’incident es coneix com atac a la cadena de subministrament de programari.

És especialment delicat perquè els equips poden instal·lar una actualització confiant en la seva procedència sense saber que el procés de distribució ha estat compromès.

Què fer si utilitzes LiteLLM?

L’equip de LiteLLM ha retirat les versions afectades i publicat un informe amb les recomanacions de resposta.

Si vas instal·lar o executar la versió compromesa durant el període indicat en l’avís, has de considerar la possibilitat que l’entorn s’hagi vist afectat.

En aquest cas, no n’hi ha prou amb actualitzar a una altra versió: és necessari seguir el procediment oficial de resposta a l’incident, revisar l’entorn i substituir les credencials que hagin pogut quedar exposades.

Pots trobar els detalls i les instruccions en l’informe oficial de seguretat de LiteLLM.

Què hauries de revisar en els teus projectes?

Encara que aquests avisos s’han publicat pràcticament al mateix temps, no tots afecten els mateixos sistemes ni requereixen les mateixes accions.

Si utilitzes hosting compartit de cdmon, les actualitzacions de PHP que hem comunicat ja estan aplicades. No necessites intervenir per corregir aquestes vulnerabilitats.

No obstant això, continua sent important mantenir actualitzat el programari de la teva pàgina web, especialment WordPress, els seus temes i plugins.

Si administres el teu propi VPS, servidor dedicat o aplicacions, convé revisar quines tecnologies utilitzes i quins components estan sota la teva responsabilitat.

Algunes bones pràctiques que poden ajudar-te són:

• Mantenir un inventari actualitzat: saber quines versions de PHP, Node.js, sistemes operatius i aplicacions utilitzes facilita identificar si un avís t’afecta.
• Seguir les fonts oficials: els equips responsables de cada tecnologia publiquen informació sobre versions vulnerables, correccions i possibles mesures temporals.
• Planificar les actualitzacions: especialment quan impliquen canvis de versió, possibles incompatibilitats o reinicis.
• Mantenir còpies de seguretat i provar els canvis: disposar d’un punt de restauració i d’un entorn de proves ajuda a reduir els riscos durant el manteniment.
• Revisar les dependències: una aplicació pot incorporar components vulnerables encara que no els utilitzis directament.

La clau no és actualitzar tot indiscriminadament cada vegada que apareix una alerta, sinó entendre què t’afecta, valorar la seva gravetat i actuar amb criteri.

Per què s’estan descobrint tantes vulnerabilitats alhora?

La coincidència de tants avisos importants en pocs dies planteja una pregunta interessant: és simplement casualitat o està canviant la forma en què descobrim els problemes de seguretat?

No hi ha una explicació única demostrada per a aquesta concentració d’incidents. Les vulnerabilitats poden portar anys presents en el codi abans que algú les descobreixi, i les seves dates de publicació depenen de nombrosos factors, com els processos d’investigació, coordinació i desenvolupament de correccions.

Però hi ha un altre element que està transformant el panorama: la intel·ligència artificial.

Les eines d’IA estan adquirint capacitats per analitzar codi, identificar patrons sospitosos i ajudar a detectar errors que abans requerien moltes hores de treball especialitzat.

Això obre dues possibilitats al mateix temps.

D’una banda, els equips de seguretat poden analitzar més codi, localitzar vulnerabilitats i desenvolupar correccions amb més rapidesa.

D’altra banda, aquestes mateixes capacitats també poden facilitar el treball dels qui busquen explotar els errors.

El nostre CEO, Jaume R. Palau, planteja precisament aquesta reflexió en el seu article «És casualitat que s’hagin ajuntat tantes vulnerabilitats crítiques de cop?».

La seva hipòtesi és que la IA podria estar accelerant considerablement el descobriment de vulnerabilitats que portaven anys ocultes en el programari. I també planteja l’altra cara de la moneda: aquestes mateixes eines ofereixen una oportunitat per revisar i millorar sistemes que fins ara resultaven massa costosos d’auditar.

És una reflexió que val la pena llegir, especialment si treballes en desenvolupament, administració de sistemes o ciberseguretat.

La seguretat és una feina contínua

El que ha passat aquests dies és un recordatori que la seguretat no depèn d’una única actualització ni acaba quan es corregeix una vulnerabilitat.

Les tecnologies evolucionen, es descobreixen nous errors i apareixen amenaces que obliguen a revisar el que fins ahir consideràvem segur.

A cdmon, la nostra feina consisteix a seguir de prop aquesta evolució, avaluar els riscos per a la nostra infraestructura i actuar quan és necessari.

La resposta a les vulnerabilitats de PHP del 21 d’octubre és un exemple: primer vam aplicar mesures temporals per reduir l’exposició i, tan aviat com van estar disponibles les correccions oficials, vam actualitzar els serveis afectats.

Perquè protegir una infraestructura no significa que mai no apareguin vulnerabilitats. Significa estar preparats per identificar-les, respondre i mantenir els sistemes actualitzats.

I, per descomptat, mantenir-te informat del que passa i de les accions que realment necessites realitzar per protegir els teus projectes.