PHP2Shell: ¿está en riesgo mi sitio WordPress y qué hacer?

Cualquier sitio WordPress que funcione con una versión de PHP de php.net anterior a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 es vulnerable a PHP2Shell (los paquetes de las distribuciones Linux tienen sus propios números de versión, más abajo lo explico). Estas cuatro versiones de PHP salieron el 21 de octubre de 2026 y corrigen dos vulnerabilidades críticas que permiten ejecutar código de forma remota sin iniciar sesión. El fallo está en PHP, así que actualizar WordPress, el tema o los plugins no lo elimina. Hay que actualizar PHP en el servidor o asegurarse de que el hosting ya lo ha hecho.

El aviso de cada una de las cuatro versiones en php.net incluye la misma frase:

No hay mitigaciones completas, actualizar es la única opción segura.

(traducción propia, php.net, anuncios de las versiones del 21 de octubre de 2026)

#Qué es PHP2Shell

PHP2Shell son dos errores del motor de PHP que, según la página de los propios investigadores, descubrieron Calif, OpenAI y Wiz. La investigación y la descripción son obra de Ryan Austin, de Calif, y los errores se encontraron dentro de la iniciativa Patch the Planet de OpenAI (Calif). Wiz Research publicó su propio análisis (Wiz). El proyecto PHP los registra como dos vulnerabilidades:

Ambas son errores de seguridad de memoria del tipo use-after-free en la forma en que PHP gestiona los errores fatales, incluidos los de falta de memoria, y una petición HTTP manipulada puede provocarlos antes de que se ejecute cualquier código de WordPress. Las entradas de la base de datos GitHub Security Advisories del repositorio php-src se publicaron el 21 de octubre de 2026 a las 13:34 UTC. Señalan como vulnerables todas las versiones inferiores a 8.2.35, 8.3.36, 8.4.27 y 8.5.12 (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).

Según la cronología que publicó Calif, los investigadores comunicaron el primer error al proyecto PHP el 11 de agosto de 2026, PHP confirmó el 15 de agosto que su prueba de concepto de ejecución remota de código funcionaba, y las versiones corregidas salieron el 21 de octubre de 2026 (Calif).

Un día antes, el 20 de octubre, el equipo de seguridad de PHP anunció la publicación para el 21 de octubre a las 14:00 UTC e indicó que ambas vulnerabilidades tienen una puntuación de 9.2 en la escala CVSS v4.0 (php.net, anuncio del 20 de octubre).

Hacia las 16:05, hora peninsular española (14:05 UTC), la web de Wordfence solo mostraba este mensaje: “Los servicios de Wordfence no están disponibles temporalmente mientras implementamos medidas de mitigación para la vulnerabilidad PHP2Shell, que aún no tiene parche. Gracias por tu paciencia.” (traducción propia, web wordfence.com, estado del 21 de octubre de 2026 hacia las 16:05). Al volver a comprobarlo a las 17:16, hora peninsular (15:16 UTC), la web seguía mostrando solo ese mensaje. Incluso un proveedor de seguridad para WordPress desactivó sus propios servicios durante ese tiempo para aplicar protecciones.

El centro estatal de TIC de Finlandia, Valtori, empezó a desconectar por precaución servicios web públicos de la administración central poco después de las 13:00, hora finlandesa, del 21 de octubre, y la web del servicio finlandés de catastro y cartografía, Maanmittauslaitos, ya no funcionaba a las 15:11 (Yle News). La Universidad de Friburgo anunció a las 10:39, hora local, que sus webs y servicios clave iban a quedar fuera de línea (centro de cálculo de la Universidad de Friburgo).

