PHP2Shell, execució remota de codi a PHP

Què ha passat?

PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35 corregeixen dues vulnerabilitats crítiques que poden permetre l'execució remota de codi sense autenticació, i l'equip de PHP recomana encaridament actualitzar immediatament. Les vulnerabilitats es coneixen com PHP2Shell.

El cas és especialment urgent perquè els detalls es van filtrar a internet el 20 d'octubre, abans de la divulgació coordinada i abans que hi hagués el pegat. Investigadors de watchTowr han confirmat que les vulnerabilitats són reals i han reproduït CVE-2026-109618.

• CVE-2026-109618 (RCE per corrupció de memòria després de falta de memòria): la gestió d'errors per manca de memòria pot interrompre PHP mentre les dades internes de la petició només estan parcialment inicialitzades, i la neteja posterior pot tractar-les com a vàlids.
• CVE-2026-109619 (RCE per estat global residual): cert estat intern d'una petició pot sobreviure després d'alliberar-ne la memòria, i una petició posterior atesa pel mateix procés el pot reutilitzar abans que es reinicialitzi.

A Espanya, INCIBE-CERT ha publicat un avís sobre aquestes vulnerabilitats amb importància 5 sobre 5 (crítica). Segons INCIBE, l'equip de PHP indica que totes les versions podrien estar afectades, encara que les proves només s'han fet a les versions 5 a 8. En el moment de publicar el seu avís, INCIBE no tenia constància d'explotació activa de cap dels dos CVE.

A qui afecta?

A pràcticament qualsevol organització amb una web o aplicació a PHP (WordPress, PrestaShop, Magento, intranets, ERPs web, etc.). Segons PHP, estan en risc totes les instal·lacions que serveixen peticions web, incloent-hi PHP-FPM, Apache amb mod_php, php-cgi, FrankenPHP i LiteSpeed. El risc més alt és amb mod_php, on s'ha demostrat un exploit on una petició sense autenticació pot desencadenar l'atac abans que s'executi cap codi de l'aplicació.

A escala global, Palo Alto Networks ha identificat més de 22,6 milions d'instàncies exposades potencialment vulnerables.

Què cal fer?

1. Inventariar. Localitzar tots els sistemes amb PHP, començant pels exposats a internet, sense limitar-se a les versions antigues, ja que totes poden estar afectades.
2. Actualitzar ja a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 segons la branca. Les distribucions Linux i els proveïdors LTS van rebre els pegats per endavant, així que convé consultar si ja hi ha paquets actualitzats. Per comprovar-ho, es pot revisar el changelog del paquet (per exemple apt changelog php8.3-cli o rpm -q --changelog php) i buscar el número del CVE.
3. Si uses el repositori Remi: PHP recomana passar als paquets de la distribució o compilar des de codi font, ja que aquest dipòsit no tindrà actualitzacions avui.
4. Hosting compartit: confirmar amb el proveïdor que ha aplicat el pegat a totes les versions de PHP que ofereix.
5. Versions sense suport (8.1 o anterior): ja no reben actualitzacions del projecte PHP; algunes distribucions i proveïdors LTS ofereixen correccions adaptades. Donada la gravetat, l'equip de PHP ha publicat pedaços mínims per a PHP 7.4, 8.0 i 8.1 per a qui compile des de codi font. Tot i així, el recomanable és migrar a una versió amb suport.
6. Programari de tercers: vigileu les actualitzacions d'appliances i productes que incloguin PHP. El NCSC-NL ha publicat un inventari de productes amb dependència de PHP potencialment afectats.
7. Si no es pot actualitzar immediatament, aplicar les mitigacions temporals oficials. Només l'actualització és una solució completa; aquestes mesures redueixen lexposició a vies datac concretes, però no fan la instal· lació segura.
   
   • CVE-2026-109618: establir memory_limit=-1 de manera que les aplicacions no puguin sobreescriure'l (per exemple amb php_admin_value), fixar un post_max_size baix (8M sense pujada de fitxers, 32M si són necessàries) i utilitzar un límit de contenidor o cgroup com a barrera de disponibilitat. ⚠️ Treure el límit de memòria sense un límit de cgroup o contenidor pot deixar el servidor sense RAM.
   • CVE-2026-109619: establir session.upload_progress.enabled=0 i reiniciar tots els workers, configurant-ho a php.ini, el pool de FPM o el servidor (no mitjançant ini_set() ni .user.ini); a PHP 8.5, a més, fatal_error_backtraces=0.
8. Darrer recurs: si no es pot apedaçar ni mitigar a temps, valorar desconnectar el sistema fins a poder protegir-lo.
9. Revisar possibles compromisos. En sistemes que han estat exposats sense pegat, cercar indicis d'intrusió i portes del darrere.

Necessites ajuda?

Si no tens clar quina versió de PHP usen els teus webs o servidors, o vols que revisem la teva exposició, contacta amb l´equip d´Infordisa i us ajudem a avaluar i aplicar les actualitzacions.

Fonts:
Avís de seguretat oficial de PHP · INCIBE-CERT · NCSC · Avisos tècnics a GitHub