CVE-2026-40265 is a medium-severity (CVSS 5.9) CWE-862 vulnerability in github.com/enchant97/note-mark/backend. A fix is available for github.com/enchant97/note-mark/backend — see the affected versions and patch details below.
Note Mark has Broken Access Control on Asset Download
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-40265.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-40265 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/enchant97/note-mark/backendReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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
noteIDandassetID; no authentication is required - Attack complexity: High, because successful exploitation depends on prior disclosure of both UUIDs rather than feasible online guessing
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/enchant97/note-mark/backend | all versions | 0.0.0-20260411145023-6593898855adgo get github.com/enchant97/note-mark/backend@v0.0.0-20260411145023-6593898855ad |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/enchant97/note-mark/backend, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/enchant97/note-mark/backend to 0.0.0-20260411145023-6593898855ad or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-40265 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-40265 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-40265. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-40265 in your dependencies?
O3 Security finds CVE-2026-40265 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.