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

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

Which versions of Daptin are affected by CVE-2026-72575?

An authorization bypass in Daptin through v0.12.34 allows unauthenticated attackers to read, modify, and delete all usergroup and permission records on the platform, though no public exploit has been…

How to fix or mitigate CVE-2026-72575?

Immediately create an inventory of all Daptin deployments running v0.12.34 or earlier and isolate them from untrusted networks using firewall rules or VPN-only access within 24 hours. Over the next seven days, implement network segmentation, enable comprehensive audit logging for all usergroup and permission operations, review access logs for anomalous changes, and restrict usergroup management APIs to named internal users only. Establish continuous monitoring for Daptin security advisories and plan to upgrade to patched versions immediately upon vendor release, then conduct a full forensic audit of usergroup and permission objects to detect and remediate any unauthorized modifications introduced during the unpatched period.

Daptin CVE-2026-72575

EUVD-2026-55231 CRITICAL

Improper Access Control (CWE-284)

2026-08-10 TuranSec

GHSA-w34h-746p-3wp3

Authentication Bypass Daptin

9.1

CVSS 3.1 · Vendor: TuranSec

Severity by source

Vendor (TuranSec) PRIMARY

9.1 CRITICAL

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

vuln.today AI

9.1 CRITICAL

Unauthenticated network access with no interaction (AV:N/AC:L/PR:N/UI:N); full read plus create/update/delete of usergroup data gives C:H and I:H, with no DoS impact so A:N.

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

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

Primary rating from Vendor (TuranSec).

CVSS VectorVendor: TuranSec

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Aug 10, 2026 - 11:21 vuln.today

CVE Published

Aug 10, 2026 - 10:41 cve.org

CRITICAL 9.1

DescriptionCVE.org

An improper authorization vulnerability in daptin through v0.12.34 allows unauthenticated remote attackers to read, create, update, and delete usergroup records. The permission check functions (CanRead, CanPeek, CanCreate, CanUpdate, CanDelete, CanRefer) in server/permission/permission.go return true whenever p.UserId equals the requesting userId, but fail to reject the null/zero reference - unlike CanExecute, which explicitly guards it. Since usergroup table rows have no user_account_id and are loaded with a null owner, an unauthenticated guest whose session UserId is null gains full CRUD access to all usergroup objects.

AnalysisAI

Improper authorization in Daptin through v0.12.34 lets unauthenticated remote guests perform full CRUD (read, create, update, delete) on all usergroup records, effectively bypassing access control on the platform's group and permission objects. The flaw arises because permission checks treat a null/zero UserId as a valid ownership match, so a guest whose session UserId is null is granted owner-level rights over ownerless usergroup rows. No public exploit identified at time of analysis, but the CVSS of 9.1 (network, no auth, no interaction) reflects that manipulating usergroups can be leveraged to escalate privileges and corrupt the platform's authorization model.

Technical ContextAI

Daptin is an open-source, Go-based headless backend/BaaS that auto-generates REST/GraphQL APIs and enforces per-record access through a permission layer in server/permission/permission.go. This is a CWE-284 (Improper Access Control) root cause: the check functions CanRead, CanPeek, CanCreate, CanUpdate, CanDelete, and CanRefer return true whenever the record owner p.UserId equals the requesting userId. Unlike CanExecute, which explicitly rejects the null/zero reference, these functions omit that guard. Because usergroup table rows carry no user_account_id and are loaded with a null owner, the comparison null-owner == null-session-user evaluates as a legitimate ownership match, collapsing the intended authorization boundary. The affected component is identified by CPE cpe:2.3:a:daptin:daptin:*.

RemediationAI

No vendor-released patch identified at time of analysis; the references point only to the Daptin repository and the affected permission.go source file, not to a tagged patched release, so no exact fix version can be cited from the input. The correct code-level fix mirrors CanExecute: update CanRead, CanPeek, CanCreate, CanUpdate, CanDelete, and CanRefer in server/permission/permission.go to explicitly reject the null/zero UserId reference before treating an owner match as valid, then rebuild and redeploy. Until an upstream release is available, apply compensating controls: place the Daptin API behind an authenticating reverse proxy or gateway so anonymous/guest sessions cannot reach usergroup endpoints (trade-off: breaks any intended public/guest API access); restrict network exposure to trusted internal networks or VPN instead of the public internet; and monitor for unexpected create/update/delete operations against usergroup records. Track https://github.com/daptin/daptin for a patched release and upgrade immediately once published.