Si recibió un correo electrónico mío que le dirige a esta página, es porque su sitio web parece estar ejecutando una versión de iCagenda (el com_icagenda de JoomliC, una extensión de calendario de eventos para el sistema de gestión de contenidos Joomla) que está afectada por un problema de seguridad conocido. Esta página explica en qué consiste el problema, cómo comprobar si le afecta y cómo solucionarlo.

Este aviso trata sobre CVE-2026-48939, una vulnerabilidad crítica y explotada activamente que permite la carga de archivos arbitraria sin autenticación que conduce a la ejecución remota de código a través del formulario público «Enviar un evento» de la extensión. Se añadió al catálogo de vulnerabilidades explotadas conocidas de la Agencia de Seguridad de Ciberseguridad e Infraestructura de EE. UU. el 10 de julio de 2026.

Dos condiciones, y ambas deben cumplirse

Su sitio está afectado por el problema de ejecución remota de código cuando se cumplen ambas de estas condiciones:

  1. iCagenda está en la línea 4.0.x, en una versión anterior a 4.0.8 (es decir, de 4.0.0 a 4.0.7), y
  2. El núcleo de Joomla es anterior a 6.1.2.

Si iCagenda es 4.0.8 o posterior, no está afectado. Y si el núcleo de su Joomla es 6.1.2 o posterior, tampoco está afectado, incluso con una iCagenda antigua, porque el propio núcleo bloquea la carga. Si esa es la situación de su sitio, puede dejar de leer aquí, salvo por señalar que actualizar iCagenda sigue mereciendo la pena.

La segunda condición es la parte en la que esta página discrepa del propio aviso del proveedor, que afirma que el problema solo alcanza a los sitios que ejecutan Joomla 6. También alcanza a sitios con Joomla 4 y Joomla 5 completamente actualizados, y expongo la evidencia de ello más abajo, porque verá que el proveedor afirma lo contrario si sigue el enlace.

Si tiene una versión afectada, actualice iCagenda, y dado que esta vulnerabilidad fue explotada antes de que existiera una corrección, además compruebe en su sitio si hay indicios de que alguien llegó antes que usted (véase Si tenía una versión afectada más abajo).

Una nota para quienes tengan la línea 3.9.x, más antigua. El rango de CVE publicado incluye la 3.9.x, y el proveedor también corrigió esa línea, en la 3.9.15. Según mi propia lectura y pruebas, la línea 3.9.x utiliza una ruta de código distinta y protegida para la carga, por lo que el resultado de ejecución remota de código no es alcanzable ahí: en Joomla 4 y 5 la carga la bloquea el núcleo, y en Joomla 6 esa ruta de código ya ni siquiera existe, de modo que la función simplemente da un error. Eso no es motivo para ignorar la actualización. Las mismas versiones corrigen una comprobación de autorización ausente que permite a un visitante anónimo introducir un evento sin aprobar en su sitio (y, en Joomla 4 y 5, junto con él, un archivo de un tipo permitido). De menor gravedad, pero igualmente merece corregirse: actualice a 3.9.15 o posterior. Tenga en cuenta también que el proveedor solo ofrece parches de seguridad para la línea 3.9.x hasta el 13 de octubre de 2026.

¿Es legítimo este mensaje?

Sí. Este es un aviso de divulgación responsable y de buena fe de un investigador de seguridad independiente. Yo no le pido dinero, contraseñas ni acceso a su sitio, y no he intentado infiltrarme en él, subir nada ni explotar nada.

Lo que leí fueron dos archivos públicos que su sitio sirve a cualquiera que los solicite: el manifiesto del componente iCagenda en /administrator/components/com_icagenda/icagenda.xml, y el manifiesto del núcleo de Joomla en /administrator/manifests/files/joomla.xml. Ambos son simples archivos XML de versión, y son los mismos dos archivos descritos en Cómo comprobar sus versiones más abajo, de modo que puede ver exactamente lo que yo vi. Eso es todo. En concreto, no envié su formulario de evento, no subí nada, y no solicité el directorio de adjuntos de su sitio. Esa ruta aparece más adelante en esta página únicamente como un lugar para que usted mire en su propio sitio. Nada de esta comprobación toca sus datos, su área de administración ni ninguna parte privada de su sitio.

Si desea verificar quién soy, consulte los datos de contacto al final de esta página y la página Acerca de.

Por qué importa

iCagenda publica un calendario de eventos en sitios Joomla. Una de sus funciones permite a un visitante enviar un evento a través de un formulario público, adjuntando opcionalmente un archivo, que se guarda en images/icagenda/frontend/attachments/.

En las versiones afectadas, ese envío se acepta sin iniciar sesión, y el adjunto se escribe en disco sin ninguna comprobación de qué tipo de archivo es, conservando el nombre y la extensión que eligió quien lo envió. Esa combinación permite a un atacante colocar en su servidor un programa de su elección y ejecutarlo: ejecución remota de código completa, sin necesidad de cuenta ni de cooperación alguna por su parte.

