GHSA-56gv-mfrw-xf8j
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain webhook-config access on a project
-
DeliverySet webhook URL to internal/metadata target
-
ExploitTrigger project event firing the webhook
-
ExecutionAllura server issues internal request
-
ImpactExfiltrate internal response or cloud credentials
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service URL allowlisting, SSRF prevention
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the attacker to be able to create or modify an Apache Allura webhook and supply a malicious callback URL, and to trigger the project event that fires the webhook; the SSRF then originates from the Allura server. The primary limiting factor is that webhook configuration in Allura is a project-maintainer/admin function, so despite the CVSS PR:N rating, some level of authenticated project access is realistically needed - this contradiction should be confirmed against the vendor advisory. Impact severity is further bounded by what internal services are reachable from the Allura host's network position. |
| Impact | The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, score 9.1) rates this as network-exploitable with no privileges, but this warrants scrutiny: creating or editing a webhook in Allura normally requires an authenticated project maintainer/admin account, which conflicts with PR:N - verify with the vendor, as realistic exploitation likely needs PR:L. Additionally, SSRF is predominantly a read/confidentiality primitive (C:H is well-justified for reaching internal endpoints); the I:H rating is optimistic and only holds if the SSRF can trigger state-changing internal requests. Countervailing signals: EPSS is low (0.21%), there is no CISA KEV listing, and no public exploit code is referenced, so this is a genuine-but-not-yet-widely-weaponized issue best treated as a prompt patch rather than an emergency. SSVC-style read: exploitation=none observed, automatable=likely no (requires webhook creation), technical impact=partial-to-total depending on internal reachability. |
| Exploit ScenarioDerived | An attacker with the ability to configure a project webhook points its callback URL at an internal service or the cloud metadata endpoint (e.g. http://169.254.169.254/latest/meta-data/), then triggers the associated project event; the Allura server dispatches the request from inside the trust boundary and the attacker harvests internal responses or credentials. Because the CVSS marks AV:N/AC:L, delivery is straightforward over the network, though it hinges on webhook-configuration access. No public proof-of-concept is referenced at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Sep 08, 2026
Server-Side Request Forgery in Apache Allura through version 1.20.0 lets attackers abuse the project webhook feature to coerce the server into issuing arbitrary outbound requests, enabling access to internal-only services and cloud metadata endpoints. The flaw is fixed in 1.21.0. No public exploit is identified at time of analysis and EPSS is low (0.21%, 11th percentile), indicating no observed mass-exploitation pressure despite the high CVSS.
Earlier versions of this analysis (1)
Server-side request forgery in Apache Allura's webhook subsystem allows authenticated users to coerce the Allura server into making arbitrary outbound HTTP requests to attacker-controlled URLs, potentially reaching internal network services, cloud metadata endpoints, or other restricted hosts. All releases through 1.20.0 are affected; version 1.21.0, released September 2026, resolves the issue. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade Apache Allura to 1.21.0, which fixes the SSRF per the project advisory and the Apache mailing-list thread (https://lists.apache.org/thread/v4nplqchsmdg9sdhp91f8hn03rlq8y7s). If immediate upgrade is not feasible, apply compensating controls: place the Allura server behind an egress proxy or firewall that denies outbound requests to RFC1918, loopback, and link-local (169.254.169.254) ranges so webhook callbacks cannot reach internal services or cloud metadata - trade-off is that legitimate webhooks to internal hosts break; restrict who can create/edit webhooks to trusted project admins and audit existing webhook targets; and disable the webhook feature entirely if it is unused, at the cost of losing event-driven integrations. Refer to the oss-security post (https://seclists.org/oss-sec/2026/q3/644) for disclosure context.
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 open-source forge/collaboration platform (originally developed to power SourceForge) for hosting Git/SVN repositories, tickets, wikis, and discussions. The vulnerable component is its webhook subsystem, which dispatches HTTP callbacks to user-supplied URLs when project events fire. CWE-918 (SSRF) here means the webhook target URL is not adequately validated against internal address ranges, so the Allura server can be induced to fetch attacker-chosen destinations (RFC1918 hosts, localhost services, link-local 169.254.169.254 metadata). The Apache/SSRF tags accurately reflect the vendor and vulnerability class.
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
Webhook creation is a project-maintainer function so PR:L (not PR:N); SSRF is chiefly a confidentiality read primitive (C:H), with only limited integrity from triggered internal requests (I:L).
Primary rating from Vendor (CNA).
CVSS VectorVendor
Lifecycle Timeline
3Description PRE-NVD
Articles & Coverage 3
Executive ViewAI
Apache Allura versions up to 1.20.0 contain a vulnerability in the webhook feature that enables attackers to force the server to make unauthorized requests to internal services and cloud environments, potentially exposing sensitive data or infrastructure access. Although the technical severity rating is critical (CVSS 9.1), exploitation likelihood remains very low (EPSS 0.21%) with no identified public exploits, indicating this is a future-focused defensive priority rather than an immediate operational threat.
Apply vendor patch. Upgrade to Apache Allura version 1.21.0 or later.
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
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
EUVD-2026-70922
NVD
CVE.org
EPSS
VulDB
Exploit-DB