PHP2Shell: qué puedes hacer ahora mismo

Dos vulnerabilidades críticas de PHP, conocidas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619), permiten a un atacante ejecutar código en un servidor web sin necesidad de iniciar sesión. PHP les otorga una calificación de 9.2 sobre 10 y lanzará correcciones el 21 de octubre de 2026 a las 14:00 UTC. Los detalles se filtraron un día antes y ya se han reportado ataques.

Si tu sitio web funciona con PHP, aquí tienes lo que puedes hacer hoy mismo, desde la solución definitiva hasta las soluciones temporales. Para obtener información técnica completa y una cronología actualizada, lee Aviso de Sansec.

1. Actualiza PHP lo antes posible.

Actualizar PHP es la única solución real. Todo lo demás que se menciona en este artículo solo reduce el riesgo hasta entonces.

• Versiones corregidas previstas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Estos números provienen de investigadores de seguridad y rastreadores de distribuciones de Linux; PHP solo los confirma con el lanzamiento.
• Versiones anteriores (8.1, 8.0, 7.x, 5.x) Estos sistemas han llegado al final de su ciclo de vida y no cuentan con una solución oficial. Si utiliza uno de estos sistemas, planifique una actualización ahora y mantenga las soluciones provisionales que se indican a continuación.
• Comprueba que tu paquete realmente contiene la corrección. El número de versión por sí solo puede ser engañoso, porque las distribuciones a menudo incorporan correcciones a versiones anteriores. Busque el número CVE en el registro de cambios, por ejemplo con Registro de cambios de apt php8.3-cli (Debian/Ubuntu) o rpm -q --changelog php (RHEL/Alma/Rocky).
• Reinicia PHP después de actualizar. (Por ejemplo systemctl restart php8.3-fpm), de lo contrario, el código antiguo seguirá ejecutándose.
• En alojamiento compartido, Pregúntale a tu proveedor de alojamiento cuándo implementarán la versión de PHP corregida.

2. Desactivar el progreso de carga de la sesión

Los primeros análisis apuntan a la función de progreso de carga de sesión de PHP, que está activada por defecto y se ejecuta al cargar un archivo. Desactivarla y habilitar el modo de sesión estricta reduce la exposición. Sin embargo, esto no soluciona la vulnerabilidad, y los investigadores de seguridad advierten que podría bloquear solo uno de los dos fallos.

Añade esto a php.ini, .user.ini o la configuración PHP de su proveedor de alojamiento:

session.upload_progress.enabled = Off session.use_strict_mode = 1

Si utiliza PHP-FPM, también puede configurarlo por grupo:

php_admin_flag[session.upload_progress.enabled] = off

Reinicie PHP después. Muy pocos sitios web dependen de barras de progreso de carga basadas en esta función, por lo que este cambio rara vez causa problemas.

3. Bloquear las cargas en el servidor web (nginx)

Las rutas de ataque conocidas utilizan solicitudes multipart, el formato que usan los navegadores para subir archivos. Bloquearlas en el servidor web las detiene antes de que lleguen a PHP. Sansec recomienda esta medida como solución temporal.

Agregue esto dentro de su servidor { } bloque, fuera de cualquier ubicación:

if ($http_content_type ~* "multipart/form-data") { rewrite ^ /__upload_blocked last; } location = /__upload_blocked { internal; default_type text/plain; return 403 "Actualmente no se permite la carga debido a un error importante. Volveremos pronto.\n"; }

Los visitantes que intentan subir archivos ahora reciben un mensaje claro en lugar de una página de error simple. interno La línea significa que nadie puede abrir /__carga_bloqueada directamente, y sus otras páginas de error permanecen iguales.

Prueba y vuelve a cargar:

nginx -t && nginx -s reload curl -i -F "x=1" https://yoursite.example/ curl -i -F "x=1" https://yoursite.example/some/subpage

Ambos rizo Las pruebas deberían devolver 403 con el mensaje. Si una subpágina aún se carga, compruebe que la si se sienta directamente en servidor { } y no dentro de un ubicación, y que usted editó el servidor Bloque que realmente sirve al sitio. Una solicitud de página normal sin carga de archivos debería seguir funcionando.

4. Bloquear las cargas en el servidor web (Apache / .htaccess)

En Apache 2.4, agregue esto a la .htaccess en la raíz de tu documento. Funciona en cualquier parte del archivo, incluso por encima o por debajo de las reglas de tu CMS:

ErrorDocument 403 "Actualmente no se permite la carga debido a un error grave. Volveremos pronto." Require all denied

Apache rechaza la solicitud antes de que se ejecuten las reglas de reescritura, por lo que todas las URL están cubiertas, no solo la página de inicio. Una versión basada en Regla de reescritura [F] Es fácil equivocarse: al estar colocado debajo de las reglas de un CMS, bloquea solo la página de inicio, mientras que las subpáginas aún acceden a PHP.

• Utilice el .htaccess Apache realmente lee para su sitio. Para Magento 2, ese suele ser el que está en pub/.
• Una subcarpeta con su propia .htaccess, como por ejemplo una segunda instalación de WordPress, puede que necesite el mismo bloque.
• Un error 500 después de guardar generalmente significa que su host no permite estas directivas en .htaccess. Pídeles que lo permitan o que añadan la regla en la configuración del servidor.

Prueba la página de inicio y al menos una subpágina. Ambas deberían devolver 403 con el mensaje:

curl -i -F "x=1" https://yoursite.example/ curl -i -F "x=1" https://yoursite.example/some/subpage

Si una subpágina aún devuelve la página misma, el bloqueo no está vigente para esa URL.

Qué esperar y cuándo deshacerlo

El bloqueo del servidor web detiene todas las solicitudes multipart, no solo las cargas de archivos. Es probable que dejen de funcionar hasta que lo elimines.

• Carga de archivos e imágenes, incluso en su área de administración o CMS.
• Algunos formularios comunes, como los de contacto o los de edición de productos, se envían como formularios multipartes.
• Cargas en segundo plano en JavaScript, que pueden mostrar un error genérico en lugar de su mensaje.

La configuración de PHP del paso 2 rara vez causa problemas y puede mantenerse. Elimine el bloqueo del servidor web una vez que PHP se haya actualizado y haya confirmado la solución en el registro de cambios de su paquete. Luego, reinicie nginx o Apache y pruebe a subir archivos.

Lecturas adicionales

• Vulnerabilidades críticas de ejecución remota de código en PHP: CVE-2026-109618 y CVE-2026-109619 (Sansec): aviso, medidas de mitigación y cronograma en tiempo real
• Próxima actualización crítica de seguridad de PHP (Anuncio de PHP)
• Alerta de seguridad importante: PHP vulnerable a RCE crítico (Pila de parches)
• PHP2Shell: ¿qué te protege realmente antes del parche? (The Hacker News)

Última actualización: 21 de octubre de 2026