Toma de control total de Postiz por cualquier usuario registrado (CVE-2026-115931, CVE-2026-115932, CVE-2026-115933)

Resumen

• Tres fallos críticos de Postiz, la aplicación de programación de publicaciones en redes sociales, están al alcance de cualquier usuario con una cuenta normal. Las llamadas sin restricciones a métodos de proveedores (CVE-2026-115931) y el recorrido de rutas multimedia (CVE-2026-115932) permiten leer cualquier archivo accesible para el backend, incluido el secreto de firma JWT, y provocar la caída del backend con una solicitud. La falsificación de tokens con secreto compartido (CVE-2026-115933) permite iniciar sesión como cualquier usuario o superadministrador de cualquier organización. El equipo de seguridad de Anthropic descubrió los tres; los avisos los califican con CVSS v3.1 9.9 (CVE-2026-115931), 9.6 (CVE-2026-115932) y 9.9 (CVE-2026-115933).
• El autorregistro está abierto en la configuración predeterminada, por lo que el atacante no necesita una cuenta previa, privilegios ni acciones de otras personas. Todas las instancias afectadas son autoalojadas. El repositorio tenía 37.856 estrellas GitHub y 7.395 bifurcaciones al redactar este artículo, un indicador aproximado del alcance de los despliegues.
• Los tres fallos se divulgaron el 23 de octubre de 2026 y se corrigieron en menos de un día: la versión 2.25.2 corrige la lectura de archivos (CVE-2026-115931), y 2.25.3 corrige la falsificación de tokens (CVE-2026-115933) y el recorrido de rutas multimedia (CVE-2026-115932).
• Actualice a 2.25.3 o posterior y después rote el secreto de firma JWT, las credenciales de base de datos y Redis y las claves de API de todos los proveedores conectados. Hasta actualizar, establezca DISABLE_REGISTRATION=true y bloquee POST /integrations/extension-refresh.

¿Estoy afectado?

Está afectado si aloja Postiz (el proyecto gitroomhq/postiz-app, normalmente desplegado desde sus imágenes Docker) y se cumple alguna de estas condiciones:

• Su instancia ejecuta 2.23.0 a 2.25.1, para las llamadas a funciones sin restricciones (CVE-2026-115931), corregidas en 2.25.2.
• Su instancia ejecuta 2.23.0 a 2.25.2, para el recorrido de rutas multimedia (CVE-2026-115932), corregido en 2.25.3. La versión 2.25.2 sigue afectada.
• Su instancia ejecuta 2.15.0 a 2.25.2, para los tokens firmados falsificados (CVE-2026-115933), corregidos en 2.25.3.

Compruebe qué versión despliega y si el autorregistro está abierto:

docker inspect --format '{{.Config.Image}}' $(docker ps -q --filter name=postiz)   # the image tag you run
docker compose config | grep -iE 'image:|DISABLE_REGISTRATION'                    # compose pin and the registration flag

Si descargó una etiqueta flotante latest antes del 24 de octubre de 2026, suponga que la instancia estaba afectada. El autorregistro está abierto salvo que DISABLE_REGISTRATION se establezca explícitamente en true; incluso con el registro cerrado, cualquier usuario existente puede explotar los tres fallos. Dos detalles de configuración condicionan las lecturas de archivos:

• El Dockerfile de desarrollo y el contenedor distribuido ejecutan el proceso como root, por lo que cualquier archivo legible por root está al alcance.
• La principal vía de entrega del recorrido de directorios requiere un proveedor Discord configurado, que el docker-compose distribuido deja vacío.

¿Cómo lo corrijo?

Actualice a Postiz 2.25.3 o posterior, que incorpora las tres correcciones, y reinicie el backend y el proceso de publicación:

