Tu WordPress está al día.
Tu PHP no.
PHP2Shell es una ejecución remota de código sin autenticación en el intérprete de PHP, no en WordPress. El auto-update no la tapa, los plugins de seguridad tampoco y el panel de tu sitio va a seguir diciendo que está todo bien. Verifico tu versión real, coordino el parche y reviso si el sitio estuvo expuesto.
Si ya viste señales de compromiso, eso es otra cosa: recuperación de emergencia.
Por qué tu panel te está mintiendo
"Todo está actualizado" es una frase sobre WordPress. PHP2Shell vive una capa más abajo, en el binario que ejecuta WordPress. Estas son las seis situaciones en las que alguien cree estar cubierto y no lo está.
Tu WordPress dice "todo al día"
Y aun así estás expuesto. El auto-update de WordPress no puede parchear una falla del intérprete de PHP: no es su código.
Tu hosting no te avisó nada
Muchos proveedores aplicaron el parche en silencio; otros todavía no. Sin verificación no hay forma de saber de qué lado estás.
No sabés qué versión de PHP corre de verdad
El `php -v` de la terminal puede ser distinto al PHP que sirve el sitio. En hosting compartido, casi siempre lo es.
Estás en PHP 8.1 o anterior
No hay parche upstream. PHP publicó backports mínimos de código, pero si no compilás desde fuente la única salida es migrar de rama.
El sitio estuvo online del 21 al parche
Con exploits circulando desde antes de la divulgación. Que no veas nada raro no significa que no haya pasado nada.
Desactivar plugins no te protege
Ningún plugin, tema ni WAF de plugin frena el escenario mod_php. El ataque ocurre antes de que WordPress arranque.
Las tres vulnerabilidades, en una tabla
Dos son críticas y tienen parche desde el 21 de octubre de 2026. La tercera apareció el 23 y no va a tener release de emergencia.
| CVE | CVSS | Qué falla | Corrección |
|---|---|---|---|
| CVE-2026-109618 | 9.2 | RCE por corrupción de memoria al manejar el límite de memoria (OOM). | PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 |
| CVE-2026-109619 | 9.2 | RCE por estado global que sobrevive al request en el mismo worker. | PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 |
| CVE-2026-115560 | — | RCE en configuraciones poco comunes de session.serialize_handler. Sin release de emergencia. | session.upload_progress.enabled=0 |
Detalle técnico completo en el artículo: PHP2Shell: WordPress no puede parchear esto.
Qué hago, paso a paso
Ocho pasos concretos, en este orden, sobre tu instalación real. No es un escaneo automático: es alguien mirando el servidor.
01
Verificación real de la versión
La que sirve el sitio, no la del CLI. Reviso Salud del sitio, el pool de FPM, el panel del hosting y también el PHP embebido en paneles, phpMyAdmin y cron.
02
Comparación contra las versiones corregidas
8.5.12, 8.4.27, 8.3.36 y 8.2.35. Con distros hay que mirar la fecha de build del paquete: Debian, Ubuntu y RHEL backportean el fix sin cambiar el número.
03
Coordinación con tu hosting
Si es gestionado, redacto el ticket con la versión exacta, la fecha de build esperada y la referencia al advisory para que no te respondan con un copy-paste.
04
Actualización y verificación del parche
Si es VPS propio, actualizo yo. Después confirmo que lo que sirve el sitio es el binario parcheado y no un contenedor que quedó con la imagen vieja.
05
Mitigaciones mientras se actualiza
memory_limit=-1 por php_admin_value, post_max_size acotado, session.upload_progress.enabled=0, fatal_error_backtraces=0 en 8.5 y límites en el proxy. Verificadas en vivo con ini_get, no solo escritas en el archivo.
06
Reinicio real de todos los workers
Apache, PHP-FPM, contenedores sin rebuild, OPcache y cualquier proceso PHP de larga duración. Sin esto, el parche queda en disco y no en memoria.
07
Revisión de compromiso del período expuesto
Archivos PHP nuevos fuera de wp-content, usuarios admin, cron jobs, .htaccess y webshells. Más los logs de Apache/FPM buscando multipart anómalos seguidos de errores de memory limit.
08
Rotación de credenciales
Salts de wp-config.php, contraseña de la base, claves de API, tokens de integraciones y contraseñas de administradores. Por si el ataque entró y no dejó rastro visible.
Qué NO es este servicio
El alcance acotado es lo que hace que esto se pueda resolver rápido y bien.
-
No es un pentest. No hago pruebas de intrusión ofensivas contra tu servidor.
-
No es un plan de mantenimiento recurrente. Si querés que alguien vigile esto todos los meses, eso es otro servicio.
-
No incluye desarrollo, diseño, migración de hosting ni recuperación de un sitio ya caído. Si aparece un compromiso confirmado, se cotiza aparte.
-
No garantizo que tu proveedor de hosting responda rápido. Lo que garantizo es que el pedido salga correcto y quede documentado.
Contame en qué versión está tu PHP
Con eso te digo si estás expuesto y qué hace falta. Si no sabés dónde verlo, te paso los tres pasos para mirarlo en tu panel. Sin formularios largos, sin cotizador automático.
Hablar por WhatsAppSi preferís dejarlo por escrito, está el formulario de contacto.
Preguntas frecuentes
¿Actualizar WordPress me protege de PHP2Shell?
No. PHP2Shell son dos vulnerabilidades del intérprete de PHP (CVE-2026-109618 y CVE-2026-109619), no de WordPress. El auto-update de WordPress no puede aplicar ese parche porque no es su código. Hay que actualizar PHP en el servidor.
¿Cómo sé si mi PHP ya está parcheado?
En WordPress: Herramientas → Salud del sitio → Información → Servidor. Si estás en 8.5.12, 8.4.27, 8.3.36 o 8.2.35, está parcheado. Si el número es menor pero el hosting es Debian, Ubuntu o RHEL, puede tener el fix por backport: se confirma con la fecha de build del paquete, no con el número de versión.
¿Sirve tener Wordfence o un WAF de plugin?
No en el escenario mod_php, que es el de mayor riesgo. Los plugins corren después de que PHP arrancó el request, y el ataque ocurre antes de que corra una línea de código de la aplicación. Un WAF perimetral (Cloudflare, AWS WAF) sí inspecciona antes y ayuda como mitigación temporal, pero no reemplaza el parche.
¿Qué pasa si mi hosting no actualiza PHP?
Se abre ticket con la versión exacta y la fecha de build esperada, y se aplican las mitigaciones temporales mientras tanto: memory_limit=-1 por php_admin_value, post_max_size bajo, session.upload_progress.enabled=0 y reinicio de workers. Si el proveedor no responde, migrar de hosting pasa a ser parte de la solución.
¿El sitio puede haber sido comprometido sin que me entere?
Sí. El ataque entra por debajo de la aplicación, así que el log de WordPress y los plugins de seguridad no muestran nada. El sitio sigue funcionando normal. Por eso la revisión de archivos, usuarios, cron y logs del servidor es parte del trabajo, junto con la rotación de credenciales.
¿Cuánto tarda?
La verificación y la aplicación de mitigaciones se hacen en una sesión de trabajo. Si hay que coordinar con el hosting, el plazo depende de su respuesta. La revisión de compromiso y la rotación de credenciales se suman en la misma jornada cuando hay acceso al servidor.
¿Trabajás con clientes fuera de Argentina?
Sí. Trabajo en remoto con clientes en España, LATAM y resto de la UE. Todo se coordina por WhatsApp y el acceso es con tus credenciales o las de quien administre el servidor.
¿Qué necesitás de mí para empezar?
Acceso al panel de WordPress con rol administrador y, si tenés, acceso al panel del hosting o al servidor. Con eso verifico la versión real de PHP y armo el plan. Si no tenés accesos, te digo exactamente qué pedirle a tu proveedor.
¿En qué puedo ayudarte?
Contame qué problema tenés con tu sitio. En menos de 24 horas te respondo con un diagnóstico claro y, si lo necesitás, un presupuesto sin compromiso.
¿Preferís hablar directo?
Escríbenos por WhatsApp