Page Builder CK para Joomla expone RCE sin autenticación vía upload arbitrario (CVE-2026-56290)

Contexto del incidente

El 7 de julio de 2026, CISA agregó CVE-2026-56290 al catálogo Known Exploited Vulnerabilities con fecha de remediación federal 10 de julio, bajo la BOD 26-04. La vulnerabilidad reside en el componente Page Builder CK, una extensión de maquetado visual (drag-and-drop) para Joomla publicada por el desarrollador francés Cedric Keiflin, instalado en miles de sitios para construir landing pages y bloques de contenido sin tocar código.

El puntaje es el techo absoluto: CVSS 4.0 = 10.0 (CRITICAL), con vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. La clase registrada es CWE-434 (Unrestricted Upload of File with Dangerous Type) cruzada con CWE-284 (Improper Access Control). En castellano: el handler de upload del front-end de Page Builder CK no exigía autenticación, no verificaba la extensión del archivo subido, no restringía el directorio de destino y solo se "protegía" con un token CSRF que cualquier visitante anónimo podía levantar del HTML público del sitio en una sola request.

Lo que vuelve a CVE-2026-56290 particularmente serio es el alcance del control que el atacante obtiene. En un upload bug clásico, el archivo cae en un directorio de imágenes que, por configuración del servidor, no ejecuta PHP. Acá no: el atacante elige tanto el nombre del archivo como el directorio destino, así que puede apuntar el upload a una ruta bajo /media/com_pagebuilderck/ que sí ejecuta scripts, o incluso a cualquier directorio del Joomla donde Apache/PHP-FPM esté configurado para servir ejecutables. El resultado es control total del sitio como el usuario del web server, lo que en hostings compartidos suele ser suficiente para comprometer cuentas vecinas via path traversal o abusing de cPanel/FTP.

La confirmación de explotación activa llegó rápido. El equipo de mysites.guru, que descubrió la falla comparando el código antes y después del parche, reportó que dentro de horas del fix publicado el 27 de junio su escáner empezó a marcar sitios Joomla de su base con web shells plantados por exactamente esta vía. Uno de los artefactos identificados: /media/com_pagebuilderck/gfonts/bhup.php, un handler que ejecuta lo que reciba por POST. La cadena es tan simple como el código: una GET a la página pública del sitio para levantar el token CSRF embebido, una POST al endpoint de upload con un archivo .php cuyo destino se especifica en el payload, y la ejecución inmediata del archivo en cualquier browser. Sin exploits de complejidad, sin encadenamiento de bugs, sin ingeniería social.

Cuando la única protección de un upload endpoint es un token que vive en la misma página pública que el endpoint, esa protección no existe: el atacante lee el token antes de usarlo.

Lo que falló en el diseño (y por qué importa)

Page Builder CK está en el radar de cualquier equipo que use Joomla para contenido: la extensión es de las tres más instaladas del Joomla Extensions Directory, con cientos de miles de sitios activos según el ranking del JED. El handler vulnerable se llama desde el front-end vía una ruta accesible para visitantes, lo cual no es en sí mismo un problema de diseño — la mayoría de los formularios de upload legítimos (logos de usuario, avatares, adjuntos) se sirven desde allí. El problema es que el handler fue pensado para editores autenticados, expuesto a internet sin auth check, y "asegurado" con el único mecanismo que Joomla siempre trae activado: el CSRF token.

El patrón del token CSRF como única defensa es engañoso porque parece algo pero no hace nada contra un atacante anónimo. Joomla emite el token en cada página pública (en un campo hidden de los formularios o en un <meta>) porque está pensado para evitar que un sitio malicioso en otra pestaña fuerce un submission desde la sesión autenticada del visitante. Pero un adversario que empieza la cadena visitando la página pública del sitio a atacar ya tiene un token válido para enviar a ese mismo sitio en una request propia. La confusión entre "CSRF = autenticación" y "CSRF = anti-CSRF" es la causa raíz.

El segundo problema es de defensa en profundidad ausente. Una validación de extensión en whitelist (jpg, png, webp, svg safe si se valida), una verificación de tipo MIME real (no la del cliente, la del archivo), un .htaccess que deshabilite la ejecución de scripts bajo /media/com_pagebuilderck/ y una generación de nombres aleatorios sin preservar la extensión habrían cortado la cadena por separado. Ninguna estaba presente en las versiones 1.0 a 3.5.10. La única defensa era el código que Cedric Keiflin publicó con la versión 3.6.0, cuyo changelog dice solamente — literalmente — "IMPORTANT : Fix security issue".

¿Cómo proteger tu infraestructura?