1. Fije la imagen en v2.25.3 o posterior en su archivo compose y ejecute docker compose pull && docker compose up -d --force-recreate para recrear los contenedores con la compilación corregida.
2. Rote el secreto de firma JWT (la variable de entorno JWT_SECRET): con el secreto antiguo, un token falsificado antes de actualizar seguiría validándose. Rotarlo invalida todas las sesiones, invitaciones y tokens de restablecimiento de contraseña y empresariales a la vez.
3. Rote las credenciales de base de datos y Redis y las claves de API de todos los proveedores conectados, porque los avisos indican que el entorno que las contiene puede leerse mediante los fallos de lectura de archivos.
4. Revise la lista de usuarios en busca de cuentas que no haya creado y la de organizaciones en busca de superadministradores inesperados, dos rastros que puede dejar la toma de control.

Si no puede actualizar hoy, tres medidas reducen la exposición. Cada una tiene un límite indicado en los avisos:

• Establezca DISABLE_REGISTRATION=true. Elimina la entrada anónima, pero no protege contra usuarios existentes.
• Bloquee POST /integrations/extension-refresh en el proxy inverso si no utiliza canales que dependan de la extensión de navegador de Postiz. Elimina la principal ruta de firma para falsificación de tokens, pero deja la ruta más limitada de invitaciones.
• Deje sin configurar el identificador de cliente, el secreto de cliente y el token del bot de Discord. Elimina la principal vía de exfiltración del recorrido de directorios, pero deja sus otras dos rutas.

¿Cuál es la causa raíz?

Faltan tres comprobaciones independientes, una por fallo, todas en la gestión del backend de solicitudes de un usuario con sesión iniciada.

CVE-2026-115931: el backend ejecutaba métodos de proveedores por su nombre sin lista de permitidos. La ruta POST /integrations/function recibe un canal y un nombre de función e invoca esa función en el objeto proveedor, pasando el token almacenado del canal como primer argumento.

Antes de la corrección, solo se comprobaba que existiera en el objeto un método con ese nombre. El commit 9383f5be restringe la ruta a métodos registrados como @Tool o marcados con el nuevo decorador @DashboardFunction.

Una de las funciones auxiliares internas ahora bloqueadas lee un archivo cuya ruta llega en ese primer argumento, de modo que un canal cuyo token almacenado sea una ruta de archivo convierte el endpoint en un lector de archivos; otra función auxiliar termina el proceso backend.