En los Países Bajos, NOS informó a las 11:10, hora peninsular española, de que la Tweede Kamer, el NCSC, la Autoriteit Persoonsgegevens y Tweakers habían desconectado sus webs, y de que NotuBiz, el sistema que usan unos cien municipios para los plenos, había dejado de funcionar esa mañana (NOS). La web de la Universidad de Viena y la wiki explain xkcd también estuvieron temporalmente fuera de línea (ORF, explain xkcd). W3Techs registra PHP en el 69,3 % de los sitios cuyo lenguaje del lado del servidor conoce (datos del 23 de octubre de 2026). Por eso un solo error en el intérprete llevó a tantas organizaciones a desconectar sus webs a la vez (W3Techs).

De la publicación de Wiz Research, al propietario de un sitio le afectan tres conclusiones:

• son vulnerables las versiones de PHP desde la 5.4,
• en las pruebas de Wiz, la ejecución remota de código sin autenticación funcionó en la imagen de contenedor wordpress:latest, y también en Drupal y Joomla,
• un error independiente permite leer un fragmento de la memoria del proceso PHP, donde puede haber contraseñas, tokens de autenticación, claves de API y certificados, incluso cuando la aplicación no inicia ninguna sesión (session_start()).

Wiz señala además que, aparte de los cuatro errores descritos, existen otras variantes del mismo problema, y que la corrección del proyecto PHP las elimina todas (Wiz).

#¿Es vulnerable mi sitio WordPress?

Sí, si funciona con una versión de PHP inferior a la versión corregida de su rama. Según php.net, está en riesgo cualquier instalación de PHP que atienda peticiones web: PHP-FPM, Apache con el módulo mod_php, php-cgi, FrankenPHP y LiteSpeed. php.net atribuye el mayor riesgo a las configuraciones con mod_php, para las que existe un exploit demostrado que se lanza con una petición sin autenticar, antes de que arranque el código de la aplicación (php.net). Automattic escribió el 21 de octubre de 2026 que los sitios alojados en WordPress.com, WordPress VIP, WP Cloud, Pressable y Tumblr ya están protegidos y que sus propietarios no tienen que hacer nada (Automattic), así que la actualización afecta a los sitios cuyo PHP gestiona el propio dueño u otro proveedor de hosting.

La versión de WordPress, del tema y de los plugins no importa aquí, porque el error está en el intérprete de PHP y las actualizaciones automáticas de WordPress no tocan el PHP del servidor. Tampoco protege la calidad del código del sitio: según Wiz, hasta una aplicación sencilla tipo “Hello World” en una versión vulnerable de PHP puede ser objetivo de un ataque. Un plugin de seguridad funciona dentro de WordPress, y la petición puede provocar el error antes de que WordPress se cargue.

Una tienda WooCommerce tiene más que perder en esta situación que una web corporativa. En la base de datos y en la configuración están los datos de los clientes, los pedidos y las claves de las pasarelas de pago, y la exposición de la memoria del proceso afecta justo a ese tipo de secretos.

Calif confirmó la ejecución remota de código sin autenticación en WordPress 7.1.2 y, entre otras aplicaciones, también en Magento 2.4.9, phpMyAdmin 5.2.3 y WHMCS (Calif). En mi opinión, un phpMyAdmin o un panel de cliente que funcione con el PHP del mismo servidor queda expuesto de la misma forma, así que el servidor necesita la actualización de PHP aunque el propio WordPress no sea accesible.

Los sitios estáticos quedan fuera del alcance de este fallo. Si el sitio se genera en archivos HTML y el servidor no ejecuta PHP al atender peticiones, el aviso de php.net no le afecta, porque describe instalaciones de PHP que atienden peticiones web.

#Cómo comprobar la versión de PHP en un sitio WordPress

El camino más sencillo pasa por el escritorio de WordPress:

1. Inicia sesión como administrador.
2. Abre Herramientas, Salud del sitio.
3. Ve a la pestaña Información y despliega la sección Servidor.
4. Lee la fila de la versión de PHP.

Compara el número con la tabla:

Las fechas de soporte proceden de la tabla de versiones con soporte de php.net.

La versión de PHP que aparece en Salud del sitio es la que sirve la web. El panel del hosting puede mostrar otra versión para la línea de comandos o para otro dominio de la misma cuenta, así que lo que cuenta es la lectura de WordPress.

