What is the CVSS score of CVE-2026-71234?

CVE-2026-71234 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.3%.

Which versions of Documize Community are affected by CVE-2026-71234?

Documize Community contains an unauthenticated file access vulnerability enabling remote attackers to bypass access controls and download all organizational documents without credentials.

How to fix or mitigate CVE-2026-71234?

Within 24 hours, immediately assess the scope of sensitive documents stored in affected Documize instances and implement emergency network-level access controls (such as IP whitelisting, VPN requirement, or reverse proxy authentication) to block unauthenticated attachment downloads while assessment proceeds. Within 7 days, contact the Documize vendor to obtain a confirmed patch timeline and begin technical evaluation of alternative document management platforms as contingency; simultaneously pull and analyze Documize access logs for suspicious file downloads to quantify exposure. Within 30 days, either deploy a vendor security patch if released or complete a controlled migration to a supported alternative platform, ensuring all potentially compromised documents are reviewed for data sensitivity and re-secured under proper access controls.

Documize Community CVE-2026-71234

EUVD-2026-53307 HIGH

Incorrect Authorization (CWE-863)

2026-08-05 309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c

GHSA-4gcg-395p-mg6g

Authentication Bypass

7.5

CVSS 3.1 · Vendor: 309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c

Severity by source

Vendor (309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

vuln.today AI

7.5 HIGH

Network-reachable route with no auth middleware (PR:N, AV:N); trivial single-parameter bypass (AC:L); confidentiality-only impact with no write or availability effect (I:N, A:N).

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c).

CVSS VectorVendor: 309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Analysis Generated

Aug 05, 2026 - 11:34 vuln.today

CVE Published

Aug 05, 2026 - 11:16 cve.org

HIGH 7.5

DescriptionCVE.org

Documize Community's attachment download route (domain/attachment/endpoint.go, Download function, registered via AddPublic with no auth middleware) accepts a secure query parameter and grants access whenever the parameter is simply non-empty (len(secureToken) > 0), without comparing it to any server-stored value. Any non-empty string, such as ?secure=x, bypasses authentication entirely and allows downloading any organization's attachments. Sibling handlers in the same file (togglePublish, delete) correctly enforce session-based authorization, confirming this is an inconsistency rather than intended design.

AnalysisAI

Unauthenticated attachment download in Documize Community exposes all organization files to any remote attacker via a trivially bypassable token check. The Download handler in domain/attachment/endpoint.go, registered via AddPublic without auth middleware, validates the secure query parameter only by checking that it is non-empty (len(secureToken) > 0) rather than comparing it to a server-stored secret - meaning any request with ?secure=x succeeds. Notably, sibling handlers in the same file (togglePublish, delete) enforce proper session-based authorization, confirming this is an implementation inconsistency rather than deliberate design. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis, but the attack requires no authentication, no special tools, and trivial construction.

Technical ContextAI

Documize Community is an open-source wiki and document management platform written in Go. The vulnerability resides in the HTTP handler registered for the attachment download route via AddPublic, a registration helper that intentionally omits authentication middleware - appropriate for genuinely public resources but misapplied here. The Download function accepts a secure query parameter intended to act as a capability token (a shared secret embedded in a link), but the only validation is len(secureToken) > 0, which passes for any non-empty string. CWE-863 (Incorrect Authorization) precisely classifies this: the authorization check exists in code but does not perform the correct verification step - comparing the submitted token against a server-side stored or computed value. This contrasts with CWE-862 (Missing Authorization), where no check exists at all. The root cause is a logical error in the conditional: a stub or placeholder check was never completed with the actual token comparison logic.

RemediationAI

The definitive fix requires replacing the len(secureToken) > 0 check in the Download function (domain/attachment/endpoint.go) with a constant-time comparison against the server-stored or server-computed secure token value associated with the attachment, consistent with how sibling handlers enforce authorization. No vendor-released patch or fixed version has been identified at time of analysis; the only reference is the upstream GitHub repository at https://github.com/documize/community, which should be monitored for a corrective commit or tagged release. As a compensating control pending a patch, administrators should restrict network access to the attachment download route at the reverse-proxy or firewall layer - for example, blocking external access to the /attachment/ path prefix for internet-facing deployments, accepting that this will break legitimate public attachment sharing. Alternatively, if public attachment sharing is not required, reconfiguring the route to require session authentication (consistent with togglePublish and delete handlers in the same file) eliminates the exposure without network-layer controls. Note that blocking the route at the network layer does not fix the underlying code defect and must be revisited after patching.