En resumen: filtrar las peticiones de subida en el borde significa rechazar en el proxy, el servidor web o el WAF las peticiones POST de tipo multipart/form-data que no vayan a una ruta de subida conocida. Autores especializados lo proponen como medida provisional y no oficial contra PHP2Shell. Puede romper formularios y subidas y nunca sustituye a la actualización. Proceda en tres pasos: registrar, fijar excepciones y solo entonces bloquear, con una fecha de finalización fija.
Una propuesta del debate especializado
Hasta que un servidor está parcheado, los responsables buscan todo lo que reduzca el riesgo. En el debate especializado sobre PHP2Shell surgió una propuesta: permitir las peticiones POST en formato multipart/form-data, es decir, el formato de las subidas de archivos y de algunos formularios, solo allí donde la aplicación realmente las espera. Todas las demás se rechazan en el proxy o en el Web Application Firewall.
Es importante situarlo bien. La propuesta no procede de php.net, sino de autores especializados, y está pensada expresamente como medida provisional. php.net indica sus propias medidas transitorias, reunidas en Medidas inmediatas si todavía no puede parchear. El filtro puede complementarlas, no sustituirlas.
Aquí describimos cómo introducirlo de forma controlada. Los detalles de por qué podría ayudar contra qué ataques los omitimos deliberadamente.
Qué logra el filtro y dónde perjudica
La idea que hay detrás es reducir la superficie de ataque. La mayoría de las páginas de un sitio web no necesitan subidas de archivos. Si solo unas pocas rutas conocidas aceptan esas peticiones, una gran parte de los posibles intentos de ataque ya no llega a PHP.
El reverso es igual de claro. Toda función que envíe peticiones multipart y falte en la lista de excepciones deja de funcionar. Y eso no afecta solo a los formularios de subida evidentes.
| Función | Suele usar multipart/form-data | Riesgo al bloquear |
|---|---|---|
| Formularios de contacto y de candidatura con adjunto | sí | se pierden solicitudes |
| Gestión de medios en el backend del CMS | sí | la redacción no puede subir imágenes |
| Importación de productos o clientes | sí | las interfaces fallan en silencio |
| Formularios sin adjunto | a veces | según el constructor de formularios |
| Interfaces y retornos de servicios externos | rara vez, pero posible | el fallo se nota tarde |
A ello se suma un problema de fondo: Cloudflare, que ha desplegado por sí misma reglas de protección contra PHP2Shell, advierte de que las reglas basadas solo en los datos de la petición no bastan. Cómo conciliar ambos niveles lo describe WAF o actualización: por qué necesita ambos.
Paso 1: primero registrar, después bloquear
Antes de bloquear nada, averigüe qué rutas reciben realmente peticiones multipart. Los logs estándar no muestran el tipo de contenido. Por eso, para Nginx, cree temporalmente un registro propio:
# en el bloque http
map $uri $upload_pfad {
default 0;
~^/kontakt/upload\.php$ 1;
~^/admin/medien/ 1;
}
map "$request_method:$upload_pfad:$content_type" $multipart_fremd {
default 0;
"~*^POST:0:multipart/form-data" 1;
}
log_format multipart '$time_iso8601 $remote_addr "$request" "$content_type" $status';
# en el bloque server
# Atención: un access_log en el bloque server sustituye al registro heredado,
# por eso hay que indicar aquí de nuevo el log normal.
access_log /var/log/nginx/access.log combined;
access_log /var/log/nginx/multipart-test.log multipart if=$multipart_fremd;
Las entradas de $upload_pfad son ejemplos. Empiece con una lista de excepciones vacía; entonces el registro de prueba muestra todos los POST multipart. En Apache se logra lo mismo con una variable de entorno:
# en el VirtualHost
SetEnvIfNoCase Content-Type "^multipart/form-data" ist_multipart
CustomLog ${APACHE_LOG_DIR}/multipart-test.log combined env=ist_multipart
Deje funcionar el registro varios días, idealmente durante un periodo en el que también hayan estado activos la redacción, los candidatos y las interfaces.
Paso 2: fijar excepciones y bloquear de forma controlada
A partir del registro de prueba, deduzca las rutas que necesitan legítimamente subidas. Coteje la lista con los responsables: ¿quién gestiona los contenidos, qué formularios hay, qué servicios envían datos?
- Elaborar la lista de excepciones a partir del registro y de consultas, e introducirla en
$upload_pfado en las líneasRewriteCond. - Activar el filtro primero en un entorno de pruebas o en una ventana de tiempo tranquila.
- Recorrer usted mismo todos los formularios, subidas y vías de pedido.
- Vigilar el registro de errores en busca de peticiones rechazadas (estado 403) y completar la lista si es necesario.
- Fijar una fecha de finalización: tras la actualización de PHP y el reinicio de todos los workers, el filtro se retira.
En Nginx, para ello añada el bloqueo en el bloque server:
# en el bloque server, tras evaluar la fase de registro
if ($multipart_fremd) {
return 403;
}
En Apache, mod_rewrite asume la tarea. Según la documentación de Apache, varias condiciones se enlazan con Y:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} =POST
RewriteCond %{HTTP:Content-Type} ^multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/kontakt/upload\.php$
RewriteCond %{REQUEST_URI} !^/admin/medien/
RewriteRule ^ - [F]
Si utiliza un CDN o un WAF en la nube, la misma lógica suele poder reproducirse como regla propia. También allí vale lo mismo: primero en modo de registro, después bloquear.
El filtro no sustituye a la actualización de PHP ni es motivo para aplazarla. PHP2Shell solo queda corregido con PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 o un backport confirmado, seguido del reinicio de todos los procesos de PHP.
Situar bien la medida
El filtro de subidas pertenece a una serie de propuestas que circulan actualmente. Algunas son útiles, otras perjudiciales. Un resumen de qué consejos rechazan los autores especializados, por ejemplo bloquear todas las peticiones con cookie de sesión, lo ofrece Falsos consejos peligrosos sobre PHP2Shell.
Cómo procesa PHP internamente las subidas y por qué el formato multipart/form-data desempeña ahí un papel especial lo explica Cómo procesa PHP las subidas de archivos. Para la mayoría de las empresas, sin embargo, el paso más importante no es el filtro, sino una fecha clara para la actualización.
Conclusión: una herramienta para días, no para meses
El filtro de subidas en el borde es un ejemplo típico de medida de emergencia: puede reducir la superficie de ataque en el periodo transitorio, pero tiene efectos secundarios y no cuenta con el respaldo oficial de php.net. Bien utilizado, con fase de registro, lista de excepciones acordada, pruebas y fecha de finalización fija, es defendible. Sin estos pasos corre el riesgo de perder candidaturas, bloquear redacciones y sufrir fallos silenciosos de interfaces.
Por eso tome la decisión de forma consciente y deje constancia de quién la tomó y cuándo. Y tenga presente el orden: primero viene la actualización de PHP con el reinicio de todos los workers, las medidas transitorias de php.net salvan el tiempo hasta entonces, y el filtro es, como mucho, una capa adicional.
¿Cómo ayuda PHP SOS en concreto?
- Valorar la situación: aclaramos si un filtro de subidas tiene sentido en su caso o si la actualización es posible más rápido.
- Registrar y analizar: configuramos la fase de registro y deducimos la lista de excepciones de accesos reales.
- Bloquear de forma controlada: activamos el filtro, probamos formularios y vías de pedido y vigilamos las peticiones rechazadas.
- Retirarlo limpiamente: en el marco de WAF y parcheo virtual retiramos el filtro de nuevo tras la actualización.
Preguntas frecuentes
¿Es el filtrado de peticiones multipart una recomendación oficial de php.net?
No. php.net cita otras medidas transitorias, como límites para post_max_size y desactivar session.upload_progress. El filtrado en el borde es una propuesta de artículos especializados y está pensado expresamente solo como medida temporal.
¿Qué funciones pueden dejar de funcionar por el filtro?
Todo lo que envíe archivos o formularios en formato multipart y no esté en su lista de excepciones: formularios de contacto con adjunto, formularios de candidatura, gestión de medios del CMS, funciones de importación, algunas interfaces y retornos de pago. Por eso, antes de bloquear, hay una fase de registro.
¿Sustituye el filtro a la actualización de PHP?
No. Como mucho reduce la superficie de ataque en el periodo transitorio. Cloudflare advierte por sí mismo de que las reglas basadas solo en los datos de la petición no bastan. PHP2Shell solo queda corregido con una versión parcheada de PHP y el reinicio de todos los workers.
¿Debo bloquear en su lugar las peticiones con PHPSESSID?
No. Los autores especializados rechazan expresamente este consejo que circula. Paraliza los inicios de sesión y los carritos de la compra sin ofrecer una protección fiable.