Seguridad informática

    PHP2Shell: la falla crítica de PHP y qué revisar hoy en tu sitio web

    Publicado
    25 de octubre de 2026

    Empresas que ya trabajan con nosotros

    • COTO
    • Twilio
    • Lutz Ferrando
    • GROM Audio
    • nuph.ai
    • agonProp
    • Las Contas
    • Runa Distribuidora
    • MABA Propiedades
    • Buongiorno Propiedades
    • LumeDron

    En resumen

    • Qué pasó: el 21 de octubre de 2026 el proyecto PHP publicó actualizaciones (8.5.12, 8.4.27, 8.3.36 y 8.2.35) para dos fallas críticas que, según su aviso oficial, pueden permitir ejecutar código en un servidor sin iniciar sesión.
    • Por qué te importa: la falla está en PHP, el motor detrás de WordPress y de muchas tiendas y sistemas a medida. Actualizar WordPress o los plugins no la corrige: la corrige quien administra el servidor, normalmente tu hosting.
    • Versiones viejas: PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto. Si tu sitio corre en una de ellas, hay que hablar con el proveedor o planificar la migración.
    • Qué hacer hoy: averiguar quién actualiza PHP en tu sitio y pedirle confirmación escrita de que el arreglo está instalado.

    Datos verificados al 24 de octubre de 2026.

    Qué pasó

    El 20 de octubre, php.net avisó que el 21 a las 14:00 UTC (11:00 en Argentina) publicaría una actualización para dos vulnerabilidades, ambas con 9,2 sobre 10 en la escala CVSS v4.0. Ese día salieron las versiones corregidas y el aviso que las identifica como CVE-2026-109618 y CVE-2026-109619. Según el aviso, están en riesgo todas las instalaciones de PHP que atienden pedidos web; el riesgo es mayor con Apache y mod_php, donde se demostró un ataque que se dispara antes de que corra el código de la aplicación.

    El conjunto se conoce como PHP2Shell, nombre que usa la empresa de seguridad Wiz, que afirma que PHP impulsa el 70% de los sitios web del mundo: es una cifra propia que su nota no respalda con una fuente. Según The Next Web, que cita al Wall Street Journal, PHP adelantó la publicación cuando se filtraron detalles en Hacker News.

    Hubo reacciones rápidas. Según Infobae, la NSA de Estados Unidos pidió aplicar los parches de inmediato o desconectar los sistemas afectados, la oficina alemana de seguridad informática (BSI) emitió una alerta formal y, según el diario Bild, el hospital Charité de Berlín desconectó su sitio. The Next Web suma que CERT-EU y el NCSC británico recomendaron sacar de línea lo que no pudiera parchearse, y que Pinboard, el foro de GrapheneOS y la herramienta de transmisión OBS retiraron partes de sus sitios. Una caída temporal, aclara Malwarebytes, no significa por sí sola que el sitio haya sido vulnerado.

    Cómo ocurrió, explicado sin tecnicismos

    PHP trabaja detrás de escena, en el servidor: arma la página antes de mostrártela. Según Malwarebytes, sostiene WordPress, Drupal, Joomla y Magento. Una analogía: si tu sitio es un restaurante, WordPress es el libro de recetas y PHP es la cocina. Las fallas están en la cocina, no en las recetas. Por eso, según Wiz, hasta una aplicación mínima de tipo "Hola mundo" sobre una versión afectada puede ser vulnerable, y por eso actualizar un plugin no cambia nada.

    Qué falla, en simple: según Wiz, el problema está en cómo PHP maneja los errores graves mientras atiende un pedido, en particular cuando se queda sin memoria. Puede quedar un resto mal limpiado y otro pedido posterior aprovecharlo. Es como si en plena hora pico se cayera un plato y el siguiente pedido se sirviera con lo que quedó en la mesada.

    Cómo se encontró: según The Next Web, la firma Calif halló la primera falla en agosto con GPT-5.6 Sol, un modelo de OpenAI, en una auditoría que OpenAI financió. La misma nota recoge que Wiz dijo haberlas encontrado de forma independiente; en su informe, Wiz cuenta que usó Wiz Atlas y modelos de Google y de OpenAI, y publica que descubrió la primera el 19 de agosto y la reportó a PHP el 24. El orden exacto de los hallazgos no queda claro en las fuentes. Calif sostiene que conocer la historia de PHP importó más que el modelo.

    Qué se sabe y qué todavía no

    Rama de PHPSituación según php.netQué conviene hacer
    8.5, 8.4 y 8.3Corregidas en 8.5.12, 8.4.27 y 8.3.36Confirmar con tu proveedor
    8.2Corregida en 8.2.35; fin de vida el 31 de diciembre de 2026Confirmar y planificar el salto
    8.1 y anterioresSin actualizaciones del proyecto PHPConsultar al proveedor o migrar

    Según SecurityWeek, Ubuntu publicó arreglos para todas sus versiones con soporte y Debian para bookworm y trixie, y cPanel y Plesk lanzaron compilaciones corregidas incluso para PHP 7.4, 8.0 y 8.1, ramas que el proyecto ya no mantiene. El aviso de PHP indica que algunas distribuciones y proveedores de soporte extendido ofrecen correcciones propias, y que el equipo publicó además retroportes (backports) mínimos de código fuente para esas tres ramas, pensados para quien compila por su cuenta. El proyecto aclara que no hay mitigaciones completas: actualizar es la única opción segura. Un detalle práctico: según Hostinger, en su hosting el arreglo viene dentro de la versión que el sitio ya usaba, así que el número puede no cambiar.

    El 23 de octubre PHP sumó un aviso sobre un tercer problema, CVE-2026-115560, que describe como una vía de ejecución remota poco probable, con una combinación inusual de configuración y código. Según el Centro Canadiense de Ciberseguridad, las actualizaciones del 21 no lo resuelven. Mientras tanto PHP sugiere desactivar la función de progreso de subida de sesiones, algo que tu proveedor sabrá aplicar.

    Lo que todavía no se sabe:

    • Cuántos sitios fueron comprometidos. Ninguna de las fuentes revisadas da una cifra confirmada.
    • Cuánta explotación hubo. Según SecurityWeek, Amazon dice que su primer intento detectado fue el 17 de octubre y watchTowr vio explotación masiva tras los parches, aunque las pruebas de concepto en circulación no lograron ejecutar código. El Centro Canadiense, en su aviso (publicado el 21 y actualizado el 23), dice que no identifica explotación activa.
    • Qué tan grave es en la práctica. PHP y Wiz usan 9,2. Según SecurityWeek, Red Hat puntúa ambas con 8,1 y, sobre CVE-2026-109618, dice que la explotación fiable exige manipulación precisa de la memoria y de los tiempos. PHP pide a todos los usuarios actualizar de inmediato.
    • Cuántos servidores quedan sin arreglo. CriptoNoticias, citando el informe de un investigador, habla de unos 884.000 servidores expuestos en internet que no recibirán el parche oficial: es una estimación de un tercero. Esa nota trae porcentajes por país que no pudieron contrastarse con otra fuente, y por eso no se usan. Tampoco se encontró un aviso de un organismo argentino.

    Qué lecciones deja para una pyme o un profesional de Córdoba

    Si tu sitio o tu sistema están hechos con WordPress u otro software en PHP, este caso te toca aunque tu código esté bien escrito. Siete acciones:

    1. Haz una lista de todo lo tuyo que corre PHP: sitio institucional, tienda, intranet, sistemas a medida y paneles. El Centro Canadiense recomienda incluir productos de terceros y contenedores que lo traigan incorporado.
    2. Averigua quién actualiza PHP en cada caso: el proveedor en un hosting administrado, tu equipo técnico en un VPS o servidor propio. Según Malwarebytes, actualizar WordPress o sus plugins no es lo mismo que actualizar PHP.
    3. Pide confirmación escrita de que el arreglo está instalado, no solo programado, con su fecha. Si el número de versión no cambió, pregunta cómo lo verificaron.
    4. Revisa si corres PHP 8.1 o anterior. No hay actualización oficial: pregunta si tu proveedor ofrece correcciones propias y planifica la migración, probando antes en una copia porque plugins viejos pueden fallar.
    5. Si no se puede actualizar ya, pregunta si corresponde sacar de línea lo expuesto. La NSA, el NCSC y CERT-EU lo recomendaron en ese caso. Para una tienda es una decisión de negocio: tómala con información.
    6. Mira señales raras: contenido que no pusiste, redirecciones, administradores nuevos, archivos desconocidos, y pide revisar los registros. Si encuentras algo, sigue la guía de qué hacer si tu página web fue hackeada.
    7. Desconfía de "herramientas" o "parches" que lleguen por mensaje. Según SecurityWeek, JFrog advirtió que aparecieron pruebas de concepto falsas. Guíate por php.net y por tu proveedor.

    Es una cara de un tema más amplio: el software se apoya en piezas ajenas, como pasó con el gusano de npm en la librería keyv. Si prefieres que alguien revise contigo qué versión de PHP corre tu sitio y cómo está configurado, en el estudio hacemos revisión y refuerzo de seguridad desde Villa General Belgrano: puedes ver cómo trabajamos en el servicio de seguridad informática.

    Preguntas frecuentes

    ¿Alcanza con actualizar WordPress y los plugins?

    No. Según Malwarebytes, no es lo mismo que actualizar PHP, porque las fallas están en el propio PHP. Mantener WordPress al día sigue siendo buena práctica, pero hay que confirmar PHP con quien administra el servidor.

    ¿Cómo sé si mi hosting ya lo arregló?

    Pregúntaselo por escrito y pide que te digan cómo lo verificaron. Según Hostinger, el número de versión puede no cambiar, así que la respuesta del proveedor vale más que mirar el número en tu panel.

    Mi sitio estuvo caído o en mantenimiento, ¿me hackearon?

    No necesariamente: según Malwarebytes, puede ser una decisión de protección mientras se instalan las actualizaciones. Si además ves contenido extraño, redirecciones o usuarios nuevos, conviene revisar a fondo.

    ¿Encontró estas fallas una inteligencia artificial?

    En parte, con matices. Según The Next Web, Calif usó GPT-5.6 Sol, y Wiz dice haber usado Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol. Calif sostiene que conocer la historia de PHP importó más que el modelo. Para tu sitio, lo práctico no cambia: actualizar.

    Fuentes

    • PHP.net, "Security advisory: Critical remote code execution vulnerabilities, update now", 21/10/2026 (y avisos del 20 y 23/10). php.net
    • Wiz Research, "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet", 21/10/2026. wiz.io
    • The Next Web, "PHP rushes out emergency patches for two critical bugs AI found first", 21/10/2026. thenextweb.com
    • Infobae, "Empresas y hospitales apagan sus páginas web tras detectar un fallo de seguridad crítico", 21/10/2026. infobae.com
    • Centro Canadiense de Ciberseguridad, "AL26-026 - Critical vulnerabilities impacting PHP - CVE-2026-109618 and CVE-2026-109619", 21/10/2026 (actualizado el 23/10). cyber.gc.ca
    • SecurityWeek, "Tech and Security Companies Respond to PHP2Shell Vulnerabilities", 22/10/2026. securityweek.com
    • Malwarebytes, "PHP2Shell: Why many websites had to go offline", 21/10/2026. malwarebytes.com
    • Hostinger, "Hostinger deploys protections against php2shell PHP vulnerabilities", 21/10/2026 (actualizado el 23/10). hostinger.com
    • CriptoNoticias, "Más de 880.000 servidores expuestos a ataques por vulnerabilidad en PHP", 21/10/2026. criptonoticias.com

    ¿Tienes un proyecto? Hablemos.

    ¿Listo para dejar de pagar por herramientas que no necesitas?

    Agenda una consulta gratuita con nuestro equipo, estés en la provincia que estés. Un equipo senior respalda cada proyecto que tomamos.

    Solo 3 cupos disponibles este mes