La semana pasada contábamos qué es PHP2Shell: dos fallos críticos del motor PHP que permiten ejecutar código en tu servidor sin usuario ni contraseña, con explotación observada el mismo día del parche. Esta es la parte práctica: comprobar tu versión, actualizarla y revisar que nadie ha entrado ya.
Si llegas aquí sin haber leído nada del tema, este es el contexto completo. Aquí vamos al grano.
Paso 1: saber qué versión de PHP corre tu web
Cualquiera de estas vías te lo dice en un par de minutos:
- WordPress: Herramientas → Salud del sitio → pestaña Información → sección Servidor. Ahí aparece la versión de PHP.
- Panel del hosting (Plesk, cPanel y similares): busca el selector de versión de PHP de tu dominio. Muchos paneles lo muestran en la portada del sitio.
- Por SSH, en tu propio servidor: ejecuta `php -v`. Si usas PHP-FPM, también `php-fpm8.3 -v` (o la rama que tengas).
- Último recurso: un fichero con `<?php phpinfo();` subido por FTP, abrirlo en el navegador y borrarlo inmediatamente después.
Lo que estás buscando: que la versión sea 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o superior dentro de cada rama. Si ves 8.1.x, 8.0.x o 7.x, estás fuera de soporte y sin parche oficial: salta al apartado de versiones antiguas.
Paso 2: actualizar según dónde vive tu web
Hosting compartido
- Entra en el panel y cambia la versión de PHP de tu dominio a una corregida. Si no aparece ninguna 8.2.35+, abre ticket con soporte y pide fecha de actualización por escrito.
- Tras el cambio, recorre tu web con calma: formularios, carrito, login. Algunos plugins o temas viejos rompen con versiones nuevas de PHP.
VPS o servidor propio
- Debian/Ubuntu: `apt update && apt install --only-upgrade php8.3 php8.3-fpm` (ajusta la rama). Si tu distribución no trae la versión corregida en sus repos oficiales, el paquete viene del repositorio que gestiona tu PHP (por ejemplo Sury en Debian).
- Reinicia los workers: `systemctl restart php8.3-fpm`, o Apache si usas mod_php. Un parche instalado sin reiniciar no protege: los procesos viejos siguen en memoria.
- Comprueba `php -v`, que la web carga y que los formularios siguen enviando.
Docker
- Actualiza la imagen base del contenedor a la versión corregida y haz redeploy completo. Reiniciar el contenedor viejo no cambia nada: la imagen sigue siendo la vulnerable.
Si estás en PHP 8.1 o anterior
No hay parche oficial. Las opciones reales, de menos a más trabajo:
- Backport del distribuidor: Ubuntu Pro, RHEL y proveedores de hosting con CloudLinux publican parches propios para ramas antiguas. Pregúntalo.
- Migrar la web a PHP 8.2 o superior. Es lo que toca de todos modos: esas ramas llevan años sin soporte y esto no va a ser el último fallo.
- Mientras tanto: aísla la web del público si puedes, revisa logs a diario y ponle fecha al plan de migración. Una fecha en el calendario también es una medida de seguridad.
WordPress, después de actualizar PHP
- Actualiza el core de WordPress, los plugins y el tema. Convivirán mejor con la versión nueva y cierras otras puertas.
- Revisa Salud del sitio: WordPress te avisa si algo choca con la versión de PHP.
- Elimina plugins «gestores de compatibilidad» que fuerzan versiones viejas: suelen ser la razón por la que tu web lleva años en 7.x.
Comprobar que nadie ha entrado ya
El parche cierra la puerta hacia adelante. Hacia atrás, dedica diez minutos a revisar:
- Logs de acceso: peticiones raras — subidas de ficheros, URLs con `base64` largo, ficheros `.php` que no reconoces en rutas de subidas.
- Procesos: `ps aux | grep php` y busca shells, `wget http`, `curl` colgando o procesos de Python que no encajan.
- Directorio de subidas: en uploads solo deberían haber imágenes y documentos. Un `.php` ahí dentro es una alarma.
- Tareas programadas: `crontab -l` en el servidor y el planificador de tareas del hosting. Entradas que no reconoces, fuera.
Si algo huele mal: copia de seguridad completa primero, limpieza después y cambio de contraseñas al final. Y si no tienes claro lo que estás viendo, mejor un par de ojos externos esa misma semana que tres meses de dudas.
Si hoy no puedes actualizar
- Aisla: si la web es interna o de demo, sácala de internet hasta parchear. Es lo que recomiendan CISA y ENISA.
- WAF como parche parcial: un firewall de aplicaciones reduce el riesgo pero no lo elimina. El propio PHP lo avisa: ningún cambio de configuración mitiga del todo.
- Prioriza por impacto: primero la web que trae clientes, después las secundarias. Si hay que elegir, no lo dudas.
La lista rápida
- Versión de PHP corregida: 8.2.35, 8.3.36, 8.4.27 o 8.5.12, o superior en su rama.
- Workers reiniciados después de instalar el parche.
- CMS, plugins y temas actualizados tras el cambio de versión.
- Logs, procesos y subidas revisados.
- Si corres 8.1 o anterior: parche del distribuidor o migración con fecha.
Actualizar es el único camino que cierra PHP2Shell del todo. Y si mantener esto al día se ha convertido en el cuello de botella de tu semana, ahí estamos: automatizamos el mantenimiento y la vigilancia para que estas actualizaciones no dependan de que alguien se acuerde. Cuéntanos tu caso en contacto.