Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach Corteza compose attachment endpoint
-
DeliveryObtain target private attachment ID
-
ExploitRequest original/preview route with kind=page/icon/namespace
-
ExecutionSignature check bypassed on stored attachment
-
ImpactDownload private file cross-namespace
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires that the attacker know a valid private attachment ID (a Corteza record or module compose attachment id) and then request the original or preview serving route with the URL 'kind' path segment set to a public kind - 'page', 'icon', or 'namespace' - which causes the isAccessible() logic to treat the request as a public-kind attachment and skip the token/signature verification that would normally gate the private file. No authentication, token, or signature is needed (PR:N) and no user interaction is involved. The principal limiting factor, reflected as AT:P in the CVSS 4.0 vector, is that the attachment id must be known or guessed (Corteza uses large uint64 identifiers, so blind enumeration is non-trivial); exploitation is further limited to Corteza deployments at or below version 2024.9.10 that expose the compose attachment endpoints. |
| Impact | The vendor-supplied CVSS 4.0 base score of 8.2 (High) is driven by a network-reachable (AV:N), low-complexity (AC:L), unauthenticated (PR:N) path to high confidentiality impact (VC:H) with no user interaction, tempered only by Attack Requirements being present (AT:P). That AT:P is the key nuance: exploitation is not fully spray-and-pray because the attacker must know a valid private attachment ID, which the description explicitly states ('Attackers who know a private record or module attachment id...'). The source diff confirms the root cause - isAccessible() trusted the request-supplied 'kind' segment instead of the stored attachment's kind, so declaring kind=page/icon/namespace skipped the signature check entirely - making this a confirmed, well-understood authorization flaw (CWE-863) rather than a speculative one. No EPSS score was provided in the input, the CVE is not listed in CISA KEV, and no public exploit was flagged, so there is no evidence of active or widespread exploitation at this time. On balance this is a genuine priority for any organization actually running Corteza (unauthenticated cross-tenant data disclosure with a vendor patch available), but the real-world blast radius is constrained by the need to know/guess attachment IDs and by Corteza's relatively limited deployment footprint, so it is less urgent than a comparable flaw in ubiquitous software. |
| Exploit ScenarioDerived | An unauthenticated attacker who has learned a private attachment ID (for example a record or module attachment belonging to another namespace) sends a GET to the compose attachment original or preview route while setting the URL kind segment to 'page', 'icon', or 'namespace'. Because the vulnerable code validated access against the attacker-controlled kind rather than the attachment's stored kind, the signature/token check is skipped and the private file is returned, crossing namespace and record permission boundaries. No public exploit was flagged in the input, though a detailed technical write-up (hackmd) describing the kind-confusion technique is referenced. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 11, 2026
Unauthenticated attackers can download private Corteza compose attachments by rewriting the 'kind' path segment of the original or preview serving route to 'page', 'icon', or 'namespace', which makes the platform's isAccessible() check treat the private file as a public-kind attachment and skip the token/signature verification that would normally gate it. Deployments at or below Corteza 2024.9.10 that expose the compose attachment endpoints are affected, and an attacker only needs to know or guess a valid private record or module attachment ID - that requirement is reflected as Attack Requirements: Present (AT:P) in the vendor's CVSS 4.0 score of 8.2 (High), while the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Per available intelligence there is no CISA KEV entry and no public exploit identified at time of analysis, though a public technical write-up of the attachment kind-confusion technique is referenced; EPSS data was not supplied. The impact is confidentiality-only - high-volume unauthorized reads of files across namespace and record permission boundaries - with no integrity or availability effect reported.
RemediationAI
The primary fix is the vendor-supplied patch; upstream fix available (commit 3b68aa30c7261f729fcf8202f3eab9cf7d9168d3, referenced as a patch in the advisory data), which enforces that the requested kind matches the stored attachment Kind and re-verifies signatures against the attachment's own namespace and ID - released patched version beyond 2024.9.10 was not independently confirmed in the supplied data, so treat the commit as the authoritative fix reference and confirm the corresponding tagged release with the vendor before upgrading. If an immediate upgrade is not possible, the most effective compensating control is to stop unauthenticated reachability of the compose attachment serving routes at the reverse proxy or API gateway - block or require authentication on GET requests to the attachment original/preview paths (including the page, icon, and namespace kind variants) - with the trade-off that genuinely public page and icon attachments will stop rendering for anonymous visitors and embedded links may break. Alternatively, restrict the entire Corteza compose endpoint surface to trusted networks or VPN users, which reduces exposure but does not fix the underlying authorization logic and leaves insiders unconstrained. Because exploitation hinges on knowing a valid attachment ID (large uint64 values that are hard to blind-enumerate), there is no practical configuration change that removes the risk, and logging or alerting on attachment reads with mismatched kinds is only detective. Deploy the patch, then review exposure using the VulnCheck advisory and the referenced write-up to validate that private record and module attachments can no longer be retrieved without a valid token or signature.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Corteza is an open-source low-code platform written in Go, and the vulnerable subsystem is its 'compose' module, which stores and serves record, module, page, icon, and namespace attachments. Its attachment REST controller (server/compose/rest/attachment.go) exposes original and preview serving routes whose URL includes a 'kind' segment and an attachment ID; the handler passed that request-supplied kind into isAccessible(), and because the public kinds - page, icon, and namespace - bypass the signature branch, an unauthenticated caller could reach private files by simply mislabelling the kind. The root cause is CWE-863 (Incorrect Authorization): an authorization decision made on attacker-controlled input (the request kind) rather than on the trust-relevant attribute of the stored object, meaning the attachment's real Kind and its namespace/record ACLs were never consulted on the serving path. The referenced upstream fix (commit 3b68aa30c7261f729fcf8202f3eab9cf7d9168d3) addresses this by introducing service.FindForServing(), which deliberately loads an attachment without an access-control check and documents that the caller must verify the signature, and by changing isAccessible() to take the loaded *types.Attachment so that att.Kind - not the request kind - decides whether a signature is required; signature verification is then bound to the attachment's own NamespaceID and ID via auth.DefaultSigner.Verify. Read, Delete, and Icon handlers were additionally changed to return NotFound when a.Kind does not match the requested kind, and the same commit corrects inverted namespace/page/record access checks in the service-level Find() listing path.
Know when Corteza gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable unauthenticated read (AV:N/PR:N) with no UI; CVSS 3.1 lacks an Attack-Requirements metric, so the need-to-know attachment ID is noted separately rather than as AC:H; impact is confidentiality-only (C:H, I/A:N).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Corteza through 2024.9.10 contains an incorrect authorization vulnerability in compose attachment endpoints that allows unauthenticated attackers to download private attachments by setting the URL kind segment to page, icon, or namespace. Attackers who know a private record or module attachment id can request the original or preview route without a token or signature to retrieve files across namespace and record permission boundaries.
Executive ViewAI
Corteza deployments running version 2024.9.10 or earlier expose private compose attachments to unauthenticated download, allowing anyone who can reach the attachment endpoints and guess or obtain a valid record or module ID to retrieve files that were intended to be access-controlled. Successful exploitation does not modify or disrupt systems, but it directly undermines the confidentiality of records, files, and metadata shared through the platform, which can expose customer data, internal documents, or regulated information depending on what teams store in Corteza. Leadership should treat this as a data-exposure issue affecting any business unit that relies on Corteza for private document handling, and should prioritize remediation of internet-facing instances.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-96895
GHSA-8hq6-x78m-7h79
NVD
CVE.org
EPSS
Exploit-DB