Guías de seguridad
Vulnerabilidades en la subida de archivos: cómo evitar web shells y RCE desde el diseño
Una subida de archivos mal diseñada permite a un atacante sin autenticar colocar un archivo que el servidor ejecuta (web shell → RCE). Cómo evitarlo por capas.
Para quien tenga una aplicación (o una extensión instalada) que recibe archivos: formularios, paneles de administración, plugins de CMS, API. Aquí no hay instrucciones de ataque; solo cómo hacer segura tu función de subida, a partir de hechos públicos. Relacionado: cómo corregir para siempre los fallos de las dependencias en el manual para corregir CVE y la base de seguridad para organizaciones.
Qué ocurre en realidad (en palabras sencillas)
La mayoría de las aplicaciones tiene algún lugar para recibir archivos: «sube una imagen», «cambia el icono», «adjunta un documento». Donde está mal protegido, un atacante envía un script disfrazado de imagen y consigue que se guarde en una carpeta que sirve la web. Después solo tiene que abrir la URL de ese archivo en un navegador: si el servidor ejecuta su contenido como un programa, el atacante puede lanzar órdenes a distancia. Eso es una web shell (un pequeño programa de control remoto que se deja en el servidor), y de ahí vienen la desfiguración del sitio, el robo de datos, las cuentas de administrador creadas a escondidas y la propagación a otros sistemas.
El problema es la ubicación y la ejecución, no recibir el archivo
Subir archivos es una función legítima. El peligro es colocar lo recibido donde se puede ejecutar, en una forma que se puede ejecutar. Al revés: aunque recibas un archivo sospechoso, no pasa nada si termina en un lugar donde nunca se ejecuta, se inspecciona su contenido y el punto de subida exige autenticación. Cambia la mentalidad de «bloquear archivos malos» a «que el lugar de almacenamiento nunca ejecute nada».
Los casos reales de 2026: extensiones de Joomla explotadas de forma masiva (el mismo patrón)
En 2026, varias extensiones de Joomla publicaron una tras otra exactamente el mismo patrón de subida sin autenticación → RCE y fueron explotadas de forma amplia. Según se informó, combinaban «sin comprobación de autenticación + sin validación del tipo de archivo + almacenamiento bajo la raíz web», una combinación típica. Se extendió más allá de los constructores de páginas, a una extensión de calendario de eventos, y la CISA fijó plazos cortos para corregirlo.
- SP Page Builder (CVE-2026-48908)
- De JoomShaper. Afecta a ≤ 6.6.1, corregido en 6.6.2. Según se informó, la subida de iconos personalizados no hacía comprobación de autenticación ni validación del tipo; CVSS 10.0, explotado activamente (incluido en el KEV de la CISA). Alerta: CVE-2026-48908.
- iCagenda (CVE-2026-48939)
- De joomlic, una extensión de calendario de eventos. Afecta a 3.2.1–3.9.14 / 4.0.0–4.0.7, corregido en 3.9.15 / 4.0.8. Según se informó, el control de acceso del gestor de adjuntos del formulario público de inscripción a eventos solo se aplicaba en la capa de vista; CVSS 10.0, explotado activamente (incluido en el KEV de la CISA). Alerta: CVE-2026-48939.
- Page Builder CK (CVE-2026-56290)
- De joomlack.fr. Afecta a ≤ 3.5.10, corregido en 3.6.0 (con correcciones llevadas a ramas anteriores en 3.1.1 / 3.4.10). Según se informó, la misma subida sin autenticación que lleva a RCE; CVSS 10.0.
- Lo que comparten
- Se puede explotar sin iniciar sesión = objetivo de escaneos indiscriminados. Según se informó, los ataques se centraron en conservar el acceso: crear cuentas de administrador ocultas y colocar web shells para que el atacante mantenga el acceso incluso después de parchear la vulnerabilidad.
- La primera corrección
- Actualiza la extensión afectada a la versión corregida (y haz inventario de las extensiones que no usas para eliminarlas). Además, el diseño y la configuración que siguen, por capas.
Lección: una extensión que no se usa suele ser el punto débil más explotado
Los casos tienen algo en común: se entró a través de una extensión olvidada que seguía instalada. Cada plugin o extensión de CMS que añades es más superficie de ataque. Con solo hacer inventario y borrar lo que no usas, reduces lo que puede alcanzar este tipo de explotación masiva (cómo hacer el inventario de tus activos).
Cada fase del ataque y cómo detenerla
Este patrón tiene un punto donde detenerlo en cada paso. Léelo como dónde se puede detener, no como instrucciones.
1. Se envía un archivo a un punto de subida sin autenticación
Cualquiera puede llegar al gestor de subidas y enviar un script.
Solución: autenticación + comprobación de permisos + token CSRF
2. Se salta la validación del tipo y se guarda
Extensión / Content-Type falsificados; disfrazado de «imagen».
Solución: lista de permitidos en el servidor + inspección del contenido (magic bytes)
3. Termina bajo la raíz web, accesible por URL
Se guarda en una ruta fácil de adivinar y se puede abrir directamente en un navegador.
Solución: guardar fuera de la raíz web / nombres de archivo aleatorios
4. El servidor lo ejecuta como un script
Ejecución permitida en la carpeta de almacenamiento = web shell → RCE.
Solución: desactivar la ejecución de scripts en la zona de subidas
Configuración insegura frente a configuración segura
La configuración que falla
- El punto de subida no comprueba autenticación ni permisos (cualquiera llega)
- Se decide solo por la extensión o el Content-Type (falsificables, extensiones dobles)
- Los archivos recibidos se guardan directamente bajo la raíz web
- El lugar de almacenamiento sigue permitiendo ejecutar scripts
- Los nombres de archivo los pone el usuario o son fáciles de adivinar
La configuración que resiste
- Autenticación + permisos + CSRF obligatorios en el punto de subida
- Lista de permitidos para el tipo e inspección de los bytes reales (magic bytes)
- Almacenamiento fuera de la raíz web (servido mediante un gestor dedicado)
- La zona de subidas tiene la ejecución de scripts desactivada
- Se renombra con un nombre aleatorio; nunca se confía en rutas del usuario
Cómo implementarlo (por orden de prioridad)
Exige autenticación, permisos y CSRF en el punto de subida
El punto que gestiona las subidas solo debe ser accesible para un usuario con sesión iniciada y el permiso adecuado, y debe verificar un token CSRF. Según se informó, en los casos de Joomla de 2026 faltaba justamente esta comprobación de autenticación y permisos. Primero, elimina el estado de «cualquiera puede llamarlo».
Usa una lista de permitidos e inspecciona el contenido en el servidor
No confíes nunca en las comprobaciones del lado del cliente ni en el Content-Type que envía el navegador. En el servidor, permite solo los tipos conocidos mediante una lista de permitidos e inspecciona los bytes reales del archivo (magic bytes) para confirmar que de verdad es de ese tipo. Normaliza las extensiones dobles, las mayúsculas y los puntos finales antes de decidir.
Guarda fuera de la raíz web (o desactiva la ejecución)
Guarda los archivos recibidos donde no se puedan abrir directamente por URL y sírvelos mediante un controlador dedicado (con un Content-Disposition adecuado). Si eso es difícil, al menos desactiva la ejecución de scripts en la zona de subidas (configuración del servidor web). Si esto se cumple, ni siquiera un archivo malicioso se ejecutará. Te protege cuando fallan los demás controles.
Usa nombres aleatorios; añade límites de tamaño y de frecuencia
Renombra con un nombre aleatorio elegido por el servidor y nunca confíes en rutas o nombres de archivo que envía el usuario (para evitar el path traversal). Añade límites de tamaño y de frecuencia y, cuando sea posible, un análisis de malware.
Haz inventario y parchea tus extensiones y tu CMS
Haz inventario de las extensiones y plugins que usas, borra los que no usas y mantén el resto actualizado. En la explotación masiva de 2026, los atacantes entraron por extensiones sin actualizar. Siguiendo el manual para corregir CVE, añade detección de cambios para que se detecte si vuelven a aparecer.
Dónde coincide esto con cómo está construido este sitio
El problema central de este patrón es colocar una entrada no fiable donde se puede ejecutar, en una forma que se puede ejecutar. Los principios de este sitio son lo contrario: no confiar en lo que se recibe, aislar lo importante y defender por capas. Más allá de las subidas, «validar la entrada en el servidor» y «aislar los secretos y las zonas ejecutables» son la misma defensa. Consulta también los errores de ubicación en no pongas secretos en directorios públicos.
Leer a continuación
- Intrusión con un agente de IA: La intrusión en Hugging Face (2026): un ataque de un agente de IA autónomo
- La brecha de Gyazo (septiembre de 2026): qué se filtró y qué deben hacer hoy los usuarios
- Manipulación de una página de pago (septiembre de 2026): Programa de robo de tarjetas en la página de pago de PhotoGoods (Daiko Printing) (un caso en el que se señaló como causa el abuso de una función de subida de archivos)
- Términos: deserialización insegura (los datos externos deciden el tipo) / qué es la RCE (ejecución remota de código) / qué es el malware (una web shell es un tipo de malware)
- Alertas: CVE-2026-48908 (SP Page Builder) / CVE-2026-48939 (iCagenda) (el mismo patrón de subida sin autenticación → RCE)
- En la práctica: la base de seguridad para organizaciones / manual para corregir CVE / no pongas secretos en directorios públicos
FAQ
Q¿Por qué un fallo en la subida de archivos permite a un atacante tomar el control del servidor?
Si un atacante puede colocar un archivo que el servidor ejecutará (un script), basta con abrirlo en un navegador para ejecutar código en el servidor (una web shell → ejecución remota de código, RCE). A partir de ahí: desfiguración del sitio, robo de datos, cuentas de administrador creadas a escondidas y propagación a otros sistemas. Lo clave no es que se recibiera un archivo, sino que el archivo se puede ejecutar donde terminó.
Q¿Basta con comprobar la extensión del archivo?
No. La extensión y el Content-Type que envía el navegador se falsifican con facilidad. Las extensiones dobles (imagen.php.jpg), los trucos con mayúsculas, los puntos o bytes nulos al final y las extensiones ejecutables poco conocidas se saltan las comprobaciones ingenuas. Defiéndete combinando una lista de permitidos (solo lo que se sabe que es correcto), la inspección de los bytes reales del archivo (magic bytes) y, sobre todo, que el lugar de almacenamiento no ejecute nada. No dependas de una lista de bloqueo.
Q¿Se ataca también a los sitios pequeños?
Sí. Este tipo de fallo se puede explotar sin autenticación, así que los atacantes escanean todo internet y atacan las versiones vulnerables de forma indiscriminada. En la explotación masiva de extensiones de constructores de páginas de Joomla de 2026, todas las instalaciones afectadas fueron objetivo, sin importar su tamaño. «Somos demasiado pequeños para que nos ataquen» no se sostiene.