1. Actualizá Page Builder CK a 3.6.0 hoy, en cada sitio Joomla que administres

El fix está disponible desde el 27 de junio en joomlack.fr. Para la línea 3.x actual de Joomla es la 3.6.0; el vendor también back-patcheó las ramas Joomla 3.1.x y 4.x legacy. Bajá el paquete, validá el checksum contra el publicado por Joomlack, instalá vía Joomla Extension Manager o jcli. En hostings con múltiples sitios (Plesk, cPanel, DirectAdmin con many Joomla installs) corré un escaneo de filesystem que busque /components/com_pagebuilderck/pagebuilderck.xml en cada árbol de cuenta y filtre por la versión reportada — cualquier cosa que diga <version>3.5.10</version> o inferior es vulnerable. Asumí compromiso en los sitios donde el componente haya estado instalado sin parche entre el 27 de junio y hoy.

2. Si no podés actualizar hoy, deshabilitá el componente y bloqueá el endpoint

Como mitigación de emergencia entrá a Extensions → Manage → Manage, filtrá por "Page Builder CK" y desactivá el componente. Eso lo borra del menú de administración y del index de extensiones, pero no elimina los archivos del servidor: los handlers quedan en /components/com_pagebuilderck/ y siguen siendo invocables por URL. Para bloquear realmente el endpoint, agregá una regla en el vhost Apache o Nginx que rechace requests POST al patrón /components/com_pagebuilderck/ o que niegue la ejecución de PHP bajo /media/com_pagebuilderck/. En Apache la regla limpia es <Directory "/var/www/.../media/com_pagebuilderck"> <FilesMatch "\.ph(p[3457]?|t|tml|ar)$"> Require all denied </FilesMatch> </Directory>. En Nginx equivalente con location ~* /media/com_pagebuilderck/.*\.ph(p[3457]?|t|tml|ar)$ { deny all; }. Esto rompe el vector de RCE incluso si la extensión sigue habilitada. Conviene aplicar ambos: deshabilitar el componente y la regla de filesystem, en defensa por capas.

3. Audita cada sitio Joomla en busca de web shells bajo /media/com_pagebuilderck/

Si tenés sitios Joomla corriendo Page Builder CK por debajo de 3.6.0, asumí que ya pueden estar comprometidos. Los web shells asociados al incidente documentado por mysites.guru cayeron en rutas específicas que conviene buscar de manera proactiva. En cada sitio Joomla corré, desde la raíz del documento: find . -type d -name "com_pagebuilderck" -path "*/media/*", y sobre el resultado listá cualquier archivo .php, .phtml, .phar, .pht que no sea parte del paquete original. El IoC puntual compartido por mysites.guru fue /media/com_pagebuilderck/gfonts/bhup.php — buscá ese nombre exacto y todos los archivos *.php en subdirectorios creados por el atacante bajo /media/com_pagebuilderck/gfonts/. Para cada hallazgo: aislá el archivo (no lo borres, preservalo para IR), tomá su timestamp de creación, auditá los logs de Apache/Nginx del sitio en busca de requests POST a /components/com_pagebuilderck/ con Content-Type de subida (multipart/form-data, application/octet-stream) y revisá el resto del sitio por otros artefactos del atacante.

4. Endurecé el upload handler aun después del parche y vigilá los uploads en logs

El fix de 3.6.0 cierra el flujo no autenticado pero conviene sumar defensa en profundidad para que una falla similar en otra extensión no te pegue igual. En /media/com_pagebuilderck/ dejá un .htaccess con php_flag engine off y/o bloqueos equivalentes a nivel Nginx: aunque esa carpeta no debiera ejecutar PHP, una mala config de PHP-FPM o un cambio futuro podrían revertirlo. Sumá una regla en tu WAF o reverse proxy que alerte cualquier POST a /components/com_pagebuilderck/ con Content-Type: multipart/form-data y body que incluya filename="...php" — no es un patrón legítimo de uso normal del componente. En Splunk o Elastic, indexá los logs de acceso de Apache/Nginx de cada sitio Joomla y armá una búsqueda que devuelva los POST a /components/com_pagebuilderck/ con response code 200 o 302 agrupados por IP de origen: si ves un solo cliente haciendo muchos uploads en una ventana corta, eso es señal clara de automatización de la cadena. Por último, comprobá que open_basedir en tu php.ini de host esté configurado para que PHP no pueda escribir fuera del document root del sitio: el atacante no debería poder plantar un PHP en otra cuenta de hosting compartido del mismo servidor.

Indicadores de compromiso (IoC)

Estos IoCs están extraídos de la divulgación coordinada del fix y del reporte técnico de mysites.guru. Son los que aplican a la cadena CVE-2026-56290. Si administrás sitios Joomla con Page Builder CK, contrastá tu estado contra la lista. Si cualquier ítem aparece en producción, asumí compromiso del sitio y escalá a respuesta.

• Versiones vulnerables: Page Builder CK 1.0 a 3.5.10 inclusive, en todas las líneas Joomla soportadas (3.x, 4.x legacy). Se verifica en /administrator/components/com_pagebuilderck/pagebuilderck.xml → <version>.
• Versión parchada: 3.6.0 para Joomla 3.x (rama actual). El vendor también back-patcheó las líneas legacy: 3.1.13 y 4.0.5 para soporte Joomla 4.
• IoC de filesystem (web shell documentado): archivo /media/com_pagebuilderck/gfonts/bhup.php. Cualquier *.php, *.phtml, *.phar, *.pht bajo /media/com_pagebuilderck/ que no pertenezca al paquete original de la extensión debe tratarse como malicioso.
• Patrón de ataque en logs de acceso: POST /index.php?option=com_pagebuilderck&task=... seguido de un GET /media/com_pagebuilderck/<archivo_subido>.php desde el mismo User-Agent / IP en menos de 5 segundos. El método de subida con Content-Type: multipart/form-data y body con un campo de archivo cuyo filename termina en .php es el patrón de la cadena. Las requests vienen casi siempre sin header de autenticación Joomla (X-Joomla-Token) y sin cookie de sesión; ese detalle es el que marca la cadena como no legítima.
• CSRF token leak como precursor: el handler requiere un token CSRF válido pero el token está embebido en cualquier página pública del sitio (en un <meta name="csrf-token"> o en un campo hidden de un formulario). En logs vas a ver una GET a la home del sitio o a cualquier página con un form, seguida casi inmediatamente de la POST maliciosa — la primera request es el "robo de token". IPs que hacen este patrón GET home → POST upload .php en menos de 1 segundo son candidatas a automatización de la cadena.
• Vendor advisory oficial: post en el foro de Joomlack del 27 de junio y página del producto con link al paquete 3.6.0. Cualquier parche que no venga de estos dominios debe tratarse como no oficial.
• Señal de persistencia operativa: archivos .htaccess o user.ini creados o modificados bajo /media/com_pagebuilderck/ entre el 27 de junio y la fecha de hoy; suelen ser intentos del atacante de asegurarse de que el motor PHP quede encendido en esa ruta aunque el admin lo desactive.

# Linux/bash: hunt IoCs del incidente en sitios Joomla
# 1) Web shells por nombre exacto o genéricos bajo com_pagebuilderck/
find /var/www -type d -path '*/media/com_pagebuilderck*' -print0 \
  | xargs -0 -I {} sh -c 'echo "=== {} ==="; \
      find "{}" -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" -o -name "*.pht" \) -printf "%p  %TY-%Tm-%Td %TH:%TM  %s bytes\n"'

# 2) Verificar versión de Page Builder CK instalada en cada sitio
for sitexml in $(find /var/www -name pagebuilderck.xml); do
  ver=$(grep -oP '(?<=<version>)[^<]+' "$sitexml" | head -1)
  echo "$sitexml  =>  $ver"
done | grep -vE '\b(3\.6\.0|3\.1\.13|4\.0\.5|3\.6\.1)$'

# Splunk SPL: cadena POST upload -> GET ejecución desde misma IP
index=apache OR index=nginx site=joomla
| rex field=uri "(?<endpoint>/components/com_pagebuilderck/[^?\"]+)"
| where method="POST" AND match(body, "\.php")
| rex field=clientip "(?<src>\d{1,3}(?:\.\d{1,3}){3})"
| stats count values(uri) AS uris BY src
| join type=left src
    [ search index=apache OR index=nginx site=joomla
      | rex field=uri "(?<shell>/media/com_pagebuilderck/.+\.php)"
      | stats values(uri) AS shell_hits BY clientip ]
| where count > 0 AND isnotnull(shell_hits)
| sort - count

# Suricata rule: POST con filename .php al endpoint vulnerable
alert http any any -> any any (msg:"JOOMLA PageBuilder CK unauth upload RCE attempt CVE-2026-56290";
    flow:to_server,established;
    http.method; content:"POST";
    http.uri; content:"/components/com_pagebuilderck"; nocase;
    http.content_type; content:"multipart/form-data"; nocase;
    http.request_body; content:"filename="; nocase;
    http.request_body; content:".php"; nocase;
    sid:2026562901; rev:1;)