Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-10T11:17:30.277Z",
  "pubdate": "2026-08-10T11:17:30.277Z",
  "executiveSummary": "An improper authorization vulnerability exists in daptin through v0.12.34, allowing unauthenticated remote attackers to perform full Create, Read, Update, and Delete (CRUD) operations on usergroup records.\nThe vulnerability stems from flawed permission validation logic within core authorization functions, which fails to properly handle null or zero-value user references when evaluating requests from unauthenticated guests.\nBecause usergroup table rows inherently lack a valid owner reference and load with a null owner, an unauthenticated user with a null session UserId successfully satisfies the broken conditional check.\nThis flaw exposes sensitive user group management interfaces to unauthorized external entities over the network without requiring any prior authentication or special privileges.\nThe resulting risk implications include complete loss of confidentiality, integrity, and availability concerning usergroup records, enabling malicious actors to manipulate group structures arbitrarily within the application data layer.",
  "technicalDetails": "The root cause of the vulnerability resides in the permission check functions (CanRead, CanPeek, CanCreate, CanUpdate, CanDelete, and CanRefer) located in server/permission/permission.go.\nThese functions evaluate access control by checking whether p.UserId equals the requesting userId, but they fail to explicitly reject null or zero-value references.\nBy contrast, the CanExecute function correctly implements a guard to handle null or zero-value checks, highlighting an inconsistency in authorization enforcement across the codebase.\nUsergroup table rows are stored without an associated user_account_id, resulting in records being loaded with a null owner during database queries.\nWhen an unauthenticated remote attacker sends HTTP requests to the application, their session UserId defaults to a null or zero value.\nThe vulnerable permission functions compare this null requesting userId against the null owner of the usergroup records, evaluating the conditional expression to true.\nConsequently, unauthenticated guest users bypass access controls entirely and are granted full CRUD access to all usergroup objects.\nAttackers can exploit this remotely over the network by issuing standard API requests targeting usergroup endpoints without supplying valid authentication credentials or session tokens.\nPost-exploitation impact includes the arbitrary creation of new administrative or privileged user groups, modification of existing group memberships, theft of sensitive group configuration data, and deletion of critical structural records leading to denial of service."
}