Tu servidor usa PHP. PHP2Shell puede ejecutar código en él — sin iniciar sesión.
Dos fallas críticas en el propio PHP permiten a un atacante ejecutar código en el servidor que hay detrás de sitios con WordPress, Drupal, Laravel, Magento y otras aplicaciones PHP. El parche ya salió y los intentos de ataque ya se cuentan por millones. Lo que importa ahora: si todos tus sitios ya lo tienen, si alguno sigue en una versión de PHP que nunca recibirá corrección, y quién vigila los que no.
Una falla en el motor, no en tu plantilla
El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones de seguridad para dos vulnerabilidades críticas apodadas PHP2Shell. Están dentro del manejo de solicitudes del propio PHP, así que un sitio puede quedar expuesto aunque su código esté limpio. Según el equipo de seguridad de PHP, una sola solicitud sin autenticación puede disparar el ataque antes de que se ejecute el código de la aplicación.
Los detalles se filtraron antes de la publicación coordinada, circulan pruebas de concepto y las firmas de seguridad están registrando intentos de explotación a gran escala. Si usas PHP, esto es para parchear ya, no para esperar a ver qué pasa.
RCE por corrupción al quedarse sin memoria
El manejo de falta de memoria puede interrumpir a PHP cuando los datos internos de la solicitud solo están inicializados en parte; la limpieza de la solicitud puede tratar luego esos datos inválidos como válidos.
● CVSS v4.0 · 9.2 CríticaRCE por estado global obsoleto
Un estado interno de la solicitud puede sobrevivir después de que se libera su memoria, y una solicitud posterior en el mismo proceso puede usarlo antes de que la inicialización normal lo reinicie.
● CVSS v4.0 · 9.2 CríticaQué ha cambiado desde el parche
Cinco días después, los ataques son reales, pero el daño confirmado, por ahora, no. Esto es lo que se ha reportado, limitado a lo que dicen las fuentes.
| Fecha | Qué pasó |
|---|---|
| 17 oct | Los honeypots de Amazon registraron un intento de explotación, cuatro días antes de la divulgación pública. |
| 21 oct | PHP publicó las correcciones. Cloudflare vio cómo los intentos pasaron de decenas de miles en 45 minutos a millones en la madrugada del 22 de octubre. |
| 21–23 oct | Sophos y Arctic Wolf reportaron intentos de instalar una variante de la botnet Mirai en servidores vulnerables. |
| 23 oct | El proyecto PHP divulgó una falla distinta, CVE-2026-115560. Requiere una configuración de sesiones poco común, las versiones del 21 de octubre no la corrigen y la solución llegará en la próxima versión regular de PHP. |
| Estado | Al 23 de octubre, ningún compromiso exitoso confirmado públicamente. Sophos: "There is no evidence of a successful compromise due to these vulnerabilities" (no hay evidencia de un compromiso exitoso por estas vulnerabilidades). |
- "Sin intrusiones confirmadas" no es lo mismo que "a salvo". Millones de intentos significan que están probando cada servidor PHP sin parche. El momento para parchear con calma es este.
- Actualizar PHP no es el último paso. Mantén session.upload_progress.enabled = 0 después de actualizar: es la medida provisional de PHP para CVE-2026-115560 hasta la próxima versión.
- Parchear cierra la puerta, pero no revisa lo que hay adentro. Si un sitio estuvo sin parche después del 17 de octubre, buscar archivos PHP inesperados y cuentas de administrador nuevas es un seguro barato.
Por qué "mi código está bien" no es suficiente
- Está en el núcleo de PHP. Las fallas están en el manejo de solicitudes de PHP, no en tu plantilla ni en tus plugins. Una aplicación perfectamente escrita puede quedar expuesta.
- No requiere iniciar sesión. Las configuraciones con PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed están todas en riesgo; el equipo de PHP considera mod_php la de mayor riesgo.
- Lo peor es PHP sin soporte. PHP 8.1 y anteriores no reciben versión oficial corregida: solo parches mínimos de código fuente o compilaciones de proveedores. El soporte de seguridad de PHP 8.2 termina el 31 de diciembre de 2026.
Si en tu servidor corre cualquiera de estos, estás en riesgo:
Lo honesto: puedes parchearlo tú mismo
Preferimos decirlo claro. La solución completa es actualizar PHP en tu servidor. Identifica tu rama y pasa a la versión corregida:
| Rama de PHP | Afectadas | Actualizar a |
|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 |
| 8.4 | < 8.4.27 | 8.4.27 |
| 8.3 | < 8.3.36 | 8.3.36 |
| 8.2 | < 8.2.35 | 8.2.35 |
| 8.1 y anteriores | Sin soporte | Cambiar de rama / parche del proveedor |
El proyecto PHP indica medidas provisionales que reducen la exposición. La más sencilla, para la falla de estado obsoleto, va en php.ini o en el pool de PHP-FPM, y luego hay que reiniciar todos los procesos de PHP:
session.upload_progress.enabled = 0Esto no es una solución completa: no cubre CVE-2026-109618, y configurarlo con ini_set() o con un archivo .user.ini no basta. La lista completa de mitigaciones está en el anuncio del proyecto PHP (en inglés). Actualizar PHP es la única corrección completa para PHP2Shell, pero mantén esta configuración desactivada también después: PHP la recomienda para el CVE-2026-115560, que es distinto, hasta su próxima versión regular. Si tu hosting es administrado, consulta con tu proveedor: muchos ya instalaron versiones corregidas.
¿Entonces para qué contratar a alguien? Porque saber cuál es la solución y aplicarla bien en sitios en producción — a tiempo, sin romper la tienda en línea, en hostings que quizá no controlas del todo, incluidos los que están sin soporte — es el trabajo de verdad. Ahí es donde entramos nosotros.
Defensivos, no alarmistas
No vendemos pánico. Mantenemos tus sitios PHP parcheados, respaldados y vigilados, para que la próxima alerta de "parchea ya" no te quite el sueño.
Parcheo de emergencia
Actualizamos PHP en tus sitios a las versiones corregidas, verificamos que nada se rompa, confirmamos que la exposición quedó cerrada y buscamos si algo quedó instalado antes del parche.
Respaldo y reversión
Un punto de restauración limpio antes de cada cambio, para que una mala actualización se revierta en cinco minutos y no te cueste el fin de semana.
Monitoreo proactivo
Seguimos las nuevas vulnerabilidades de tu stack y aplicamos parches de forma programada: te enteras por nosotros antes que por las noticias.
Hardening y plan de migración
Configuración segura por defecto, protección de cargas y sesiones, y un plan para salir de cualquier versión de PHP sin soporte que sigas usando.
Elige dónde nos necesitas
Precios de referencia en euros, IVA no incluido: el precio final depende de cuántos sitios tienes y en qué hosting. Primero va la revisión gratis.
Ver precios para: España y Europa (€) · Colombia (COP) · Latinoamérica (US$)
Emergency Patch
- Parche de PHP2Shell aplicado y verificado
- Respaldo antes del cambio
- Reporte de exposición después del parche
- Entrega en 48 horas
Managed Protection
- Todo lo de Emergency Patch
- Monitoreo continuo de vulnerabilidades
- Parches y actualizaciones programados
- Respaldos diarios + reversión en un clic
- Configuración de seguridad base
Fleet
- Precio por volumen para todos los sitios
- Panel central de parches
- Respuesta prioritaria a incidentes
- Migración de PHP sin soporte
- Un contacto asignado
Descubre si estás expuesto — en lenguaje claro
Dinos cuál es tu sitio. Revisamos lo que muestra públicamente — servidor y versión de PHP cuando están visibles, versiones del CMS y de los plugins — y te enviamos un reporte corto: qué encontramos, qué significa y qué hacer exactamente. Sin compromiso.
Listo — tu revisión está en cola.
Revisaremos tu sitio y te enviaremos el reporte al correo que nos diste, normalmente en un día hábil. Si es urgente, responde a nuestro correo y dínoslo.
No pudimos enviar tu solicitud.
Revisa los campos e inténtalo de nuevo, o escríbenos la dirección de tu sitio a hola@wordprex.com.