PHP2Shell: com comprovar la seguretat del teu servidor PHP

Què són les vulnerabilitats PHP2Shell?

Són CVE-2026-109618 i CVE-2026-109619, amb una gravetat de 9,2 sobre 10. Afecten la memòria i l’estat que PHP conserva durant el tractament de peticions. El resultat pot ser execució de codi o divulgació de memòria.

Els casos demostrats inclouen Apache mod_php i PHP-FPM, amb condicions diferents segons el cas. Ni totes les instal·lacions són igualment explotables ni l’atac es resol sempre amb una sola petició.

INCIBE informa d’atacs anteriors als pedaços; CISA deia que no havia observat explotació en publicar l’avís del 21 d’octubre. No afirmem a partir d’això que no hi hagi hagut intrusions.

Quins sistemes has de comprovar?

PHP és habitual en WordPress, WooCommerce, PrestaShop, Joomla i Drupal, però també pot executar eines internes. El problema és al llenguatge, no necessàriament al gestor de continguts.

• Webs corporatives, botigues i aplicacions internes fetes amb PHP.
• CRM, reserves, portals d’usuaris i portals WiFi, si fan servir PHP.
• Panells d’administració: espera la confirmació del fabricant per a cada producte.
• Un equip sense PHP vulnerable no està afectat directament. Windows no és una excepció si el servidor executa PHP.

Què hem aplicat a les webs allotjades amb iDeo?

Segons l’estat operatiu comunicat per iDeo el 22 d’octubre, hem aplicat mesures als nostres servidors per a totes les versions des de PHP 5.6. No presentem aquests ajustos com una solució definitiva.

• Hem desactivat el progrés de pujada de sessions: session.upload_progress.enabled = 0. Tanca una de les vies demostrades.
• Hem activat session.use_strict_mode = 1 com a reforç general de les sessions, no com a pedaç complet de PHP2Shell.
• Estem aplicant progressivament les actualitzacions de PHP 7.4 i posteriors distribuïdes per Plesk i cPanel.
• Si la web depèn de PHP 7.3 o anterior, et contactarem per preparar-ne la migració.

Com revisem els sistemes que mantenim?

El Centre d’Atenció a Usuaris identifica PHP, prioritza els serveis exposats a Internet i comprova què s’ha actualitzat. Quan l’allotjament és extern, demanem una confirmació escrita al proveïdor.

També revisem indicis com errors de memòria, peticions inesperades i fitxers nous. L’absència d’errors al registre no demostra que un sistema sigui segur. Documentem versions i actuacions pendents.

L’actualització requereix reiniciar els processos PHP. Coordinem la intervenció i qualsevol interrupció amb tu, sense donar una durada fixa.

Quines versions incorporen la correcció?

Cal una versió corregida o un paquet amb el pedaç complet documentat pel proveïdor. Les branques sense suport regular necessiten una decisió de migració, encara que disposin d’un pedaç excepcional.

PHP 8.1 i versions anteriors no tenen suport regular. PHP ofereix pedaços excepcionals de codi font per a 7.4, 8.0 i 8.1; verifica el paquet del proveïdor i planifica una migració. PHP 8.2 té suport de seguretat fins al 31-12-2026.

Què pots fer avui com a responsable de la web?

Demana la versió exacta de PHP, la confirmació del pedaç i del reinici. Actualitzar WordPress i els complements no substitueix aquesta feina.

Si detectes canvis inesperats, contacta amb el tècnic i conserva les evidències. Si hi ha una bretxa de dades personals, cal valorar la notificació a l’AEPD: quan és obligatòria, el termini general és de 72 hores des que se’n té coneixement, excepte si és improbable que hi hagi risc per als drets i les llibertats.

Què passa si no pots actualitzar immediatament?

PHP adverteix que no existeix una configuració provisional que ho resolgui tot. Desactivar el progrés de pujada, limitar enviaments o disposar d’un WAF pot reduir vies concretes, però no reemplaça l’actualització.

Els canvis s’han d’aplicar administrativament al servidor i reiniciant els processos, no amb una instrucció dins de WordPress. Acorda com restringir l’exposició mentre es prepara el pedaç.