No hace falta activar nada para que esto se aplique. El formulario no tiene que estar publicado ni visible para los visitantes: en las versiones afectadas, el controlador que hay detrás aceptaba el envío de todos modos.

Este no es un riesgo teórico. Recibe una puntuación de 9,8 sobre 10 según NVD (y 10,0 según la autoridad asignadora con el sistema de puntuación más reciente), y está siendo explotado en la práctica. El proveedor informa de que la explotación comenzó el 15 de junio de 2026 a las 08:00 UTC, antes de que existiera el parche, y describe los ataques como automatizados. CISA lo añadió al catálogo de vulnerabilidades explotadas conocidas el 10 de julio de 2026.

Estoy describiendo esto al nivel que necesita un propietario de sitio para actuar, y no más. No estoy publicando los detalles que permitirían a alguien reproducirlo, y le pediría que no intente hacerlo contra su propio sitio ni contra el de nadie más. Leer sus dos números de versión, como se describe más abajo, le dice todo lo que necesita para decidir qué hacer.

Si mi correo electrónico citaba este problema, significa que las versiones que informa su sitio lo sitúan dentro del rango afectado en ambos aspectos. No probé si su sitio en particular es explotable ni si ya está comprometido.

En qué difiere esta página del aviso del proveedor

El aviso del proveedor merece la pena leerse y lo enlazo más abajo. Publicaron una corrección rápidamente y su orientación es buena. Pero una frase de alcance en él no se sostiene, y como es la frase que le diría a la mayoría de los lectores de esta página que se relajen, quiero mostrar mi razonamiento en lugar de limitarme a afirmarlo. El aviso dice:

Las cargas de archivos no seguras ya estaban bloqueadas por defecto en todas las versiones de Joomla anteriores a Joomla 6. Solo la instalación de iCagenda en Joomla 6 (6.0.0-6.1.1) tenía la vulnerabilidad crítica de carga.

Esto es lo que medí, en instalaciones aisladas propias. Ningún sitio de terceros estuvo implicado en ningún momento.

  • iCagenda 4.0.x realiza la carga a través de la clase del framework Joomla\Filesystem\File, que procede del paquete joomla/filesystem que incluye el núcleo de Joomla. No utiliza la clase más antigua de Joomla CMS con el mismo nombre, que es la que siempre ha llevado una comprobación de archivo seguro y es presumiblemente la que el aviso tiene en mente.
  • Ese método del framework solo obtuvo su propia comprobación de archivo seguro (el parámetro $allowUnsafe y la prueba isSafeFile) en joomla/filesystem 4.2.0, que es la versión que se incluye con Joomla 6.1.2.
  • Las versiones realmente incluidas en los lanzamientos de Joomla que comprobé: Joomla 4.4.14 incluye filesystem 2.0.2 (sin comprobación), Joomla 5.4.7 incluye 3.2.0 (sin comprobación), y Joomla 6.1.2 incluye 4.2.0 (comprobación presente).

Por lo tanto, un sitio con Joomla 4 o Joomla 5 completamente parcheado que ejecute iCagenda de 4.0.0 a 4.0.7 sí está expuesto, y por eso esta página formula la condición de Joomla como «anterior a 6.1.2» en lugar de «solo Joomla 6». Nada en el registro de CVE publicado, en la entrada de NVD ni en el catálogo de CISA acota este problema por versión de Joomla en absoluto; la frase del aviso es el único lugar donde aparece tal límite.

Cómo comprobar sus versiones

No tiene que tomar mi palabra para ninguno de los dos números, y hay dos que comprobar.

Su versión de iCagenda, desde el archivo de manifiesto (no se necesita inicio de sesión): abra

yourdomain.com/administrator/components/com_icagenda/icagenda.xml

y lea su elemento <version>. Ese es uno de los dos archivos que leí.

Su versión de iCagenda, desde el área de administración:

  1. Inicie sesión en su administrador de Joomla (normalmente en yourdomain.com/administrator).
  2. Vaya a Sistema luego Gestionar luego Extensiones.
  3. Busque iCagenda y anote la versión instalada.

Preste atención a qué icagenda.xml lee. El paquete de iCagenda también incluye un plugin de búsqueda empaquetado con un manifiesto del mismo nombre, que lleva su propio número de versión sin relación con el anterior. Solo la ruta del componente indicada arriba le dice qué versión está ejecutando la extensión.

Su versión del núcleo de Joomla: en el administrador, vaya a Sistema luego Información del sistema. O lea /administrator/manifests/files/joomla.xml y tome su elemento <version>. Ese es el otro archivo que leí.

No hay forma de saber la versión de iCagenda a partir del código fuente público de su página, y no debería intentarlo. Los recursos de front-end de la extensión llevan el hash de medios de todo el sitio de Joomla en lugar de un número de versión, y el único número con forma de versión que sí aparece en el código fuente de la página pertenece al paquete de recursos del módulo del calendario (un número bajo, como 1.0.4) y no tiene nada que ver con el componente. El archivo de manifiesto o la pantalla del administrador son la única comprobación fiable.

A continuación, aplique la regla del principio de esta página: la línea 4.0.x anterior a 4.0.8 y un núcleo anterior a 6.1.2 significa que está afectado.

