Nextcloud Collectives EUVD-2026-111130

Exploitation requires that a collective be shared as a public link (the 'public shared collective' deployment mode); any recipient who possesses that link can then create pages in the collective, because the link-recipient role was always granted page-creation rights regardless of intent. Limiting factors: the attacker must obtain the public share link (not published to the open internet by default), only Collectives version 4.0.0 is listed as affected, and the impact is confined to creating pages (low integrity) - there is no stated confidentiality exposure or availability/deletion impact. No active exploitation is confirmed.

This is a low-severity access-control issue (CVSS 3.0 base 3.5, vector AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N) in Nextcloud Collectives, with only a low integrity impact and no confidentiality or availability impact - the sole effect is that recipients of a public share link could create pages they should not have been able to create (CWE-284, improper access control). The vuln.today decision label is 'monitor', which aligns with the low severity: this is not an act_now/emergency situation. The signals are mostly consistent and point to low real-world priority: there is no CISA KEV listing (not confirmed actively exploited), and no EPSS exploitation-probability score was supplied in the input, so widespread-exploitation likelihood cannot be quantified from the data. A HackerOne report (reports/3533697) and a VulDB advisory are referenced, but these are references rather than confirmed working exploit code. The 'Authentication Bypass' tag somewhat overstates the mechanism - the flaw is an authorization/access-control weakness (unwanted page-creation privilege for link recipients), not a bypass of authentication - so defenders should read this as an unauthorized-write issue limited in blast radius, not a full account-takeover primitive.

An organization shares a collective publicly via link intending recipients to only view or read content. Because Collectives 4.0.0 always granted link recipients page-creation rights, any person holding the public link can open the shared collective and create new pages within it, injecting unwanted or misleading content. A public PoC reference exists (HackerOne report 3533697); it is not verified as working exploit code.