Resumen
En la app Collectives de Nextcloud, un colectivo puede configurarse para que solo sus administradores modifiquen el contenido. Para ello se combinan dos ajustes:
- Permissions → Allow editing for =
Admins only - Page settings → Default page mode =
View
Con esa configuración, quien accede mediante un enlace público compartido (aunque el enlace se haya creado con permiso de edición) ve el colectivo en modo solo lectura: la interfaz no ofrece ninguna opción para crear ni editar páginas.
El problema es que esa restricción solo se aplicaba en la interfaz. El endpoint de la API que crea páginas a través de un enlace público no comprobaba la política de edición del colectivo:
POST /ocs/v2.php/apps/collectives/api/v1.0/p/collectives/<shareToken>/pages/<parentPageId>
Por tanto, una persona que no era miembro y entraba con el enlace podía crear páginas nuevas enviando la petición a mano. Es un fallo de control de acceso (debilidad en HackerOne: Improper Access Control - Generic). El investigador aclara que este endpoint es distinto del que trataba otro reporte suyo, el #3530164.
Pasos de reproducción
- El usuario A crea un colectivo nuevo.
- En la configuración del colectivo, el usuario A fija:
- Permissions → Allow editing for =
Admins only - Page settings → Default page mode =
View
- El usuario A genera un enlace público para compartir el colectivo, con el permiso de edición activado.
- Alguien que no es miembro del colectivo abre ese enlace. La interfaz respeta la configuración: solo permite leer y no muestra opciones para crear ni editar páginas.
- Esa misma persona envía directamente esta petición a la API:
POST /ocs/v2.php/apps/collectives/api/v1.0/p/collectives/<shareToken>/pages/<parentPageId>
Content-Type: application/json
{
"title": "hacker",
"parentId": <parentPageId>,
"templateId": null
}
- El servidor contesta
HTTP 200 OKy la página aparece creada dentro del colectivo.
Según el investigador, si no se consigue reproducir hay que enviar la petición con las cookies de sesión de otro usuario autenticado (uno que no sea el propietario del colectivo), no sin autenticar ni desde una sesión sin iniciar.
Impacto
El administrador del colectivo había configurado expresamente que solo los administradores pudieran escribir. Aun así, quien tuviera el enlace público podía crear páginas nuevas, es decir, añadir contenido y cambiar la estructura del colectivo sin permiso. Así, la configuración que el administrador creía que protegía el colectivo no se cumplía en el backend, y la interfaz y la API aplicaban permisos diferentes.
En HackerOne el reporte figura con severidad baja.
Remediación
Nextcloud marcó el reporte como resuelto y pagó una recompensa (el importe no se ha hecho público). El fallo se describe en el aviso de seguridad GHSA-qwm4-h3xh-gmvc. El reporte no detalla el cambio en el código.
Cronología: el reporte se envió el 1 de febrero de 2026 y se divulgó el 17 de septiembre de 2026.