Cómo Evitar Webshells en tu Carpeta de Imágenes

Resulta cuestionable que la implementación estándar de WordPress no incluya, por defecto, una directiva que impida la ejecución de código en la única carpeta que obligatoriamente debe tener permisos de escritura. Es una invitación abierta. Si un atacante logra saltarse la validación de extensiones de un plugin de formularios —algo que pasa más a menudo de lo que nos gustaría—, tendrá vía libre para ejecutar una webshell y tomar el control total. Bloquear la ejecución de scripts PHP en el directorio de subidas es, posiblemente, la mejora de seguridad con mayor retorno de inversión que puedes aplicar hoy mismo.

#El Directorio de Subidas: Un Caballo de Troya

Por diseño, la carpeta wp-content/uploads es el lugar donde viven tus fotos, PDFs y vídeos. El servidor web necesita escribir en ella. Sin embargo, no hay ninguna razón legítima para que un archivo PHP resida o se ejecute allí. Parece mentira que estemos en 2026 y todavía dependamos de que el sysadmin de turno se acuerde de cerrar esta ventana. Si un exploit permite subir un archivo llamado imagen.jpg.php, y tu servidor lo procesa, estás fuera de combate.

#Protocolo de Bloqueo mediante .htaccess

La solución técnica es sencilla. Se trata de crear un archivo .htaccess específico dentro de la carpeta que queremos proteger. No confundas esto con el archivo raíz de WordPress; este vivirá exclusivamente dentro de uploads. Tras revisar varios hilos en foros de seguridad (donde todavía hay quien discute si esto es necesario), yo lo considero un estándar de hardening básico.

#Configurar en /wp-content/uploads/.htaccess:

# Desactivar el motor PHP en este directorio y sus subdirectorios
<Files *.php>
    # Denegamos el acceso a cualquier archivo con extensión .php
    # Esto previene la ejecución incluso si el archivo logra ser subido.
    Order Deny,Allow
    Deny from all
</Files>

#Problema real con una vulnerabilidad en un plugin de sliders

Ocurrió hace meses en el sitio de un cliente que usaba un plugin de sliders bastante popular pero mal mantenido. Empezamos a notar que el sitio enviaba spam masivo de repente. Los resultados fueron claros. Nada de errores de servidor típicos. El problema era un archivo PHP «ninja» alojado en la carpeta de imágenes del mes de octubre.

Al investigar la «huella» de la intrusión, vi que el atacante había aprovechado un fallo en la subida de miniaturas. Logró colar un script que le permitía ejecutar comandos. El síntoma clínico fue la aparición de archivos con nombres aleatorios como xz34.php en los directorios de subidas. Antes de entrar en pánico, el cliente intentó borrar los archivos a mano, pero el bot los regeneraba en segundos. Fue un juego del gato y el ratón inútil.

La solución definitiva no fue limpiar los archivos (que también), sino implementar la regla de .htaccess que ves arriba. En cuanto la regla estuvo activa, el script malicioso dejó de responder. El bot seguía ahí, intentando ejecutar su código, pero el servidor Apache le devolvía un 403 sistemático. Cortamos la comunicación del atacante en seco sin depender de antivirus o escáneres pesados.

#Plan de rescate y comprobación

Esta medida es muy segura, pero si usas algún plugin exótico que genere archivos PHP dinámicos en la carpeta de subidas (algo que, por cierto, es una práctica nefasta), podrías romper esa funcionalidad.

Si tras añadir el archivo notas que alguna parte de tu administración falla, simplemente borra el archivo .htaccess de /wp-content/uploads/. No afectará al resto de tu web. Para verificar que funciona, intenta subir tú mismo un archivo de prueba test.php por FTP a esa carpeta e intenta acceder desde el navegador. Si ves un error de «Acceso denegado», has ganado.

#¿Es esta técnica para ti?

• Escenarios recomendados: Casi el 100% de las instalaciones de WordPress. Es una regla de oro de seguridad pasiva.
• Escenarios exóticos: Solo evítalo si usas sistemas de caché muy antiguos o plugins de generación de PDFs que, por algún motivo absurdo, necesiten ejecutar scripts desde esa ruta.

#Pros y Contras

• Pros: Protección inmediata contra el 90% de los ataques de subida de archivos, impacto nulo en el rendimiento y fácil de revertir.
• Contras: Solo funciona en servidores Apache o Litespeed. En Nginx requiere configuraciones en el archivo de bloques del servidor (fuera del alcance de este post).

«La mejor seguridad no es la que detecta el virus, sino la que hace que el entorno sea inhóspito para su ejecución.»

Para aprender más sobre cómo blindar tu instalación, te sugiero leer la guía de Hardening oficial de WordPress o consultar las recomendaciones de Sucuri sobre limpieza de malware.