Guía para decidir mejor
Cómo detectar archivos PHP sospechosos en uploads
La presencia de PHP en uploads es una señal que exige contexto, preservación y búsqueda del origen.
Un archivo PHP inesperado en wp-content/uploads merece investigación: esa carpeta suele guardar medios, no código ejecutable. Su presencia no prueba por sí sola una infección —alguna herramienta puede crear archivos legítimos—, pero tampoco conviene abrirlo desde el navegador ni borrarlo sin registrar lo ocurrido. Lo importante es averiguar cómo llegó, si pudo ejecutarse y qué más cambió.
Detecta sin ejecutar
Busca desde el gestor de archivos o una herramienta de inventario extensiones ejecutables y nombres atípicos en uploads y subcarpetas, incluyendo archivos ocultos y cambios recientes. Registra ruta, fecha, propietario, tamaño y huella del archivo si tu equipo sabe obtenerla; compara con una copia confiable y con la lista de plugins instalados. No descargues el archivo a un equipo de trabajo corriente ni pulses su URL «para ver qué hace». La guía de pruebas de OWASP explica el riesgo de que una carga ejecutable se convierta en una puerta de entrada.
Contén y preserva la investigación
Si hay indicios sólidos de ejecución, avisa al hosting o al responsable técnico para aislar el sitio o impedir la ejecución de scripts en esa carpeta mediante una configuración compatible con el servidor. Guarda una copia restringida y metadatos antes de poner en cuarentena; no la dejes descargable públicamente. Revisa logs de acceso para ver si se solicitó esa ruta y qué usuario o proceso pudo subirla. No pegues el contenido en servicios públicos de análisis si incluye credenciales o datos personales.
Busca el origen y valida la recuperación
Comprueba permisos, formularios de subida, plugins, usuarios administradores, otros ficheros modificados, tareas programadas y base de datos. Las extensiones dobles o el tipo MIME declarado no bastan para decidir si un archivo es seguro; el servidor puede interpretar ciertos nombres de maneras inesperadas. La checklist de subida segura de OWASP propone defensa por capas.
Tras corregir la vía de entrada, reinstala componentes afectados desde fuentes confiables o restaura una copia verificada preservando datos nuevos. Cambia credenciales expuestas y monitoriza reaparición. Continúa con la respuesta completa a una infección WordPress; eliminar un solo PHP no certifica que se haya erradicado el problema. Para prevención, revisa también propiedad y permisos sin aplicar cambios recursivos a ciegas.
Cómo limitar la ejecución de PHP en uploads
Tras preservar evidencia y corregir la entrada, pide al administrador que confirme qué servidor atiende esa ruta y cómo interpreta archivos ejecutables. En Apache puede haber reglas por directorio; en NGINX, la decisión suele estar en la configuración del virtual host. No copies un archivo .htaccess pensando que NGINX lo leerá. Valida la regla en staging: una petición a un script de prueba autorizado en uploads debe ser denegada, mientras una imagen legítima sigue sirviéndose. Retira el script de prueba controladamente y comprueba subcarpetas, extensiones dobles y rutas alternativas.
Bloquear ejecución reduce una vía, pero no demuestra que la web ya esté limpia: revisa plugins, cuentas, cron y archivos fuera de uploads. La guía de OWASP sobre subidas recomienda validar tipo, contenido, almacenamiento y permisos por capas. Documenta la configuración y revalídala tras migrar de servidor.