GHSA-P5W6-75F9-CC2P

Vulnerability from github – Published: 2026-04-13 19:31 – Updated: 2026-04-13 19:31
VLAI?
Summary
Note Mark has Broken Access Control on Asset Download
Details

Summary

A broken access control vulnerability allows unauthenticated users to retrieve note assets directly from the asset download endpoint when they know both the note UUID and asset UUID. This exposes the full contents of private note assets without authentication, even when the associated book is not public.

Details

The issue is caused by the asset download route being registered without authentication middleware.

Relevant route registration: - handlers/assets.go, line 40

huma.Get(api, "/api/notes/{noteID}/assets/{assetID}", h.GetNoteAssetContentByID)

By contrast, other asset operations correctly apply authentication middleware. For example:

huma.Delete(api, "/api/notes/{noteID}/assets/{assetID}", h.DeleteNoteAsset,
    huma.WithMiddleware(h.authMiddleware.AuthRequiredMiddleware))

The backend service for asset retrieval also does not enforce ownership or visibility checks. According to the provided code references, the lookup only queries the asset table by asset ID and note ID:

SELECT * FROM note_assets WHERE id = ? AND note_id = ?

Because the retrieval path does not join against the related notes or books records, it does not verify: - whether the requester owns the parent book - whether the parent book is public or private - whether the related note has been deleted

As a result, possession of a valid noteID and assetID is sufficient to retrieve the asset binary, regardless of whether the note belongs to a private book.

The exploitability is constrained by identifier knowledge. Both noteID and assetID are UUIDv4 values, so blind guessing is impractical. However, the endpoint remains vulnerable whenever those identifiers are disclosed through another channel, such as leaked links, browser history, proxy logs, shared URLs, or other application behaviors that expose internal asset references.

PoC

The issue can be reproduced by creating a private note with an attached asset, then requesting the asset download endpoint without authentication using the valid noteID and assetID. The server returns the asset content even though the associated note is private.

Impact

  • Type: Broken access control / unauthenticated information disclosure
  • Who is impacted: Any deployment exposing the affected asset download endpoint
  • Security impact: Full binary contents of private note assets can be disclosed to unauthenticated users who know the required identifiers
  • Attack preconditions: The attacker must know both the target noteID and assetID; no authentication is required
  • Attack complexity: High, because successful exploitation depends on prior disclosure of both UUIDs rather than feasible online guessing
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/enchant97/note-mark/backend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260411145023-6593898855ad"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40265"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-13T19:31:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA broken access control vulnerability allows unauthenticated users to retrieve note assets directly from the asset download endpoint when they know both the note UUID and asset UUID. This exposes the full contents of private note assets without authentication, even when the associated book is not public.\n\n### Details\nThe issue is caused by the asset download route being registered without authentication middleware.\n\nRelevant route registration:\n- `handlers/assets.go`, line 40\n\n```go\nhuma.Get(api, \"/api/notes/{noteID}/assets/{assetID}\", h.GetNoteAssetContentByID)\n```\n\nBy contrast, other asset operations correctly apply authentication middleware. For example:\n\n```go\nhuma.Delete(api, \"/api/notes/{noteID}/assets/{assetID}\", h.DeleteNoteAsset,\n    huma.WithMiddleware(h.authMiddleware.AuthRequiredMiddleware))\n```\n\nThe backend service for asset retrieval also does not enforce ownership or visibility checks. According to the provided code references, the lookup only queries the asset table by asset ID and note ID:\n\n```sql\nSELECT * FROM note_assets WHERE id = ? AND note_id = ?\n```\n\nBecause the retrieval path does not join against the related `notes` or `books` records, it does not verify:\n- whether the requester owns the parent book\n- whether the parent book is public or private\n- whether the related note has been deleted\n\nAs a result, possession of a valid `noteID` and `assetID` is sufficient to retrieve the asset binary, regardless of whether the note belongs to a private book.\n\nThe exploitability is constrained by identifier knowledge. Both `noteID` and `assetID` are UUIDv4 values, so blind guessing is impractical. However, the endpoint remains vulnerable whenever those identifiers are disclosed through another channel, such as leaked links, browser history, proxy logs, shared URLs, or other application behaviors that expose internal asset references.\n\n### PoC\nThe issue can be reproduced by creating a private note with an attached asset, then requesting the asset download endpoint without authentication using the valid `noteID` and `assetID`. The server returns the asset content even though the associated note is private.\n\n### Impact\n- **Type:** Broken access control / unauthenticated information disclosure\n- **Who is impacted:** Any deployment exposing the affected asset download endpoint\n- **Security impact:** Full binary contents of private note assets can be disclosed to unauthenticated users who know the required identifiers\n- **Attack preconditions:** The attacker must know both the target `noteID` and `assetID`; no authentication is required\n- **Attack complexity:** High, because successful exploitation depends on prior disclosure of both UUIDs rather than feasible online guessing",
  "id": "GHSA-p5w6-75f9-cc2p",
  "modified": "2026-04-13T19:31:57Z",
  "published": "2026-04-13T19:31:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/enchant97/note-mark/security/advisories/GHSA-p5w6-75f9-cc2p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/enchant97/note-mark/commit/6593898855add151eb9965d96998b05e14c62026"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/enchant97/note-mark"
    },
    {
      "type": "WEB",
      "url": "https://github.com/enchant97/note-mark/releases/tag/v0.19.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Note Mark has Broken Access Control on Asset Download"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…