El passat 21 d’octubre, l’equip que manté PHP va publicar una actualització amb un titular que no es veu sovint: vulnerabilitats crítiques, actualitza ja. Si la teva web està feta amb WordPress, WooCommerce, PrestaShop, Joomla o qualsevol altre gestor basat en PHP —és a dir, la majoria de webs de pimes—, això va amb tu.
T’ho explico sense tecnicismes: què ha passat, per què és més seriós que els avisos de sempre i què has de comprovar aquesta mateixa setmana.
Què és PHP2Shell, en poques paraules
PHP és el llenguatge amb què funcionen per dins la majoria de webs del món. Cada cop que algú entra en una web feta amb WordPress, és PHP qui, al servidor, munta la pàgina i la lliura al visitant.
PHP2Shell és el nom amb què es coneixen dues fallades de seguretat del mateix PHP, registrades com a CVE-2026-109618 i CVE-2026-109619. Totes dues tenen una gravetat de 9,2 sobre 10 i el nom ho resumeix bé: permeten passar de “PHP” a una shell, és a dir, a executar codi al teu servidor amb els mateixos permisos que la teva web.
El pitjor és que no cal usuari ni contrasenya. N’hi ha prou d’enviar al servidor peticions preparades expressament. Perquè te’n facis una idea: no és que algú hagi robat una clau, és que el pany es pot obrir des de fora sabent on empènyer.
Per als curiosos: una de les fallades apareix quan PHP es queda sense memòria a mig preparar una petició i deixa dades internes a mig construir; l’altra fa que restes d’una visita es reutilitzin en la següent que atén el mateix procés. Totes dues acaben igual: codi aliè executant-se al teu servidor.
Per què aquest avís no és com els de sempre
Si tens WordPress, deus estar acostumat als avisos d’“actualitza aquest plugin”. Aquest és diferent per tres motius:
- La fallada no és a la teva web, és al motor. Actualitzar WordPress, el tema o els plugins no ho arregla. El que cal actualitzar és PHP, que viu al servidor i que normalment gestiona el teu proveïdor d’allotjament.
- Afecta gairebé qualsevol manera d’executar PHP: PHP-FPM, Apache amb mod_php, CGI, LiteSpeed… Segons els mateixos desenvolupadors de PHP, qualsevol instal·lació que serveixi pàgines web està en risc, i el risc és màxim amb mod_php, on l’atac pot funcionar fins i tot abans que s’arribi a executar el codi de la teva web.
- No hi va haver marge. Els detalls es van filtrar el 20 d’octubre, abans de la data prevista, i PHP va haver d’avançar un dia la publicació del pedaç. Aquell mateix 21 d’octubre, investigadors de seguretat ja van detectar intents d’explotació als seus servidors trampa. Parlem d’hores, no de setmanes.
Quines versions de PHP estan protegides
| Si la teva web fa servir… | Versió segura |
|---|---|
| PHP 8.5 | 8.5.12 o superior |
| PHP 8.4 | 8.4.27 o superior |
| PHP 8.3 | 8.3.36 o superior |
| PHP 8.2 | 8.2.35 o superior |
| PHP 8.1, 8.0 o 7.4 | Sense versió oficial: només si el teu proveïdor hi ha aplicat el pedaç |
| PHP 7.3 o anterior | Sense solució: cal actualitzar sí o sí |
Amb les versions antigues, el número enganya. PHP 8.1 i anteriors ja no reben actualitzacions oficials, de manera que el pedaç l’apliquen pel seu compte les distribucions de Linux i els panells d’allotjament… sense canviar el número de versió. A Plesk, per exemple, el PHP 8.1.34 corregit es continua dient 8.1.34; el que canvia és la data de compilació. Així que, si la teva web funciona amb una versió antiga, veure “8.1.34” no et diu si estàs protegit: cal preguntar-ho.
I un detall que se li escapa a molta gent: si el teu servidor fa servir Plesk, el mateix panell funciona amb el seu propi PHP, independent del de les webs. Plesk el va corregir a les actualitzacions 18.0.80 Update 11 i 18.0.81 Update 4. Actualitzar el PHP de les webs no actualitza el del panell, ni a l’inrevés.
Què li pot passar al teu negoci si algú hi entra
Un servidor compromès no sempre “cau”. Moltes vegades a l’atacant li interessa passar desapercebut i treure’n profit. El més habitual és això:
- La teva web comença a redirigir a estafes o s’omple de pàgines de correu brossa que Google acaba indexant amb el teu domini.
- Google o el navegador la marquen com a perillosa, i les visites —i les vendes— s’enfonsen d’un dia per l’altre.
- Et roben dades: missatges de formularis, comandes de la botiga en línia, fitxes de clients.
- Fan servir el teu servidor per enviar correu brossa, i els teus correus de debò comencen a acabar a la carpeta de correu no desitjat dels teus clients.
A més, si hi ha dades personals afectades, el RGPD t’obliga a notificar-ho a l’Agència Espanyola de Protecció de Dades en un màxim de 72 hores des que te n’assabentes, tret que sigui improbable que comporti un risc per a les persones (i, si el risc és alt, també cal avisar els afectats). Netejar un servidor, recuperar la reputació a Google i donar explicacions als clients costa moltíssim més que una actualització a temps.
Què cal fer aquesta setmana: llista de comprovació
- Esbrina quina versió de PHP fa servir la teva web. A WordPress la trobaràs a Eines → Salut del lloc → Informació → Servidor. Si tens accés a Plesk, a la configuració de PHP del teu domini.
- Demana al teu proveïdor d’allotjament una confirmació per escrit: si el PHP de la teva web i el del panell ja tenen el pedaç, i des de quina data. En un allotjament compartit no pots actualitzar PHP tu mateix; és responsabilitat seva.
- Si vas amb PHP 7.4, 8.0 o 8.1, planifica el salt a 8.3 o 8.4. El pedaç del proveïdor et treu del mal pas, però aquestes versions ja no reben manteniment oficial. Abans de canviar, prova en una còpia que el tema i els plugins són compatibles.
- Després d’actualitzar, prova el que et fa guanyar diners: formularis, cistella i pagament, reserves, connexions amb altres eines.
- Busca senyals estranys: usuaris administradors que no coneixes, fitxers
.phpdins de la carpeta d’imatges (wp-content/uploads), redireccions estranyes o avisos nous a Google Search Console. - Tingues còpies de seguretat fora del servidor i comprova que es poden restaurar. Si alguna cosa ha anat malament, una còpia neta d’abans de l’atac és el teu millor salvavides.
Si gestiones el teu propi servidor i encara no pots actualitzar, PHP recomana com a mesura temporal desactivar session.upload_progress i reiniciar els processos de PHP. Ells mateixos avisen que no és una solució completa: l’única solució de debò és el pedaç.
I si sospites que ja t’han atacat, no ho deixis per demà: canvia les contrasenyes (panell, FTP, base de dades i WordPress), restaura una còpia neta i, si necessites orientació, truca al 017, la línia gratuïta d’ajuda en ciberseguretat de l’INCIBE per a empreses i particulars.
I si la meva web és estàtica?
Una web estàtica —com les que faig amb Astro— lliura al visitant fitxers HTML ja preparats: no hi ha PHP executant-se a cada visita, així que aquesta vulnerabilitat no té per on entrar a través de la web. És un dels avantatges dels quals vaig parlar en comparar Astro i WordPress.
Però no et vull vendre fum: que la web sigui estàtica no fa invulnerable el servidor. Si al mateix allotjament hi ha un panell com Plesk, un blog en WordPress o un formulari en PHP, tot això també s’ha de tenir al dia.
La lliçó que deixa PHP2Shell
Una web no és una cosa que es fa una vegada i s’oblida. Al darrere hi ha un servidor, un llenguatge, un panell, un gestor de continguts i els seus plugins, i cada peça necessita el seu manteniment. La pregunta important no és “la meva web és segura?”, sinó “qui s’encarrega d’actualitzar cada peça, i com m’assabento que ho ha fet?”. Si no tens clara la resposta, aquest és el primer forat que cal tapar.
No saps quina versió de PHP fa servir la teva web o qui la manté? Escriu-me i ho mirem junts. I si estàs pensant a canviar d’allotjament, aquí tens els meus plans, amb SSL, còpies de seguretat automàtiques i suport tècnic.
Fonts: