EUVD-2026-97829
GHSA-6j5w-w523-6q83
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft OAuth1 request with malicious callback
-
DeliveryLure victim into OAuth authorization flow
-
ExploitServer fails to validate callback URL
-
ExecutionVictim redirected to attacker domain with token
-
ImpactReplay stolen token for account takeover
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V3 - Web Frontend Security Redirect URL validation
MITRE ATT&CK
1 technique across 1 tactic: Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the OAuth1 authorization flow to be in use on the Allura instance, and exploitation realistically depends on a victim being induced to complete an OAuth authorization request whose oauth_callback parameter the server does not properly validate (affected builds through 1.21.0). The limiting factor is that an attacker generally cannot steal tokens passively - a user must traverse the attacker-influenced OAuth flow (user interaction), narrowing this below a fully drive-by exploit despite the UI:N in the supplied vector. Patched in 1.22.0; instances already on 1.22.0+ or not exposing OAuth1 integrations are not affected. |
| Impact | Signals are mixed and skew toward a MODERATE real-world priority despite the high CVSS. The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N = 9.1) describes a remote, unauthenticated, low-complexity flaw with high confidentiality and integrity impact - consistent with OAuth callback manipulation leading to token/credential theft and account takeover. However, CWE-601 (Open Redirect) and the 'Open Redirect' tag normally imply victim interaction (clicking a crafted link), which conflicts with the UI:N in the provided vector - this discrepancy should be verified with the Apache advisory, as genuine open-redirect exploitation typically requires UI:R. EPSS is very low (0.15%, 4th percentile) and the vulnerability is NOT in CISA KEV, with no public POC identified, indicating no evidence of active or imminent widespread exploitation. Net: a legitimately high-impact authorization/redirect flaw, but mitigated by low exploitation probability, absence of public exploit code, and the niche deployment footprint of Allura - treat as a prompt patch item, not an emergency, absent new exploitation intelligence. No SSVC decision data was provided in the input. |
| Exploit ScenarioDerived | An attacker crafts a malicious OAuth1 authorization request against an Allura instance (≤1.21.0) with an attacker-controlled oauth_callback URL that the server fails to validate. A victim completing the OAuth flow is redirected off-platform, leaking the OAuth token/verifier to the attacker, who then uses it to access the victim's account. No public exploit code was identified at time of analysis, and realistic exploitation hinges on luring a user through the OAuth flow. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Oct 16, 2026
Open redirect flaw in the OAuth1 callback validation of Apache Allura through 1.21.0 allows unauthenticated remote attackers to redirect users to arbitrary attacker-controlled URLs during the OAuth authorization flow (CWE-601), potentially exposing authorization codes or tokens if a victim completes the flow. Exploitation is not drive-by: per the independent assessment a user must be induced to traverse the attacker-influenced OAuth request (UI:R), which lowers real-world risk below the supplied 9.1 base score; the vendor patched the issue in Allura 1.22.0, no public exploit identified at time of analysis, and EPSS is 0.15% (4th percentile), so this is assessed as a moderate real-world priority.
Earlier versions of this analysis (1)
Missing OAuth1 callback validation in Apache Allura through 1.21.0 lets an attacker who controls or influences an OAuth1 consumer steer a victim's authorization flow to an attacker-chosen callback URL, exposing the credentials the victim authorizes. The flaw is remotely reachable without authentication (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N) but requires the victim to actively complete an OAuth1 authorization flow, so exploitation is conditional rather than automatic and is bounded to the privileges and resources the victim grants. Only Allura deployments that expose OAuth1 consumer/integration functionality are affected; no public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV).
RemediationAI
The vendor-released patch is Allura 1.22.0; upgrade to that version or later (see https://allura.apache.org/ and https://lists.apache.org/thread.html/d716zfvgpnrjlsc7bmysv4sxbnh2b57f). If immediate upgrade is not possible, compensating controls include disabling OAuth1 authorization or provider integrations and the OAuth1 endpoints if they are not needed (trade-off: breaks legitimate OAuth1-based integrations), restricting accepted oauth_callback values to a strict whitelist of trusted domains and paths (trade-off: requires maintaining the allowlist and may reject legitimate third-party clients), and placing a reverse proxy or WAF rule in front of Allura to block callback parameters pointing to external hosts (trade-off: may cause false positives for legitimate external integrations and adds maintenance overhead). Because no public exploit identified at time of analysis and no KEV activity is known, with EPSS at 0.15%, this can be scheduled as a moderate-priority patch, but the assessed UI:R requirement means risk escalates if users are routinely steered into OAuth authorization flows by untrusted links.
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
Apache Allura is an Apache Software Foundation open-source project-hosting platform. The vulnerability resides in its handling of the OAuth1 authorization flow: the server fails to properly validate the oauth_callback parameter (CWE-601, URL Redirection to Untrusted Site / Open Redirect), so an attacker can supply a callback pointing to a domain they control. Because OAuth1 delivers the request token and verifier to the callback endpoint, a mis-validated callback can leak authorization material, but only if a victim is actually induced to complete the authorization step; the independent assessment therefore sets UI:R (user interaction required), whereas the supplied vector uses UI:N. The other assessed metrics agree: AV:N, AC:L, PR:N, S:U, C:H, I:H, A:N, i.e., an unauthenticated remote attacker with no privileges can achieve high confidentiality and integrity impact through the flow. Affected builds are those through 1.21.0; the fix is in 1.22.0, and instances that do not expose OAuth1 provider integrations are not reachable by this issue.
Know when Apache Allura 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
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Remote unauthenticated open-redirect in the OAuth callback (AV:N/AC:L/PR:N) requires a victim to complete the OAuth flow, so UI:R; token leak and account takeover give C:H/I:H, A:N.
Primary rating from Vendor (CNA).
CVSS VectorVendor
Lifecycle Timeline
2Description PRE-NVD
Articles & Coverage 1
Executive ViewAI
Apache Allura, the open-source collaboration and software forge platform used by many organizations to host code, tickets, and project workspaces, contains a critical open-redirect flaw in its OAuth1 callback validation affecting releases through 1.21.0. A remote attacker who induces a user to follow a crafted OAuth authorization link can redirect that user to an attacker-controlled site, potentially surrendering an OAuth authorization code or token and gaining access to the identities and connected services tied to that forgery account. Leadership should care because the exposure is to third-party integrations and user credentials rather than the Allura host itself, so downstream systems may be affected even where Allura is not internet-facing, though exploitation requires user interaction and no public exploit has been observed.
Apply vendor patch (upgrade to Allura 1.22.0 per the supplied assessment); if the upgrade cannot be completed immediately, restrict network exposure of Allura instances, disable or tightly scope OAuth1 integrations, enforce redirect/callback URL allow-listing at the reverse proxy or identity provider, and monitor OAuth authorization flows for off-domain redirect targets.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
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
More in Apache Allura
View allRemote code and command injection in Apache Allura before 1.19.1 lets unauthenticated attackers smuggle attacker-control
Insecure Direct Object Reference (IDOR) in Apache Allura before 1.19.1 allows unauthorized access to multiple Artifact t
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
Exploit-DB