Cómo actualizar

La vía más segura es actualizar a través del propio Joomla, y hacer antes una copia de seguridad:

  1. Haga una copia de seguridad de su sitio (archivos y base de datos) antes de realizar cambios. La mayoría de los proveedores de alojamiento ofrecen copias de seguridad con un solo clic, o use una extensión de copia de seguridad de Joomla.
  2. En la administración de Joomla, abra Extensiones luego Gestionar luego Actualizar y haga clic en Buscar actualizaciones. Si aparece una actualización de iCagenda, instálela desde aquí.
  3. Si no aparece ninguna actualización allí, descargue la versión actual directamente del proveedor, JoomliC, e instálela mediante Extensiones luego Instalar.
  4. Qué versión instalar: la 4.0.8 es el lanzamiento que corrige este problema, pero el lanzamiento actual en el momento de escribir esto es la 4.0.11, y los lanzamientos posteriores a 4.0.8 añaden protección adicional en torno a la misma función, incluido el bloqueo de la ejecución de código desde la carpeta de medios de iCagenda. Vaya a la 4.0.11 en lugar de quedarse en la 4.0.8. En la línea más antigua, vaya a la 3.9.15 o posterior.
  5. Alternativamente, actualizar el núcleo de Joomla a 6.1.2 o posterior también cierra este problema en concreto, pero no sustituye a actualizar la extensión: la comprobación de autorización ausente está en la propia iCagenda, y solo una actualización de iCagenda la corrige.
  6. Después de actualizar, confirme el nuevo número de versión utilizando los pasos anteriores, y compruebe que su calendario sigue mostrándose y que el envío de eventos sigue funcionando como espera.

Ya que está en ello, conviene confirmar que el propio Joomla y sus demás extensiones están actualizados, ya que el mismo principio se aplica a todos ellos.

Si tenía una versión afectada

Dado que esta vulnerabilidad fue explotada antes de que hubiera una corrección disponible, un sitio que ejecutó una versión afectada no debería suponer que actualizar es suficiente. Actualizar cierra la puerta, pero no le dice si alguien ya había entrado por ella. Vale la pena comprobarlo con calma en lugar de suponer lo peor: la mayoría de los sitios no encontrarán nada. En palabras del propio proveedor:

La actualización cierra el punto de entrada y protege la función de adjuntos de archivos, pero no limpia un sitio ya comprometido. […] Conserve una copia de los archivos sospechosos como prueba, elimínelos, cambie sus contraseñas y credenciales de Joomla, y audite todo su sitio, no solo la carpeta de iCagenda.

Esto es lo que usted (o su webmaster) puede buscar en su propio sitio:

  • Archivos PHP en images/icagenda/frontend/attachments/. Esa carpeta solo debería contener adjuntos de eventos. En un servidor Linux, la comprobación es:

    find images/icagenda/frontend/attachments -name '*.php' -type f
  • Eventos anónimos sin aprobar en su cola de moderación, algo que no esperaría si nunca abrió el envío de eventos al público.
  • Peticiones en sus registros de acceso de un escáner que se identifica como icagenda-batch/1.0.

Desde la 4.0.8 en adelante, iCagenda también comprueba por sí misma si hay indicios de compromiso y muestra una alerta después de actualizar si encuentra alguno. El proveedor es claro en que la ausencia de esa alerta no es una garantía, así que se trata de una señal útil, no de un certificado de que todo está bien.

Si encuentra alguno de estos indicios, trate el sitio como comprometido: conserve copias de los archivos sospechosos como prueba y luego elimínelos, rote todas las credenciales (administrador de Joomla, base de datos, FTP/SSH, panel de alojamiento), revise sus cuentas de usuario de Joomla y los grupos a los que pertenecen, y audite todo el sitio, no solo la carpeta de iCagenda. Restaurar desde una copia de seguridad anterior al 15 de junio de 2026 suele ser más seguro que limpiar in situ, porque una puerta trasera que haya quedado puede deshacer la limpieza. Si su organización tiene un equipo de seguridad informática o un CERT nacional, avíselos.

Quiero ser claro: no he comprobado su sitio en busca de ninguno de estos indicadores, y no sé si su sitio se vio afectado. Esta lista está aquí para que usted mismo pueda comprobarlo.

No tengo webmaster / estoy atascado

Si usted no es la persona que mantiene el sitio, por favor reenvíe esta página a quien lo haga (su desarrollador web, agencia o proveedor de alojamiento). Reconocerán rápidamente los pasos anteriores.

Si usted está manteniendo el sitio usted mismo y se queda atascado, estoy encantado de ayudarle a orientarse en la dirección correcta sin costo alguno. Póngase en contacto utilizando los datos de contacto que aparecen a continuación.

Contacto

Evan Harris, investigador de seguridad

Me pongo en contacto sobre problemas como este puramente para ayudar a los operadores a asegurar sus sitios. Si prefiere no ser contactado de nuevo, simplemente hágamelo saber y lo respetaré.

Referencias

Avisos oficiales y seguimiento

Proveedor (JoomliC)