All,
Recently, the Angular Team announced a critical Server-Side Request Forgery (SSRF) vulnerability in Angular SSR (CVE-2026-27739)
In this vulnerability, Angular reported that both the "Host" and "X-Forwarded-Host" HTTP Headers were not being properly validated, which could allow for an SSRF attack if the application utilized these headers. While DSpace doesn't use "X-Forwarded-Host" directly, it does use the "Host" header in a few places.
After detailed analysis and verification, we have determined that
all versions of DSpace 7.x.x/8.x/9.x are only vulnerable to this attack if you are NOT using a properly configured Apache/Nginx (or similar) proxy (as described in our
Frontend Installation documentation, step 8 "Add HTTPS support")
Specifically, your DSpace site is safe as long as you have an Apache/Nginx proxy configured with
name-based Virtual Hosts (this link goes to an Apace example, but the same setting exists in Nginx and other proxies). So, please check that your DSpace site has a proxy that is using "ServerName" (for Apache) or "server_name" (for Nginx) virtual hosts configured with trusted hostname(s). This setup will ensure that your proxy will only pass requests to DSpace where there is a valid, trusted "Host" header.
As additional layers of protection, we are working on the following:
DSpace 9.x will be updated to the latest version of Angular 20.x, which patches this vulnerability directly. This update will first be available in DSpace 9.3 (release date TBD), but we will share an early patch for sites that wish to update Angular early.
An additional patch is in the works to remove direct usages of the "Host" header from the DSpace user interface. This patch will add a layer of protection by removing the primary attack method in DSpace (direct usage of the "Host" header in DSpace UI code). It should be possible to apply this upcoming patch to 7.x.x, 8.x and 9.x instances.
We'll let you know once the additional patches are available. In the meantime, your best protection is a well configured proxy!
(Thanks to Kim Shepherd for his work in helping to analyze this vulnerability's impact on DSpace.)
Tim Donohue, on behalf of the Committers