La excepción son los paquetes de las distribuciones Linux. Según php.net, las distribuciones y los proveedores de soporte LTS recibieron las correcciones antes y publican sus propios paquetes (php.net). Si usas el repositorio rpms.remirepo.net, mantenido por voluntarios, php.net te insta a pasarte a los paquetes de la distribución o a compilar desde el código fuente para poder aplicar las actualizaciones de inmediato, y avisó de que el repositorio no tendría actualizaciones el día de la publicación (php.net, 21 de octubre de 2026). Una distribución aplica la corrección en su propia versión de PHP y mantiene su número. Ubuntu 24.04 LTS corrigió PHP con el paquete 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), así que un sitio ya corregido en un servidor así sigue mostrando 8.3.6 en Salud del sitio. Debian 13 (trixie) recibió php8.4 en la versión 8.4.27-1~deb13u1 (DSA-6574-1), mientras que el rastreador de seguridad de Debian seguía marcando php8.2 de Debian 12 (bookworm) como vulnerable cuando lo comprobé, el 21 de octubre de 2026 a las 15:14 UTC (Debian security tracker). En un VPS con PHP del repositorio de la distribución, el número de versión por sí solo no zanja la cuestión. Comprueba en el aviso de seguridad de la distribución o en el registro de cambios del paquete si la actualización incluye las correcciones de CVE-2026-109618 y CVE-2026-109619 y, en un hosting, pregunta a la empresa de hosting.

#Qué hacer si el hosting aún no ha actualizado PHP

En un hosting compartido, la actualización de PHP la hace la empresa de hosting. Como propietario del sitio, tienes cuatro opciones:

1. Cambiar la versión en el panel. Muchos paneles de hosting permiten elegir la versión de PHP por dominio. Si en la lista ya hay una versión con la corrección, cambia el sitio a esa versión y compruébalo en Salud del sitio.
2. Abrir una incidencia con el hosting. Escribe al soporte técnico con los números CVE-2026-109618 y CVE-2026-109619 y pregunta cuándo recibirá el servidor PHP 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o un paquete con esas correcciones.
3. Copia de seguridad antes del cambio. Pasar a una rama más reciente de PHP puede inutilizar un plugin o un tema antiguo. Una copia de los archivos y de la base de datos de antes del cambio acorta la vuelta a un sitio que funcione.
4. Desconectar el sitio hasta la actualización. Si PHP no se puede actualizar pronto, desconecta el sitio o muestra en su lugar una página estática de mantenimiento servida sin PHP. Nota mía: un plugin de modo mantenimiento de WordPress no basta, porque la petición sigue llegando a PHP. John Mueller, de Google, escribió el 21 de octubre: “Si estás desconectando sitios PHP para ganar tiempo y ocuparte de actualizaciones no planificadas, usa HTTP 503 en lugar de dejar que las respuestas agoten el tiempo de espera o devuelvan 404 o 500. Puedes hacerlo fuera de PHP, apuntar el DNS a otro sitio o usar una CDN.” (traducción propia, John Mueller, Bluesky). La página de mantenimiento con código 503 la sirve entonces el servidor web, la CDN u otro servidor tras un cambio de DNS, sin PHP, porque una página de mantenimiento con código 200, los tiempos de espera agotados, un 404 o un 500 pueden perjudicar la indexación. Google Search Central recomienda 503 cuando hay que desactivar un sitio con urgencia durante 1 o 2 días, una página de inicio indexable con código 200 para una pausa más larga, y desaconseja devolver 503 para robots.txt (Google Search Central).

WordPress.org escribió el 21 de octubre que los fallos no son específicos de WordPress y que no hace falta ni está prevista ninguna actualización de WordPress (WordPress.org). La misma entrada aconseja a quien gestiona su propio servidor con PHP anterior a 8.2 que valore desconectarlo mientras prepara la actualización, y remite al NCSC británico. El NCSC recomienda valorar desconectar el sistema hasta que esté protegido por completo si las medidas temporales no se pueden aplicar con suficiente rapidez (NCSC). CERT Polska recomendó ya antes de la publicación desactivar temporalmente los servicios PHP accesibles desde Internet (CERT Polska, 195/2026) e indica sus propios valores para php.ini en el aviso 196/2026. Patchstack da el mismo consejo para sitios de alto riesgo y advierte contra plugins de “corrección” no oficiales y fragmentos de código copiados, que “no están verificados y pueden romper tu sitio” (traducción propia, Patchstack). Un plugin se ejecuta dentro de PHP, así que no puede corregir un fallo del propio PHP.

php.net describe ajustes temporales del servidor para los administradores que no pueden actualizar PHP de inmediato. Incluyen, entre otros, límites de tamaño de las peticiones y la desactivación del seguimiento del progreso de subida de archivos en la sesión. Estos ajustes solo funcionan a nivel de configuración del servidor: php.net advierte que, para el ajuste de sesión, no bastan ini_set() ni un archivo .user.ini en el directorio del sitio. El aviso subraya también que ninguno de estos ajustes hace segura una instalación:

Aunque solo una actualización es una solución completa, las siguientes medidas reducen la exposición a vías de ataque concretas, pero no hacen segura una instalación.

(traducción propia, php.net, aviso de seguridad del 21 de octubre de 2026)

Como medida temporal y parcial, Calif indica session.upload_progress.enabled=0 junto con memory_limit=-1 para PHP-FPM y solo memory_limit=-1 para mod_php, y advierte de que el valor -1 elimina el límite de memoria de PHP, lo que aumenta el riesgo de que la memoria se agote (Calif).

Los advisories del proyecto PHP asignan cada medida provisional a una vulnerabilidad concreta. Para CVE-2026-109618, fijar e imponer memory_limit=-1 es la principal mitigación en la configuración. El advisory aclara que no es completa, porque una asignación de memoria fallida todavía puede llevar a PHP por la ruta vulnerable, y desaconseja RLIMIT_AS y RLIMIT_DATA, que activan justo esa ruta. También recomienda un post_max_size prudente, aplicado además en el servidor situado delante de PHP, límites al número de partes multipart, cabeceras y subidas, y bloquear allí las peticiones multipart si la aplicación no las usa. Con el parche, PHP lanza un error leve de falta de memoria en un punto seguro y solo termina el proceso cuando el consumo alcanza un segundo umbral, más alto (GHSA-w8hw-w9fx-j79w). El ajuste session.upload_progress.enabled=0 procede del advisory de CVE-2026-109619, que indica que solo cubre la ruta del ciclo de vida de la sesión demostrada allí y no las demás (GHSA-6wmf-4rv5-p3rp). Nota mía: WordPress usa peticiones multipart para subir archivos a la biblioteca de medios y en muchos formularios, así que bloquearlas por completo rompe el panel y los formularios. Esa opción solo encaja en sitios que no reciben archivos.

Para CVE-2026-109619 en PHP 8.5, php.net indica también fatal_error_backtraces=0 con el reinicio de todos los procesos de trabajo, y dice que esto solo bloquea la ruta confirmada a través del backtrace de errores fatales (php.net, 21 de octubre de 2026). El mismo aviso recomienda eliminar ajustes de PHP no válidos u obsoletos aplicados en cada petición que generen avisos antes de la inicialización, y ocultar los avisos con error_reporting, display_errors o @ no ayuda. Ejemplo mío, no de php.net: desde PHP 8.3 todos los ajustes INI assert.* están obsoletos, así que en PHP 8.3 y versiones posteriores revisa .htaccess, los pools de FPM y php.ini en busca de entradas assert.* que hayan quedado, por ejemplo php_value assert.active.

Actualización del 24 de octubre de 2026. Las versiones del 21 de octubre no cierran todas las vías. El 23 de octubre, php.net publicó un aviso informativo sobre otro vector de ejecución remota de código, CVE-2026-115560. El proyecto PHP lo considera poco probable en la práctica, lo corregirá en la próxima versión ordinaria de corrección de errores y solo entonces publicará el aviso completo. Afecta, por tanto, también a servidores ya actualizados, pero exige tres condiciones a la vez: la configuración fija session.serialize_handler en php_binary o php_serialize, la aplicación lo cambia a php en tiempo de ejecución con ini_set() antes de llamar a session_start(), y el seguimiento del progreso de subida en la sesión sigue activado. Las aplicaciones que nunca cambian el serializador en tiempo de ejecución pueden dejar la función activada. Hasta esa versión, php.net sugiere session.upload_progress.enabled=0. Si ya lo configuraste el 21 de octubre como mitigación de CVE-2026-109619, mantenlo y no tienes que hacer nada más (php.net, 23 de octubre de 2026). Cómo aplicarlo lo explica el aviso del 21 de octubre: en php.ini, en un pool de FPM o en la configuración del servidor, no mediante ini_set() ni .user.ini, y después reiniciar todos los procesos de trabajo. En un hosting compartido, por tanto, es una petición a tu proveedor. Nota mía: para saber si algún código de tu servidor cambia el serializador, busca session.serialize_handler en los plugins, temas y código propio, por ejemplo con grep -rn "session.serialize_handler" wp-content/.

He reunido los detalles de estos ajustes para el administrador del servidor en la sección sobre la versión crítica de PHP de mi guía de seguridad para WordPress.

Si el tráfico del sitio pasa por Cloudflare (nube naranja en el registro DNS), hay una capa adicional. Según Cloudflare, desde las 05:02 del 21 de octubre de 2026, hora peninsular (03:02 UTC), los clientes con el WAF gratuito o de pago quedaron protegidos contra PHP2Shell por defecto, también en el plan Free, y en los planes Pro, Business y Enterprise conviene comprobar que el Managed Ruleset está desplegado en modo de bloqueo (Cloudflare). Patchstack matiza que estas reglas solo ayudan si el servidor acepta tráfico únicamente de Cloudflare (Patchstack). Si el servidor responde a cualquiera, una petición enviada directamente a su dirección IP esquiva el WAF. Cloudflare indica además que observó tráfico de ataque contra sus clientes antes de la publicación oficial, después de que la vulnerabilidad se filtrara, y atacantes que modificaban la carga del ataque para esquivar las reglas. La cronología de Patchstack recoge a las 07:34 UTC “varios incidentes de explotación activa notificados a Patchstack por socios de hosting” (traducción propia, Patchstack), mientras que Huntress escribió que no había visto explotación entre sus socios hasta las 10:00, hora de la costa este de EE. UU. (14:00 UTC), del 21 de octubre (Huntress). La propia Cloudflare presenta el WAF como una capa adicional de defensa y recomienda actualizar PHP de todos modos, y limitar las subidas de archivos y su tamaño tampoco sustituye a la corrección.

Actualización del 23 de octubre de 2026. Un día después de las correcciones, Wordfence informó de que no había observado ningún compromiso confirmado por estas dos vulnerabilidades en los más de cinco millones de sitios WordPress que protege, mientras el cortafuegos de la empresa había interceptado más de 74 000 intentos de ataque y sondeo. En una muestra de peticiones del 20 al 22 de octubre, que la propia Wordfence considera no representativa de todo el tráfico, las peticiones intentan leer .env y wp-config.php, ejecutar comandos como id y uname -a y escribir una shell PHP llamada wp2s.php en carpetas con permiso de escritura para subidas, plugins o temas. Muestran intención, no ataques logrados. Wordfence añade que la ausencia de compromisos confirmados en los datos de la empresa no hace seguro un servidor sin actualizar, porque algunos fallos ocurren fuera de WordPress y de los registros de WordPress (Wordfence, 22 de octubre de 2026). En servidores Debian y Ubuntu que instalan PHP desde el repositorio deb.sury.org, los paquetes los prepara Ondřej Surý, desarrollador de Debian en cuyo trabajo se basan los paquetes PHP oficiales de Debian y Ubuntu. Él mismo escribe que lo hace sobre todo en ratos libres (deb.sury.org). Cuando lo comprobé el 23 de octubre, el repositorio para Debian 12 ya tenía las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12, compiladas el 21 de octubre (packages.sury.org). Esto vale para cualquier aplicación PHP, ya sea una tienda, un CRM u otro CMS: comprueba quién compila los paquetes PHP de tu servidor y si tu rama sigue recibiendo correcciones, compara la versión instalada con la corregida y reinicia todos los procesos PHP tras actualizar. Vigilar esto en los servidores de clientes forma parte de mi mantenimiento WordPress.

#Cómo detectar un intento de ataque en los registros del servidor

Wiz advierte de que los errores actúan por debajo de la capa de aplicación, así que los registros de WordPress pueden mostrar poco. Hasta la actualización, conviene buscar tres señales en los registros del servidor (Wiz):

• peticiones multipart inusuales seguidas de errores por superar el límite de memoria o de respuestas HTTP 500 repetidas,
• cookies PHPSESSID inesperadamente grandes o malformadas en las respuestas del servidor,
• reinicios sin explicación de los procesos de trabajo de PHP.

Estas señales indican por dónde empezar a revisar. Que no aparezcan no significa que no haya habido un ataque, y que aparezcan no sustituye a la actualización.

Actualización, 28 de octubre de 2026. Una semana después de los parches, Wordfence sigue sin conocer ningún sitio WordPress comprometido mediante PHP2Shell, y su equipo de limpieza de sitios no ha atendido ningún caso así. Los intentos continúan: una regla de monitorización específica registró entre el 23 y el 27 de octubre unas 77.600 peticiones relacionadas desde más de 2.000 direcciones IP, y ninguna parecía tráfico normal de visitantes. Las herramientas creadas para estos fallos aparecieron en los datos de Wordfence el 21 de octubre, unas cuatro horas antes del anuncio público. En el laboratorio de Wordfence, un exploit de prueba ejecutó código en una compilación de PHP configurada a propósito, pero en una compilación normal y optimizada de la misma versión solo tumbó el proceso. El exploit hay que adaptarlo a cada servidor, lo que frena los ataques masivos y no arregla nada (Wordfence, 28 de octubre de 2026). En un servidor propio comprueba dos cosas. find wp-content -name "*.php" -newermt 2026-10-17 lista los archivos PHP creados o modificados desde el 17 de octubre, y en wp-content/uploads no debería haber ninguno. cat /proc/sys/kernel/randomize_va_space debería devolver 2, es decir, aleatorización completa del espacio de direcciones (ASLR). Guarda los registros del servidor web, de PHP y del cortafuegos desde el 17 de octubre hasta el día en que PHP se actualizó y se reinició. Si encuentras un archivo que no pusiste tú o una cuenta de administrador desconocida, trata el sitio como comprometido: primero una copia del estado actual como prueba, después una contraseña nueva para la base de datos y claves nuevas en wp-config.php. Si hay datos personales afectados, el artículo 33 del RGPD da 72 horas para notificarlo a la AEPD. Así trabajo en la eliminación de malware en WordPress.

#¿Hay que cambiar las contraseñas después de la actualización?

El aviso de php.net no exige cambiar contraseñas. Es una recomendación mía, basada en la conclusión de Wiz: el fallo permite leer la memoria del proceso PHP, donde puede haber contraseñas, tokens y claves de API de otras peticiones (Wiz). Un sitio que funcionó durante un tiempo con una versión vulnerable puede haber expuesto un secreto así sin dejar rastro en el escritorio de WordPress.

Los secretos se cambian solo después de actualizar PHP, porque una contraseña nueva establecida en un servidor sin parchear puede filtrarse por la misma vía que la antigua.

Qué cambiar:

• Las claves y las sales de wp-config.php. El generador oficial de WordPress.org crea un nuevo juego de las ocho constantes. Tras el cambio, se cierra la sesión de todos los usuarios conectados.
• La contraseña de la base de datos. Cámbiala en el panel del hosting y escribe la nueva en wp-config.php como DB_PASSWORD.
• Las contraseñas de las cuentas de administrador y de otras cuentas con permisos de edición.
• Las claves de API: claves de la REST API de WooCommerce, claves de las pasarelas de pago, credenciales SMTP y tokens de servicios externos guardados en los ajustes de los plugins.

#Qué pasa con PHP 7.4, 8.0 y 8.1

El proyecto PHP ya no publica correcciones para PHP 8.1 y anteriores. El aviso de php.net indica dos caminos: algunas distribuciones y proveedores LTS ofrecen correcciones adaptadas, y el resto debería pasar a una versión con soporte. Dada la gravedad de los fallos, el equipo de seguridad de PHP publicó parches mínimos de código fuente para PHP 7.4, 8.0 y 8.1, pensados para quien compila PHP desde el código fuente o no tiene acceso a un proveedor LTS (php.net).

Si tu sitio está en un hosting compartido, los parches de código fuente no cambian nada, porque en un servidor así quien compila e instala PHP es el hosting. La opción real es pasar a PHP 8.3, 8.4 u 8.5 en la versión con la corrección. PHP 8.2 también recibió la corrección, pero su soporte de seguridad termina el 31 de diciembre de 2026 (php.net), así que elegir 8.2 supone otro cambio dentro de dos meses.

La tabla de compatibilidad entre versiones de WordPress y PHP está en el artículo actualizar WordPress con seguridad. Si un tema o plugin antiguo impide pasar a un PHP más reciente, el plan de migración está en la guía para modernizar bases de código WordPress heredadas. Si una tienda WooCommerce dejó de aceptar pedidos o muestra errores críticos tras cambiar la versión de PHP, te ayudará el sprint de rescate de WooCommerce. La revisión de la configuración del servidor, de la versión de PHP y de las cuentas tras un incidente forma parte de la auditoría de seguridad de WordPress.

Actualización del 27 de octubre de 2026. Al pasar a una rama más reciente de PHP hay un fallo con un aspecto especialmente raro: en lugar de la página, el navegador descarga un archivo, normalmente index.php. El servidor ha dejado de entregar los archivos .php al intérprete y los envía como archivos normales. En Apache la causa suele ser una línea AddHandler en el .htaccess que asocia .php al handler de una versión de PHP que el hosting ha eliminado (Apache, mod_mime). Un comando confirma el diagnóstico: curl -sI https://example.com/ devuelve Content-Type: application/octet-stream en lugar de text/html. La solución es elegir una versión con soporte en el panel del hosting y borrar la línea AddHandler antigua, no restaurar una copia de seguridad. Lo que casi ninguna guía menciona: mientras PHP no se ejecuta, cualquier archivo .php se puede descargar como código fuente, también el wp-config.php con la contraseña de la base de datos y las claves. Si el fallo duró más de un momento, revisa después en el registro de accesos si alguien pidió ese archivo (grep "wp-config.php" access.log). Si encuentras peticiones, o no tienes registro, cambia la contraseña del usuario de la base de datos y genera claves y salts nuevos (generador de WordPress.org). Los salts nuevos cierran la sesión de todos los usuarios, que es justo lo que quieres aquí. Hago el cambio de versión de PHP con esta comprobación dentro del mantenimiento WordPress.

#Lista de comprobación para propietarios de sitios WordPress y tiendas WooCommerce

Situación a 22 de octubre de 2026, hacia las 08:00 UTC, según el aviso de php.net, las entradas de GitHub Security Advisories, las publicaciones de Calif y Wiz Research y los avisos de Ubuntu, Debian, WordPress.org, NCSC, CERT Polska, Automattic, Patchstack y Huntress. El aviso informativo de php.net del 23 de octubre (CVE-2026-115560) se añadió el 24 de octubre de 2026.