CVE Joomla Balbooa RCE File Upload 5 min lectura

Balbooa Forms para Joomla: RCE sin autenticación vía upload de adjuntos (CVE-2026-56291)

Un visitante anónimo puede subir un PHP y tomar el server Joomla. La extensión Balbooa Forms (com_baforms) tenía el handler de adjuntos abierto a Internet sin chequeo de autenticación, sin token CSRF y sin whitelist de extensiones. Parcheá a la 2.4.1 ya.

IP
IPSecureNetwork
July 11, 2026

Contexto del incidente

El jueves 9 de julio de 2026 el Joomla! Project publicó el advisory para CVE-2026-56291, una vulnerabilidad de severidad máxima en la extensión Balbooa Forms (com_baforms). Veinticuatro horas después, el 10 de julio, CISA la agregó a su catálogo KEV con date_added 2026-07-10 y due_date 2026-07-13, y la columna de ransomware figura como "Unknown" — pero el flag E:A del CNA confirma que hay explotación activa en la naturaleza, previa a la publicación del parche.

El vector CVSS v4.0 reportado por el CNA del Joomla! Project es el peor posible: 10.0 (Red). La cadena completa es AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:A/AU:Y/U:Red. En castellano: vector de red, complejidad baja, sin requisitos previos, sin privilegios, sin interacción del usuario, impacto alto en confidencialidad, integridad y disponibilidad tanto del sistema vulnerable como de los sistemas posteriores alcanzables desde él, exploit disponible y automatizable. La categoría CWE es CWE-434 — Unrestricted Upload of File with Dangerous Type.

El detalle técnico de la falla está en el handler FormModel::uploadAttachmentFile() del componente. La función recibe un archivo vía POST multipart, lee la extensión del nombre enviado por el atacante y la aplica tal cual al archivo escrito en disco, pasando por encima del sanitizer File::makeSafe() de Joomla — que normaliza caracteres pero NO bloquea extensiones peligrosas como .php. No hay whitelist de extensiones, no hay chequeo de MIME, no hay validación de token CSRF y, lo más grave, no hay chequeo de autenticación: cualquier IP que llegue al endpoint puede subir un web shell. La ruta vulnerable completa es /index.php?option=com_baforms&task=form.uploadAttachmentFile y los archivos quedan en /images/baforms/uploads/, una carpeta públicamente accesible y ejecutable por PHP. El PoC es un único request HTTP con un archivo shell.php; el atacante después lo invoca y obtiene ejecución de código en el contexto del usuario del web server.

El alcance es amplio: Balbooa Forms tiene cientos de miles de instalaciones activas en Joomla, en sitios que van desde formularios de contacto corporativos hasta portales de inscripción y checkout. Versiones afectadas: todas desde la 1.0 hasta la 2.4.0 inclusive. Versión parchada: 2.4.1, publicada el mismo 9 de julio, que introduce validación de extensiones por campo, chequeo de MIME, nombres generados del lado del server (sin confiar en el nombre que manda el cliente) y validación de token CSRF en todos los uploads. La ventana entre divulgación pública y explotación masiva fue de horas, no de días — exactamente el patrón que vimos el año pasado con la oleada de zero-days en extensiones Joomla y WordPress.

La regla de oro del file upload es que la extensión válida NO la decidís vos desde el cliente — la decidís vos desde el server, contra una whitelist corta, ignorando lo que diga el navegador o el header Content-Type.

¿Cómo proteger tu infraestructura?

1. Actualizá Balbooa Forms a 2.4.1 ya

Si administrás un Joomla con formularios públicos y todavía corrés Balbooa Forms ≤ 2.4.0, hacelo hoy: Extensions → Manage → Update en el backend de Joomla, o bajá el paquete directo desde el Joomla Extension Directory (JED). Después de actualizar, verificá la versión instalada entrando a Extensions → Manage y comprobá que figure "Balbooa Forms 2.4.1". No te quedes en la 2.4.0 pensando "ya casi estamos" — la 2.4.0 sigue siendo vulnerable.

2. Buscá shells ya subidos en images/baforms/uploads/

Aunque parcheés, si fuiste comprometido antes, el atacante dejó un web shell ahí. Listá el directorio por SSH o desde el File Manager de cPanel y revisá cualquier archivo .php, .phtml, .phar, .pht, archivos con doble extensión (shell.php.jpg, cmd.php.png) y nombres con caracteres Unicode confusibles. Ese directorio está pensado solo para adjuntos subidos por usuarios finales (PDFs, fotos, currículums), así que cualquier .php legítimo en esa ruta es altamente sospechoso. Comando rápido:

find /home/*/public_html/images/baforms/uploads/ -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" -o -name "*.pht" \) -printf "%p %s %TY-%Tm-%Td\n"

3. Bloqueá el endpoint en el WAF hasta confirmar el parche

Si necesitás horas para coordinar el update con un equipo grande, una regla temporal en ModSecurity, Cloudflare WAF o un bloque location en nginx te compra tiempo sin tirar el formulario público. La firma es: POST a index.php con query string conteniendo option=com_baforms&task=form.uploadAttachmentFile y Content-Type: multipart/form-data. Equivalente en nginx (bloquea con 403):

if ($request_method = POST) {
    set $b 0;
    if ($args ~* "option=com_baforms") { set $b 1; }
    if ($args ~* "task=form\.uploadAttachmentFile") { set $b $b+1; }
    if ($http_content_type ~* "multipart/form-data") { set $b $b+1; }
    if ($b = 3) { return 403; }
}

4. Hunting en logs de acceso buscando POSTs a ese endpoint

En Apache o nginx filtrá por POST /index.php?option=com_baforms y revisá los responses 200 con cuerpo HTML/PHP anormales (los uploads legítimos devuelven JSON con el nombre del archivo subido, no HTML). En Splunk o Elastic Stack:

index=apache OR index=nginx
| search uri="*com_baforms*" method=POST status=200
| stats count by src_ip, uri, user_agent, _time
| where count > 5
| sort -count

Sumá esta búsqueda a tu runbook de hunting semanal. Esta clase de falla — upload handler sin auth — va a repetirse con cada nueva extensión Joomla (o WordPress, o Drupal), así que tener una query guardada para los endpoints de upload de adjuntos de los CMS más comunes te detecta el próximo caso el día uno.

Indicadores de compromiso (IoC)

Estos son los IoC específicos del CVE-2026-56291 que podés usar para detección y respuesta. Los paths y endpoints están confirmados contra el advisory del Joomla! Project y el análisis técnico de ionix.io.

  • Endpoint vulnerable: POST /index.php?option=com_baforms&task=form.uploadAttachmentFile (sin autenticación, sin CSRF).
  • Directorio de drop del atacante: /images/baforms/uploads/ dentro del root web de Joomla (público y ejecutable por PHP).
  • Extensiones maliciosas típicas: .php, .phtml, .phar, .pht, y archivos con doble extensión como shell.php.jpg o cmd.php.png.
  • Patrón de request: POST multipart/form-data con campo de archivo cuyo nombre contiene la extensión PHP; respuesta HTTP 200 con cuerpo HTML/PHP (los uploads legítimos devuelven JSON con el nombre guardado).
  • Versiones vulnerables: Balbooa Forms 1.0 hasta 2.4.0 inclusive. Versión parchada: 2.4.1 (publicada 9 de julio de 2026).
  • Fuente de telemetría útil: Shadowserver publica un feed diario de servidores Joomla con Balbooa Forms detectable por banner; revisá si tu rango aparece y cruzá con tus logs.
# Hunting rápido desde el shell del server Joomla
grep -E "POST .*com_baforms.*uploadAttachmentFile" /var/log/apache2/access.log \
  | grep -E " 200 " \
  | awk '{print $1, $4, $7}' \
  | sort | uniq -c | sort -rn | head -20

🛡️ ¿Tu Joomla acepta uploads sin login?

Si administrás uno o más portales Joomla con formularios públicos — Balbooa Forms, RSForm, BreezingForms, cualquier otro — una auditoría rápida de los handlers de upload te puede ahorrar un incidente. En IPSecureNetwork revisamos cada endpoint que toca Internet en tu CMS: archivo subido, validación, permisos del directorio de drop y monitoreo post-upload.

SOLICITAR AUDITORÍA →