Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Network-accessible app, low complexity IDOR; PR:L assumed for session-based context; impact is confidentiality disclosure only.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
4DescriptionCVE.org
Insecure Direct Object Reference (IDOR) due to missing permission checks for multiple Artifact types in Apache Allura.
This issue affects Apache Allura: before 1.19.1.
Users are recommended to upgrade to version 1.19.1, which fixes the issue.
Articles & Coverage 1
AnalysisAI
Insecure Direct Object Reference (IDOR) in Apache Allura before 1.19.1 allows unauthorized access to multiple Artifact types due to missing server-side permission checks. Attackers who can interact with the platform can reference artifact objects directly by their identifiers and retrieve content beyond their authorization level, resulting in information disclosure across potentially broad artifact categories. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Technical ContextAI
Apache Allura is an open-source collaborative software development platform originally developed for SourceForge, providing forge-style project hosting with tickets, wikis, code repositories, and file releases - all represented internally as typed 'Artifact' objects. CWE-280 (Improper Handling of Insufficient Permissions or Privileges) identifies the root cause: the application's permission enforcement layer fails to consistently validate the requesting user's privileges before serving artifact resources across multiple artifact types. In an IDOR pattern, the application exposes a direct reference (typically an ID or slug) to an internal object, and when the server omits authorization validation at retrieval time, any user who can construct or enumerate a valid reference can access the resource. The CPE string cpe:2.3:a:apache_software_foundation:apache_allura:*:*:*:*:*:*:*:* confirms all versions prior to the fixed release are affected. The vulnerability spans multiple Artifact types, suggesting the authorization bypass is systematic rather than isolated to a single endpoint.
RemediationAI
Vendor-released patch: Apache Allura 1.19.1. Operators should upgrade immediately by following instructions in the vendor release announcement at https://allura.apache.org/posts/2026-allura-1.19.1.html. For deployments where immediate upgrade is not feasible, a compensating control is to restrict access to the Allura instance at the network perimeter - specifically, placing the application behind a VPN or IP allowlist so that only authorized users can reach artifact endpoints at all; this reduces the population of potential attackers but does not eliminate the underlying authorization flaw for users who retain access. Restricting anonymous/guest access to artifact types that are not intended to be public can also reduce exposure for mixed public/private deployments. No workarounds eliminate the root cause; upgrade to 1.19.1 is the definitive fix.
More in Apache Allura
View allRemote code and command injection in Apache Allura before 1.19.1 lets unauthenticated attackers smuggle attacker-control
Cross-site scripting in Apache Allura's Markdown rendering (versions 1.10.0 up to but not including 1.19.1) allows an at
Cross-site scripting (XSS) in Apache Allura's code-display feature allows an attacker who can place crafted content into
Unauthenticated REST API disclosure in Apache Allura through version 1.19.1 exposes certain content items to unauthorize
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-57370
GHSA-mjpp-gw39-h7mj