En resumen: Un archivo PHP en la carpeta de subida es una señal de alerta seria, porque allí solo deberían estar imágenes y documentos. No abra nunca el archivo en el navegador, sino léalo como texto, compruebe las marcas de tiempo y el propietario y busque el nombre del archivo en los registros de acceso. Suelen ser inofensivos solo los marcadores vacíos, como un index.php sin contenido; todo lo demás trátelo como una posible intrusión.
Por qué PHP no pinta nada en la carpeta de subida
Las carpetas de subida son para contenidos que suben visitantes o redactores: imágenes, PDF, vídeos. El usuario del servidor web puede escribir allí; de lo contrario, las subidas no funcionarían. Eso es justo lo que hace atractivas estas carpetas para los atacantes. Quien puede escribir archivos mediante una vulnerabilidad los deja donde está permitido escribir.
Según los informes de que disponemos, los archivos PHP nuevos en carpetas de subida o de caché figuran entre las señales de alerta generales tras una intrusión. Para PHP2Shell no hay indicadores de compromiso confirmados; un hallazgo no dice, por tanto, nada sobre a través de qué vulnerabilidad llegó el archivo. Cómo se construyen de forma segura las funciones de subida lo describe Implementar de forma segura las subidas de archivos en PHP.
Si un archivo así puede causar daño lo decide la configuración del servidor web. Si ejecuta archivos PHP en la carpeta de subida, cada archivo depositado allí se convierte en un posible control remoto. Si la ejecución está bloqueada allí, el archivo sigue siendo un cuerpo extraño, pero de entrada sin efecto. Muchas instalaciones nunca han configurado ese bloqueo.
¿Cómo llega un archivo PHP a la carpeta de subida?
Para la valoración ayuda conocer los caminos posibles. Cada uno lleva a otras preguntas de seguimiento.
| Camino | Contexto típico | Pregunta de seguimiento |
|---|---|---|
| Formulario de subida inseguro | comprobación solo de la extensión o del tipo comunicado por el navegador | ¿Qué formularios aceptan archivos? |
| Vulnerabilidad en un plugin o tema | vulnerabilidad conocida en una extensión obsoleta | ¿Qué extensiones están obsoletas? |
| Credenciales robadas | cuenta de administración, FTP o alojamiento | ¿Qué inicios de sesión hubo recientemente? |
| Ejecución de código mediante una vulnerabilidad | por ejemplo en el intérprete, como es posible con PHP2Shell | ¿Era vulnerable PHP en ese período? |
| Plugin legítimo | marcador, rara vez archivos de caché | ¿Pertenece el archivo al paquete original? |
Pueden coincidir varios caminos. Un atacante que ejecuta código mediante una vulnerabilidad quizá solo deja el archivo para volver más cómodamente después.
Enumerar sistemáticamente los lugares de hallazgo
Antes de valorar un archivo concreto, obtenga una visión de conjunto. Los comandos solo leen. Las rutas son ejemplos de WordPress; en otros sistemas, adapte la ruta de subida.
# Archivos de tipo PHP en la carpeta de subida con tamaño, propietario, mtime y ctime
find /var/www/html/wp-content/uploads -type f \
\( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.phar" -o -iname ".htaccess" -o -iname ".user.ini" \) \
-printf '%s Bytes %u m:%T+ c:%C+ %p\n'
# Determinar el tipo de archivo por el contenido y no por la extensión (llaman la atención imágenes con contenido PHP)
find /var/www/html/wp-content/uploads -type f -newermt "2026-10-17" -exec file {} + | grep -viE "image|pdf|video|audio"
Otros sistemas usan otras carpetas de escritura, como fileadmin en TYPO3, images en Joomla o la carpeta de medios bajo public en Shopware 6. A ello se suman los directorios de caché y temporales de la aplicación. En instalaciones multisitio y con varios sitios web en un servidor hay otras tantas carpetas de subida; todas pertenecen a la búsqueda.
También los archivos .htaccess y .user.ini en la carpeta de subida son sospechosos. Con ellos se puede volver a activar la ejecución de PHP en esa carpeta o modificar la configuración.
Archivo PHP en la carpeta uploads: interpretar bien el hallazgo
No toda coincidencia es igual de seria. La siguiente clasificación ayuda en la primera valoración. No sustituye a una investigación detallada.
| Hallazgo | Primera clasificación |
|---|---|
index.php con cero bytes o solo un comentario |
normalmente un marcador contra el listado de directorios; contrastar con el plugin |
| Archivo PHP con contenido en una carpeta mensual | sospecha alta |
Doble extensión como bild.jpg.php o .php.png |
sospecha alta, camuflaje típico |
Imagen que según file contiene código PHP |
sospecha alta, puede ejecutarse mediante inclusión |
.htaccess o .user.ini en la carpeta de subida |
sospecha, revisar la configuración |
| El archivo pertenece al usuario del servidor web, ctime posterior al 17/10 | encaja con una intrusión a través del sitio web |
Lea los archivos sospechosos solo como texto, por ejemplo con head -c 2000 datei.php o less. Llaman la atención las líneas muy largas, las cadenas codificadas y nombres de función como eval o base64_decode. Cómo reconocer código ofuscado lo muestra Reconocer código PHP ofuscado.
¿Se llamó al archivo? Una mirada al log
La pregunta más importante tras el hallazgo es: ¿ha utilizado alguien el archivo? La respuesta está en los registros de acceso del servidor web. Busque el nombre del archivo, también en los registros archivados.
# Llamadas al archivo sospechoso en registros actuales y comprimidos (nombre como ejemplo)
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* 2>/dev/null
zgrep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log*.gz 2>/dev/null
# Solo llamadas correctas con dirección IP y momento
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* | awk '$9 == 200 {print $1, $4, $6, $7}'
Muchas peticiones POST correctas desde pocas direcciones indican un uso activo como webshell. Que no haya coincidencias no significa automáticamente que no haya peligro, porque los registros pueden estar rotados, borrados o incompletos. Si el sitio web funciona detrás de una CDN o de un proxy, allí hay más registros; en el alojamiento compartido, el hoster suele facilitar los registros de acceso en el área de cliente. Fíjese además en las peticiones a otros archivos nuevos desde las mismas direcciones, porque a menudo conducen a otros componentes. Conserve los registros desde el 20 de octubre. Cómo analizar los registros a fondo figura en la guía Analizar los registros del servidor web tras un ataque.
Si el log muestra llamadas correctas a un archivo PHP desconocido, dé por hecha una intrusión. Asegure el archivo y los registros, restrinja el acceso al servidor y compruebe si pueden verse afectados datos personales.
Tras la valoración: el orden correcto
- Asegurar: copiar el archivo con suma de comprobación y marcas de tiempo, asegurar los registros.
- Aclarar el origen: revisar formularios de subida, plugins y el período anterior al hallazgo.
- Buscar otros componentes: archivos adicionales, tareas cron, cuentas de administración nuevas.
- Bloquear la ejecución: prohibir PHP en la carpeta de subida a nivel de servidor web, como se describe en el artículo Prohibir la ejecución de PHP en carpetas de subida.
- Limpiar y cambiar los accesos: solo entonces eliminar el archivo y renovar todas las contraseñas.
¿Cómo ayuda PHP SOS en concreto?
- Valorar el hallazgo: revisamos el archivo sin ejecutarlo y lo clasificamos.
- Aclarar el uso: analizamos los registros y reconstruimos quién llamó al archivo y cuándo.
- Limpiar por completo: con la eliminación de malware buscamos todos los componentes, cerramos la causa y cambiamos los accesos.
- Evitar la repetición: bloqueamos la ejecución de PHP en las carpetas de escritura y vigilamos los archivos nuevos.
Preguntas frecuentes
¿Es peligroso todo archivo PHP en la carpeta de subida?
No todos. Algunos plugins dejan un index.php vacío para que no se liste el contenido de la carpeta. Todo lo demás, en especial archivos con contenido, nombre inusual o doble extensión, debería tratarlo como caso sospechoso.
¿Puedo abrir el archivo sospechoso en el navegador?
No. Una llamada a través del sitio web ejecuta el código. Lea el archivo solo como texto en el servidor o en una copia, por ejemplo con less o head.
¿Cómo averiguo si el archivo se ha utilizado?
Busque el nombre del archivo en los registros de acceso del servidor web. Las peticiones con estado 200 y método POST muestran que se llamó al archivo. Las direcciones IP y los momentos asociados ayudan en la investigación posterior.
¿Basta con borrar el archivo y bloquear PHP en la carpeta de subida?
Ambas cosas son necesarias, pero no suficientes. Aclare además cómo llegó el archivo allí, busque otros componentes y cambie las credenciales. De lo contrario, el atacante vuelve por el mismo camino.