El 21 d’octubre de 2026, PHP va publicar correccions urgents per a CVE-2026-109618 i CVE-2026-109619, dues vulnerabilitats crítiques que poden permetre execució remota de codi sense autenticació. Cal actualitzar primer i revisar després per què una aplicació interna continua exposada directament a Internet.

Patch first. Reduce exposure permanently. Primer, aplicar els pedaços. Després, reduir l’exposició de manera permanent.

Què ha confirmat PHP

L’avís oficial de PHP descriu dos problemes del runtime:

Vulnerabilitat	Problema	Impacte potencial
CVE-2026-109618	La gestió de manca de memòria pot deixar dades internes parcialment inicialitzades que després es tracten com a vàlides.	Execució remota de codi sense autenticació.
CVE-2026-109619	Un estat intern d’una petició pot sobreviure a l’alliberament de la seva memòria i reutilitzar-se en una altra petició del mateix worker.	Execució remota de codi sense autenticació.

El preavís del 20 d’octubre assigna a totes dues CVSS v4.0 de 9,2: crítiques. El risc afecta instal·lacions que serveixen peticions web: PHP-FPM, Apache amb mod_php, php-cgi, FrankenPHP i LiteSpeed.

PHP considera mod_php la configuració de més risc. S’hi ha demostrat explotació amb una petició no autenticada abans que s’executi codi de l’aplicació. Aquesta via concreta no s’ha de presentar com a idèntica en tots els runtimes, ni com a confirmació d’atacs en producció.

Versions corregides i verificació

Branca	Versió corregida publicada el 21 d’octubre
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Instal·la aquestes versions o una actualització posterior que inclogui les correccions. Les distribucions i els proveïdors LTS poden oferir pedaços amb una numeració diferent: confirma-ho al seu avís.

PHP 8.1 i anteriors ja no reben manteniment ordinari del projecte. PHP ha facilitat backports mínims d’emergència per a 7.4, 8.0 i 8.1, però això no recupera el suport d’aquestes branques. Consulta el proveïdor o migra a una branca suportada.

Després d’actualitzar, reinicia els processos necessaris i comprova la versió que realment atén les peticions web, no només la de la consola: PHP-FPM, Apache i els contenidors poden executar versions diferents.

El login no sempre protegeix el runtime

Moltes empreses publiquen ERPs, CRMs, intranets o panells interns amb un port 443 obert. Abans d’arribar al login, la petició passa pel servidor web i, segons el desplegament, per PHP.

Internet → servidor web públic → PHP → login de l’aplicació

Quan el problema es pot activar abans del codi de l’aplicació, l’autenticació pròpia no és necessàriament una barrera suficient. L’exposició del runtime s’ha de revisar separadament.

Què aporta ConnectaSec Access

Una aplicació que només necessiten empleats o proveïdors autoritzats pot mantenir-se dins d’una xarxa privada, amb control d’accés abans d’arribar a l’origen.

Usuari → identitat i política d’accés
       → connexió segura → connector → aplicació privada

Un desplegament correcte de ConnectaSec Access pot utilitzar connexions sortints sense publicar ports entrants al servidor de l’aplicació. La identitat i les polítiques determinen qui accedeix al recurs. La integració amb Microsoft 365 ajuda a gestionar usuaris i grups; l’autenticació i l’MFA concrets depenen de la configuració i del servei d’identitat.

Cal tancar també qualsevol accés directe a l’origen: adreces públiques antigues, DNS alternatius i regles de tallafoc. Afegir una capa sense retirar l’exposició original deixa oberta la mateixa via.

Access no substitueix el pedaç

La vulnerabilitat continua existint fins que s’actualitza PHP. Un usuari autoritzat maliciós, un dispositiu compromès o una via alternativa mal configurada continuen representant un risc.

Access pot reduir la possibilitat que un atacant anònim d’Internet contacti directament amb el servidor privat. És una defensa addicional, especialment durant una actualització urgent, però no converteix una instal·lació vulnerable en segura.

PHP descriu mesures temporals per reduir vies concretes d’explotació i adverteix que només l’actualització és una solució completa. Els canvis de memòria i de processament de peticions s’han de valorar amb l’equip responsable perquè també poden afectar la disponibilitat.

Cinc passos per a empreses i MSPs

Inventariar servidors, contenidors i aplicacions PHP, identificant l’exposició pública.
Actualitzar el runtime o aplicar el pedaç confirmat pel proveïdor.
Verificar els processos web i revisar registres: el pedaç no elimina una intrusió anterior.
Retirar l’exposició innecessària de les aplicacions internes i els accessos directes a l’origen.
Revisar permisos perquè empleats i proveïdors només accedeixin als recursos necessaris.

Un web públic ha de continuar sent públic; una intranet o un panell administratiu no necessàriament. Consulta la plataforma ConnectaSec per valorar el control d’accés als recursos privats.

Les aplicacions privades haurien de continuar sent privades

Una vulnerabilitat en una capa inferior pot afectar una aplicació amb un login ben dissenyat. Actualitzar és imprescindible; reduir l’exposició és una defensa addicional i permanent.

Demana una demo per revisar l’accés a les teves aplicacions internes.

Fonts oficials

Informació revisada el 22 d’octubre de 2026. «PHP2Shell» no figura com a denominació oficial als avisos citats; utilitzem els identificadors CVE.