Situación actual: PHP2Shell. Dos vulnerabilidades críticas de PHP (CVSS 9.2) permiten ejecutar código malicioso sin autenticación. Parches desde el 21/10/2026.Qué hacer ahora →
PHP2Shell · CVE-2026-109618 · CVE-2026-109619

PHP sin parchear es una puerta abierta. Nosotros la cerramos.

Ayuda de emergencia en remoto para empresas en Europa: parchear PHP, revisar indicios de intrusión, eliminar código malicioso y reforzar el servidor. De inmediato, con socios especializados, hasta que el incidente quede cerrado y documentado.

CVSS 9.2dos vulnerabilidades, código malicioso sin inicio de sesión
8.2.35 · 8.3.36 · 8.4.27 · 8.5.12primeras versiones parcheadas
22,6 Minstancias expuestas según Unit 42
revisión · producción
$ php -v
PHP 8.3.35 (cli) (built: Sep 30 2026)
! Estado antes del parche del 21/10/2026
$ phpsos pruefen --ziel produktion
  Modo de ejecución .. php-fpm
  CVE-2026-109618 .. abierto
  CVE-2026-109619 .. abierto
  Reinicio de workers .. pendiente
$ phpsos absichern
  [ok] Paquete 8.3.36 instalado
  [ok] todos los workers reiniciados
  [ok] Sistema de archivos revisado en busca de webshells
  [ok] Informe para la dirección elaborado
  • Made in GermanySeguridad informática desde Alemania, con trabajo conforme a la normativa europea de protección de datos.
  • Más de 25 añosEspecializados desde hace más de 25 años en seguridad informática y operación de servidores, junto con nuestra red de socios.
  • Red de sociosProfesionales de ciberseguridad especializados en análisis forense, pruebas de penetración y refuerzo de servidores, coordinados a través de un único interlocutor.
Autotest · 10 segundos

¿Su PHP ya está parcheado?

Introduzca su versión de PHP. La prueba la compara con los avisos de seguridad de php.net e indica qué hacer a continuación. Importante: ni siquiera una versión parcheada demuestra que no haya ocurrido nada antes de la actualización.

Cómo encontrar su versión de PHP →

Se ejecuta solo en su navegador, no se envía nada. Base: avisos de seguridad de php.net del 21 y del 23/10/2026. Los backports de las distribuciones a veces no cambian el número.

Prueba rápida independiente del número de versión

Según el manual de PHP, con los parches llegó el ajuste memory_hard_limit_percent. Si su PHP no lo conoce, está afectado:

php -r 'var_dump(ini_get("memory_hard_limit_percent"));'

bool(false) significa: desconocido, es decir, afectado. Compruebe cada versión de PHP instalada por separado; la línea de comandos puede usar una versión distinta de la del servidor web.

Chequeo de emergencia · 4 preguntas

¿Cómo de urgente es su situación?

Cuatro preguntas, una clasificación, los primeros pasos y un mensaje de WhatsApp preparado para nosotros. En el nivel 3: no borrar nada, no reinstalar nada, conservar los rastros.

1. ¿Qué observa?
2. ¿Cómo se ejecuta su PHP?
3. ¿Está PHP parcheado?
4. ¿Qué datos hay almacenados?
Servicios

De la llamada de emergencia al servidor reforzado

Nos encargamos de la parte técnica y entregamos las pruebas que necesitan la dirección, la protección de datos y el seguro.

Proceso

Así trabajamos en caso de emergencia

Pasos claros, un único interlocutor, todo en remoto. Cuando hacen falta análisis forense o pentest, se suman especialistas de nuestra red de socios.

  1. Evaluar la situación

    Usted nos escribe por WhatsApp o nos llama. Aclaramos el sistema, la versión de PHP, el proveedor de hosting y lo observado.

  2. Asegurar y cerrar

    Conservar los rastros, parchear PHP o aplicar medidas provisionales, reiniciar todos los workers y documentar el estado del parche.

  3. Revisar y limpiar

    Revisar archivos, base de datos, cuentas y registros en busca de indicios de intrusión. Eliminar webshells y puertas traseras.

  4. Reforzar e informar

    Reforzar la configuración, configurar la monitorización y elaborar el informe para la dirección, la protección de datos y el seguro.

Actúe usted mismo

¿Aún no es posible parchear? Medidas provisionales

php.net indica ajustes que dificultan las vías de ataque conocidas hasta que se instale la actualización. Elija su modo de ejecución, copie las líneas y reinicie después todos los procesos de PHP.

El BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda: si la actualización no es posible de inmediato, desconectar temporalmente el servidor web de la red.

Todas las medidas provisionales explicadas →

Medidas provisionales según php.net, no sustituyen a la actualización. memory_limit=-1 solo junto con un límite de memoria mediante contenedor o cgroup. Haga antes una copia de seguridad de la configuración.

Responsabilidades

¿Quién hace qué? El hueco entre proveedor de hosting y agencia

Muchas empresas dan por hecho que «alguien» aplica los parches. Por lo general, el reparto es el siguiente:

TareaProveedor de hosting (hosting compartido)Agencia / diseño webPHP SOS
Actualizar el paquete de PHPnormalmente sínormalmente nosí, o junto con su proveedor de hosting
Reiniciar todos los workers y demostrarloen partenosí, con justificante
Comprobar si hubo una intrusión antes del parchepor lo general noen partesí
Eliminar webshells y puertas traseraspor lo general noen partesí
Informe para la dirección, la protección de datos y el seguronoraramentesí
Refuerzo y monitorización continuaen parteen partesí
Conocimiento sobre PHP2Shell

Qué está demostrado y qué hacer ahora

Hechos extraídos de los avisos de php.net y del BSI, preparados para la dirección y los administradores.

¿Qué es PHP2Shell? La vulnerabilidad explicada

PHP2Shell son dos vulnerabilidades críticas en el propio PHP que permiten a los atacantes ejecutar código en servidores web sin autenticarse. La situación, en palabras claras.

Seguir leyendo →

CVE-2026-109618: RCE por un estado de falta de memoria

CVE-2026-109618 es una de las dos vulnerabilidades de PHP2Shell: un estado de falta de memoria puede interrumpir PHP en pleno procesamiento de la petición. Corregida desde PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

Seguir leyendo →

CVE-2026-109619: RCE por un estado global obsoleto

CVE-2026-109619 es la segunda vulnerabilidad de PHP2Shell: el estado interno de una petición puede persistir tras liberar la memoria y ser aprovechado por la siguiente petición en el mismo worker.

Seguir leyendo →

CVE-2026-115560: aviso sobre Session-Upload-Progress

CVE-2026-115560 es un aviso de php.net del 23/10/2026: posible ejecución de código solo con una configuración de sesión poco habitual. Solución hasta la próxima versión: session.upload_progress.enabled=0.

Seguir leyendo →

¿Qué versiones de PHP están afectadas?

PHP2Shell está corregida en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales. La tabla muestra el estado de cada rama.

Seguir leyendo →

Comprobar correctamente la versión de PHP y el estado del parche

La versión de PHP que se muestra no dice por sí sola si PHP2Shell está cerrada. Lo decisivo son el estado del paquete, los backports y si los procesos nuevos se están ejecutando realmente.

Seguir leyendo →

Las 12 páginas de conocimiento

La primera hora

10 pasos antes de que nos hagamos cargo

Marque lo que ya esté hecho. La lista se guarda en su navegador.

Obtener ayuda directamente

Las marcas solo se guardan en su navegador.

Blog · 113 artículos

Situación, tutoriales, ayudas para decidir

Desde el nivel de alerta del BSI y los changelogs de paquetes hasta la pregunta de si reinstalar o limpiar. Cada artículo con fuentes.

PHP2Shell: qué está comprobado y qué no

Una verificación de hechos sobre PHP2Shell: qué afirmaciones proceden de fuentes primarias, cuáles de informes de prensa y qué afirmaciones no se sostienen.

Seguir leyendo →

Cambiar la versión de PHP en el área de cliente del alojamiento

Cómo cambiar la versión de PHP en el área de cliente de su proveedor de alojamiento, qué versión elegir y qué comprobar antes y después.

Seguir leyendo →

Señal de alerta: el servidor web inicia una shell

Si un proceso de PHP-FPM o del servidor web inicia una shell, es una de las señales de alerta más fuertes de una intrusión. Cómo revisar el árbol de procesos, valorar las excepciones y vigilar el patrón de forma permanente.

Seguir leyendo →

Aislar los pools de PHP-FPM por sitio web

Un pool propio por sitio web es el comienzo, no el final. Cómo revisar los pools existentes y reforzar sockets, extensiones, páginas de estado, recursos y logs.

Seguir leyendo →

Guardar contraseñas en PHP con seguridad: usar bien password_hash

Cómo guardan los desarrolladores las contraseñas en PHP con password_hash y password_verify, cómo elegir el algoritmo adecuado y cómo sustituir hashes MD5 o SHA-1 antiguos sin restablecer la contraseña de todos los usuarios.

Seguir leyendo →

Contratos con proveedores de TI: regular con claridad las obligaciones de seguridad

PHP2Shell ha mostrado con qué frecuencia no está claro quién debe parchear. Qué obligaciones de seguridad deben incluirse en los contratos con agencias, proveedores de hosting y proveedores de TI.

Seguir leyendo →

Los 113 artículos del blog

Preguntas frecuentes

Respuestas breves

Todas las preguntas →

¿Qué es PHP2Shell?

PHP2Shell designa dos vulnerabilidades críticas en el propio PHP (CVE-2026-109618 y CVE-2026-109619, CVSS 9.2). Pueden permitir a los atacantes ejecutar código malicioso en el servidor sin autenticación. Hay parches desde el 21/10/2026.

¿Qué versiones de PHP son seguras?

Las correcciones están incluidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Algunos proveedores de hosting y distribuciones incorporan backports sin cambiar el número de versión. Lo decisivo es el estado del paquete o la confirmación por escrito del proveedor.

¿Basta con actualizar WordPress o la tienda online?

No. La vulnerabilidad está en PHP, no en el CMS. Una actualización del CMS no la cierra. Y un parche de PHP no elimina el código malicioso que se haya introducido antes.

¿Con qué rapidez pueden ayudarnos?

Trabajamos en remoto y empezamos en cuanto disponemos de los accesos. Escríbanos por WhatsApp indicando el sistema, la versión de PHP y lo que ha observado. Así acordamos directamente cómo proceder.

¿Trabajan también para agencias y clientes de proveedores de hosting?

Sí. Trabajamos directamente para empresas, en segundo plano por encargo de agencias y en coordinación con su proveedor de hosting cuando es este quien gestiona el servidor.

¿Tenemos que notificar el incidente?

Si pueden verse afectados datos personales, el art. 33 del RGPD establece, por regla general, un plazo de notificación de 72 horas desde que se tiene conocimiento. Si es aplicable, debe aclararlo con su delegado de protección de datos. Nosotros aportamos la documentación técnica.

Contacto inmediato

Cada hora cuenta. Escríbanos ahora.

Describa brevemente el sistema, la versión de PHP y lo que ha observado. Nos pondremos en contacto, aclararemos la situación y trabajaremos en remoto hasta que el incidente quede cerrado y documentado.

Ayuda inmediata