-    // @ts-ignore
-    if (integrationProvider[body.name]) {
+    if (
+      this._integrationManager.isDashboardCallable(
+        integrationProvider,
+        body.name
+      )
+    ) {

CVE-2026-115933: un solo secreto de firma, ningún marcador de tipo de token y una ruta que firmaba datos de la solicitud. Postiz firma sus tokens de sesión, invitación, restablecimiento de contraseña y empresariales con un secreto compartido y no almacena en el token nada que indique de qué tipo es.

La ruta de actualización de credenciales de la extensión de navegador firmaba un payload JSON tomado de la propia solicitud y guardaba el resultado donde el usuario solicitante podía recuperarlo. Eso le daba un token con firma válida y los atributos que eligiera.

El commit a5affe62 deja de firmar los datos de la solicitud (AuthService.signJWT pasa a ser AuthService.fixedEncryption, «almacenado cifrado como hace connectSocialMedia, nunca firmado»). También añade discriminación de tipos de token. Cada ruta que consume tokens rechaza ahora payloads con campos de otro tipo de token, como timeLimit para invitaciones de equipo y expires para restablecimientos de contraseña.

CVE-2026-115932: se confiaba en que una ruta multimedia permaneciera dentro del directorio de cargas. Al publicar una entrada, Postiz trata una ruta multimedia que no es una dirección web como un archivo en disco. No comprueba que esté dentro del directorio de cargas.

Un usuario registrado podía guardar una ruta multimedia manipulada con una publicación y superar los controles que normalmente la restringen. El proceso de publicación leía después el archivo y lo enviaba como adjunto a un servidor Discord controlado por el usuario.

El commit 12db9bd2 rechaza nombres multimedia que contengan / o \, limita las lecturas del proceso al directorio de cargas y dirige las descargas de URL influidas por usuarios al mismo cliente HTTP protegido contra SSRF que utilizan los proveedores.

¿Cómo se explota?

Tres cadenas solo requieren una cuenta creada por autorregistro: lectura de archivos (CVE-2026-115931), toma de control por falsificación de tokens (CVE-2026-115933) y exfiltración multimedia (CVE-2026-115932). El informante demostró cada una de principio a fin contra una compilación sin modificar en el commit 3a7d28b7ad96:

• Lectura de archivos (CVE-2026-115931): registrarse, conectar un canal cuyo token almacenado sea una ruta de archivo, llamar a la función interna de lectura mediante POST /integrations/function y recibir el contenido como bytes. La demostración devolvió un archivo situado fuera de los directorios de la aplicación. También leyó el entorno del proceso: el secreto JWT con el que se inició el backend, la dirección de la base de datos, la cadena de conexión Redis y las credenciales de proveedores conectados.

• Toma de control (CVE-2026-115933): obtener mediante la ruta extension-refresh un token con firma válida y atributos elegidos. Después, presentarlo como uno de estos:

  • Una sesión de otro usuario. No necesita conocer su identificador. Los atributos del token se utilizan como filtro de base de datos, por lo que un objeto de filtro que coincida con otro usuario lo selecciona.
  • Una invitación a organización con rol de superadministrador para cualquier organización cuyo identificador exponga un enlace compartido de vista previa de publicación.
  • Un restablecimiento de contraseña de un usuario cuyo identificador conozca.
  • Un token de aprovisionamiento empresarial que conceda a una organización una suscripción de nivel superior de por vida.

  La demostración convirtió a un segundo usuario autorregistrado en superadministrador de la organización de otro usuario y leyó su clave de API. Los tokens falsificados no caducan y no pueden distinguirse de los auténticos. - Exfiltración (CVE-2026-115932): guardar una publicación cuya ruta multimedia apunte fuera del directorio de cargas, publicarla y recibir el archivo byte por byte como adjunto en el servidor Discord del atacante. Una segunda ruta revela si una ruta existe y puede agotar la memoria del backend apuntando a un archivo de dispositivo; una tercera alcanza la misma lectura en instancias con almacenamiento local.

¿Cómo se desarrolla el ataque?

Una cuenta autorregistrada en una instancia sin parchear lee el secreto de firma de sesiones y después inicia sesión como cualquier persona.

El fallo de falsificación de tokens llega al mismo resultado, iniciar sesión como cualquier usuario o superadministrador de cualquier organización, sin leer archivos. El recorrido de directorios consigue la misma lectura y envía el contenido a un servidor Discord controlado por el atacante.

¿Qué puede hacer un atacante?

Un atacante puede leer cualquier archivo que el backend pueda leer, iniciar sesión como cualquier usuario o superadministrador de cualquier organización, detener el backend con una solicitud y descifrar datos cifrados con el secreto compartido. El conjunto completo, según los impactos de los avisos:

• Leer cualquier archivo accesible para el proceso backend como bytes sin procesar, por lo que también funcionan los archivos binarios. En el contenedor distribuido que se ejecuta como root, son todos los archivos legibles por root, incluidos el archivo de entorno, los secretos montados y los registros de aplicación.
• Iniciar sesión como cualquier usuario, unirse a cualquier organización como superadministrador, leer su clave de API y lista de canales y programar publicaciones mediante sus cuentas sociales conectadas.
• Restablecer la contraseña de cualquier usuario cuyo identificador conozca.
• Crear una organización con suscripción de nivel superior de por vida mediante el endpoint empresarial.
• Detener el backend con una sola solicitud, repetible después de cada reinicio, mediante la función de caída (CVE-2026-115931) o la ruta de agotamiento de memoria (CVE-2026-115932).
• Descifrar datos que la aplicación almacena cifrados con el mismo secreto que la clave de firma JWT.

Las condiciones son una cuenta normal (el autorregistro la proporciona en una instancia predeterminada), acceso de red a la interfaz web de Postiz y, para la principal ruta de exfiltración, un proveedor Discord configurado. Ningún otro usuario tiene que hacer nada y no se necesitan privilegios adicionales a los de la cuenta.

¿Por qué funciona la corrección?

Cada corrección añade la comprobación ausente en lugar de limitarse a ocultar la ruta.

• Lista de permitidos para llamadas a funciones. Un nombre proporcionado por el solicitante solo puede alcanzar métodos declarados seguros para invocarse desde el panel. Ninguna función interna que lea archivos o termine el proceso es accesible por su nombre.
• Cifrado en lugar de firma. La ruta extension-refresh ahora cifra los datos de la solicitud en lugar de firmarlos, por lo que ya no puede entregar firmas válidas. La discriminación de tipos hace que un payload firmado solo sea aceptado por la ruta cuyo conjunto de campos coincida.
• Validación de rutas multimedia. Se rechazan nombres con separadores y las lecturas permanecen dentro del directorio de cargas, por lo que una publicación almacenada no puede dirigir al proceso de publicación fuera de él.

Las mismas correcciones cierran otras tres rutas más limitadas mencionadas en los avisos: la de firma de invitaciones, la de recorrido de directorios que revela si una ruta existe y puede agotar memoria, y la lectura de archivos en almacenamiento local.

¿Cómo compruebo si he sufrido una intrusión?

No se han publicado indicadores de compromiso para estos fallos ni se ha comunicado explotación en ataques reales. Realice estas comprobaciones frente a los impactos documentados:

• Revise la lista de usuarios de la instancia en busca de cuentas creadas por autorregistro que ningún administrador haya invitado, y la lista de miembros de cada organización en busca de superadministradores inesperados.
• Compruebe los canales conectados buscando aquellos cuyo token almacenado parezca una ruta de archivo en lugar de una credencial de proveedor: es la huella de la cadena de lectura de archivos.
• Inspeccione las publicaciones en busca de rutas multimedia que se resuelvan fuera del directorio de cargas y audite las entregas de webhooks Discord con archivos adjuntos que usted no haya enviado.
• Considere expuestos el secreto JWT, las credenciales de base de datos y Redis y las claves de API de todos los proveedores conectados si la instancia ejecutó una versión afectada y tenía registro abierto o al menos una cuenta de usuario, porque cualquier usuario autenticado puede alcanzar los fallos. Rótelos. Un token falsificado no puede distinguirse de uno auténtico por inspección, por lo que la rotación es la medida fiable.

Cronología

• 2026-10-23 17:45 UTC: Anthropic divulga CVE-2026-115932 y CVE-2026-115933 a Postiz con pruebas de concepto funcionales; Postiz reproduce ambos en 15 minutos.
• 2026-10-23 19:45 UTC: Anthropic divulga CVE-2026-115931 con una prueba de concepto funcional; Postiz lo reproduce y trabaja en las correcciones.
• 2026-10-23 21:33 UTC: Postiz publica y verifica la corrección de CVE-2026-115931.
• 2026-10-23 21:59 UTC: Postiz publica 2.25.2 con la corrección de CVE-2026-115931 y su aviso.
• 2026-10-24 12:26 y 13:27 UTC: Postiz publica y verifica las correcciones de CVE-2026-115932 y CVE-2026-115933.
• 2026-10-24 14:16 UTC: Postiz publica 2.25.3 con ambas correcciones y los avisos.
• 2026-10-26: este artículo.

Preguntas frecuentes

¿Se encadenan los tres fallos?

Sí, y cada uno también permite llegar por sí solo a la toma de control. La lectura de archivos (CVE-2026-115931) y el recorrido de directorios (CVE-2026-115932) exponen el secreto de firma JWT, y cualquiera que lo posea puede falsificar tokens válidos. La falsificación de tokens (CVE-2026-115933) produce directamente tokens con firma válida sin leer primero el secreto.

¿Está afectado el servicio alojado de Postiz?

Los avisos se refieren al repositorio autoalojado postiz-app y especifican sus versiones afectadas y corregidas. Para cualquier oferta gestionada, la exposición depende de la versión desplegada y los parches aplicados por el operador. En su propia instancia, compruebe qué imagen ejecutan los contenedores con docker inspect --format '{{.Config.Image}}' $(docker ps -q --filter name=postiz).

No podemos actualizar hoy. ¿Qué reduce más la exposición?

Cierre el autorregistro (DISABLE_REGISTRATION=true), bloquee POST /integrations/extension-refresh en el proxy inverso si no utiliza la extensión de navegador y deje sin configurar las credenciales del proveedor Discord. Cada medida elimina una ruta, pero ninguna elimina los fallos; los usuarios existentes siguen pudiendo explotar lo que quede abierto.

¿Qué hay que rotar después de actualizar?

Primero el secreto de firma JWT, porque los tokens falsificados antes de actualizar se validan hasta que cambie. Después, las credenciales de base de datos y Redis y las claves de API de todos los proveedores conectados, porque los avisos indican que el entorno que las contiene puede leerse. La invalidación de sesiones se deriva de rotar el secreto.

¿Hay una prueba de concepto pública?

No hay código publicado. Cada divulgación a Postiz incluía una prueba de concepto funcional y el informante demostró las tres cadenas de principio a fin contra una compilación sin modificar, pero los avisos describen el mecanismo sin publicar scripts. No se ha comunicado explotación en ataques reales.

¿Cómo se descubrieron?

El equipo de seguridad de Anthropic comunicó los tres. Enno Gelhaus coordinó la divulgación mediante GAdvisory. Nevo David los corrigió y cada corrección se verificó en cuestión de horas.

Referencias

• PSA-2026-JNXM56, aviso de CVE-2026-115931 con el vector CVSS v3.1 9.9, intervalo afectado, medidas provisionales, impactos demostrados y cronología: https://gadvisory.org/advisories/PSA-2026-JNXM56 (consultado el 26 de octubre de 2026)
• PSA-2026-YT2HMH, aviso de CVE-2026-115933 con el vector CVSS v3.1 9.9 y los impactos de toma de control: https://gadvisory.org/advisories/PSA-2026-YT2HMH (consultado el 26 de octubre de 2026)
• PSA-2026-E9AHFV, aviso de CVE-2026-115932 con el vector CVSS v3.1 9.6 y las condiciones de configuración por ruta: https://gadvisory.org/advisories/PSA-2026-E9AHFV (consultado el 26 de octubre de 2026)
• Avisos GitHub de los mismos tres fallos, GHSA-h5r5-h782-vqvp, GHSA-9j6f-8rw3-93c4 y GHSA-rmc2-p2gv-m88f: https://github.com/gitroomhq/postiz-app/security/advisories (consultado el 26 de octubre de 2026)
• Commits de corrección: 9383f5be (lista de métodos de proveedores permitidos, CVE-2026-115931), a5affe62 (cifrado en lugar de firma y discriminación de tipos de token, CVE-2026-115933) y 12db9bd (validación de rutas multimedia y confinamiento al directorio de cargas, CVE-2026-115932): https://github.com/gitroomhq/postiz-app/commit/9383f5be4d310c346e33a3748a9a7ded64c96fed, https://github.com/gitroomhq/postiz-app/commit/a5affe62c74e39c1e7ac960d50d8418b807d532c, https://github.com/gitroomhq/postiz-app/commit/12db9bd2f428b628a62809669c3d76297e07750a (consultado el 26 de octubre de 2026)
• Notas de Postiz 2.25.2, 23 de octubre de 2026, que resuelve PSA-2026-JNXM56: https://github.com/gitroomhq/postiz-app/releases/tag/v2.25.2 (consultado el 26 de octubre de 2026)
• Notas de Postiz 2.25.3, 24 de octubre de 2026, que resuelve PSA-2026-E9AHFV y PSA-2026-YT2HMH: https://github.com/gitroomhq/postiz-app/releases/tag/v2.25.3 (consultado el 26 de octubre de 2026)
• Repositorio de Postiz, cuyos recuentos de estrellas y bifurcaciones (37.856 y 7.395 el 26 de octubre de 2026) sirven de indicador del alcance de despliegues autoalojados: https://github.com/gitroomhq/postiz-app (consultado el 26 de octubre de 2026)