EUVD-2026-97832
GHSA-ccrf-jfj2-x65f
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIntercept valid OAuth1-signed API request
-
ExploitReplay request to Allura endpoint
-
ExecutionBypass nonce/timestamp validation
-
ImpactPerform authorized action as victim
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Replay attack prevention
|
| Exploitation Conditions | Exploitation requires the Allura OAuth1 API to be in use and the attacker to first obtain a valid, previously issued OAuth1-signed request from a legitimate user - typically via network interception/man-in-the-middle or access to logged or leaked requests. The flaw is that Allura (≤1.21.0) fails to adequately enforce OAuth1 nonce/timestamp single-use, permitting replay of that captured request. Limiting factors: the attacker gains only the authorization scope of the captured request (not arbitrary access), must capture a genuine signed request before replaying it, and only instances running versions through 1.21.0 are affected; upgrading to 1.22.0 removes the condition. No attacker-side authentication is needed because the victim's own signed request is replayed. |
| Impact | Signals diverge sharply for this vulnerability. The input CVSS is 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), driven by a network vector, no required privileges, and high confidentiality/integrity impact. However, the real-world risk appears lower than that score implies. The weakness is CWE-294 (capture-replay), meaning an attacker cannot act unilaterally - they must first obtain a previously valid OAuth1-signed request, which realistically requires network interception or access to logged/leaked requests. This precondition makes the practical attack complexity higher than the AC:L in the published vector suggests. Supporting this, EPSS is only 0.15% (4th percentile), indicating very low predicted exploitation probability, and there is no CISA KEV listing and no public exploit identified at time of analysis. Apache Allura is niche forge/project-hosting software with a small deployment footprint, further reducing aggregate exposure. Net assessment: a genuine authentication-weakness flaw worth patching, but a 'high-CVSS, lower-real-risk' case rather than an active emergency. Note the tension: the published AC:L understates the capture requirement inherent to a replay attack - I assess AC:H independently (see assessed vector). |
| Exploit ScenarioDerived | An attacker who can observe network traffic to an Allura instance (e.g., via a man-in-the-middle position or recovered request logs) captures a valid OAuth1-signed API request issued by a legitimate user. Because nonce/timestamp validation is insufficient, the attacker resubmits (replays) that captured request to the Allura API, which accepts it as authentic and performs the action under the victim's authorization, disclosing or modifying the victim's data. No public exploit identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Oct 16, 2026
OAuth1 request replay in Apache Allura through 1.21.0 lets a remote, unauthenticated attacker reuse a previously captured OAuth1-signed request to act with the original requester's authorization, because the platform does not adequately enforce nonce/timestamp single-use. The practical barrier is high rather than trivial: the attacker must first obtain a genuine signed request from a legitimate user - most plausibly through network interception, a man-in-the-middle position, or access to logged or leaked requests - and the replay only yields the scope of that specific captured request rather than arbitrary access, which is why the attack-complexity is assessed as high (AC:H) despite the PR:N vector. No public exploit code and no confirmed active exploitation were identified at time of analysis; EPSS is low at roughly 0.15% (4th percentile), so mass scanning is unlikely, though the vendor has published a fix in Apache Allura 1.22.0.
Earlier versions of this analysis (1)
OAuth1 request replay in Apache Allura through 1.21.0 allows an attacker who has captured a complete, validly-signed OAuth1 request to resubmit that request and have it accepted, so any action the original signed request authorized can be repeated on the victim's behalf. The assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) rates this as low impact: the attack surface is limited to deployments that actually use Allura's OAuth1 API, and the attacker cannot forge new requests, only replay previously observed ones. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the issue is fixed in Allura 1.22.0, which introduces the nonce/timestamp enforcement that closes the replay window.
RemediationAI
The vendor-released fix is Apache Allura 1.22.0, which corrects the OAuth1 nonce/timestamp validation; upgrading all instances from 1.21.0 or earlier to 1.22.0 is the primary and complete remediation, and users are explicitly recommended to do so per the advisory at https://allura.apache.org/ and https://seclists.org/oss-sec/2026/q4/137. Where an immediate upgrade is not possible, prioritize compensating controls against the capture step, since the replay is only exploitable once a valid signed request is in hand: enforce HTTPS end-to-end with HSTS on every Allura endpoint handling OAuth1 API traffic and reject plaintext HTTP, which removes the most likely interception path but does not protect against a compromised client, proxy, or leaked logs; if the OAuth1 API is not used by any integration, disable or block the OAuth1 endpoints at the reverse proxy and firewall layer, accepting that all OAuth1 clients break until re-migrated; shorten OAuth1 access-token lifetimes and rotate consumer secrets so any captured signature pair is valid only briefly, at the cost of more frequent re-authorization for legitimate clients; and restrict OAuth1 request logging so signed requests are not persisted in plaintext or shipped to central log stores, which reduces the leaked-request vector that the assessment identifies as a realistic acquisition path. Because exploit code is not publicly known, EPSS is only about 0.15%, and no KEV entry exists, these controls can be sequenced behind normal patch cadence, but any Allura instance exposing OAuth1 to untrusted networks should be treated as higher priority given the C:H/I:H impact if a signed request is captured.
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
The flaw is CWE-294 (Authentication Bypass by Capture-replay) in the OAuth1 layer of Apache Allura, the Apache Software Foundation's open-source project-hosting and collaboration forge. OAuth1 authenticates each API request with a signature over the request parameters, a client key, a timestamp, and a one-time nonce; replay protection depends on two things - the nonce must never be accepted twice within the provider's retention window, and the timestamp must fall within an accepted freshness window (typically minutes), otherwise the signature is rejected. When an implementation fails to durably record and reject already-used nonces (or tolerates stale timestamps), a signed request becomes a bearer credential that can be copied and re-submitted. The independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1 vendor score with AC:L), reflecting that no attacker credentials are needed because the victim's own signed request is replayed, but that the attacker must first capture a valid request and is thereby constrained to the privileges and scope embedded in it. Affected per EUVD is the version range 'Apache Allura 0 through 1.21.0'; no CPE strings were supplied with the input data. The associated tags classify the issue as an Apache information-disclosure concern, consistent with the captured-request parameter leakage that precedes the replay.
Know when the next one hits your stack
- 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
Network-exploitable with no attacker privileges (PR:N) since the victim's own signed request is replayed, but AC:H because the attacker must first capture a valid OAuth1-signed request; replay grants victim-scoped read/write (C:H/I:H), no availability impact.
Primary rating from Vendor (CNA).
CVSS VectorVendor
Lifecycle Timeline
1Description PRE-NVD
Executive ViewAI
Apache Allura, the collaboration and software-development platform used to host project workspaces, repositories, and shared content, contains a critical OAuth1 request-replay flaw affecting all releases through 1.21.0. Because a captured signed request can be reused under the original user's authorization, affected teams face potential unauthorized access to or modification of whatever data that request covered - but successful exploitation requires an attacker to first intercept or otherwise obtain a genuine signed request, which materially limits real-world likelihood. Leadership should care because Allura typically fronts shared engineering and partner-facing content, so any compromise of user authorization scope could expose sensitive project data even without mass exploitation.
Apply vendor patch.
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
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB