Ce mail provient de l'extérieur, restons vigilants

=====================================================================

                            CERT-Renater

                Note d'Information No. 2026/VULN226
_____________________________________________________________________

DATE                : 26/02/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running @angular/ssr (npm) versions prior
                      to 21.2.0-rc.1, 21.1.5, 20.3.17, 19.2.21,
                        @nguniversal/common (npm),
                        @nguniversal/express-engine (npm).

=====================================================================
https://github.com/angular/angular-cli/security/advisories/GHSA-x288-3778-4hhx
https://github.com/angular/angular-cli/security/advisories/GHSA-xh43-g2fq-wjrj
_____________________________________________________________________

SSRF and Header Injection in Angular SSR
Critical
alan-agius4 published GHSA-x288-3778-4hhx Feb 23, 2026

Package
@angular/ssr (npm)

Affected versions
>= 21.2.0-next.0 < 21.2.0-rc.1
>= 21.0.0-next.0 < 21.1.5
>= 20.0.0-next.0 < 20.3.17
>= 19.0.0-next.0 < 19.2.21
<= 18.2.21

Patched versions
21.2.0-rc.1
21.1.5
20.3.17
19.2.21
none

@nguniversal/common (npm)
Affected versions
<= 16.2.0
Patched versions
None

@nguniversal/express-engine (npm)
Affected versions
<= 16.2.0
Patched versions
none


Description

A Server-Side Request Forgery (SSRF) vulnerability has been identified
in the Angular SSR request handling pipeline. The vulnerability exists
because Angular’s internal URL reconstruction logic directly trusts
and consumes user-controlled HTTP headers specifically the Host and
X-Forwarded-* family to determine the application's base origin without
any validation of the destination domain.

Specifically, the framework didn't have checks for the following:

    Host Domain: The Host and X-Forwarded-Host headers were not checked
to belong to a trusted origin. This allows an attacker to redefine the
"base" of the application to an arbitrary external domain.
    Path & Character Sanitization: The X-Forwarded-Host header was not
checked for path segments or special characters, allowing manipulation
of the base path for all resolved relative URLs.
    Port Validation: The X-Forwarded-Port header was not verified as
numeric, leading to malformed URI construction or injection attacks.

This vulnerability manifests in two primary ways:

    Implicit Relative URL Resolution: Angular's HttpClient resolves
relative URLs against this unvalidated and potentially malformed base
origin. An attacker can "steer" these requests to an external server
or internal service.
    Explicit Manual Construction: Developers injecting the REQUEST
object to manually construct URLs (for fetch or third-party SDKs)
directly inherit these unsanitized values. By accessing the
Host / X-Forwarded-* headers, the application logic may perform
requests to attacker-controlled destinations or malformed endpoints.


Impact

When successfully exploited, this vulnerability allows for arbitrary
internal request steering. This can lead to:

    Credential Exfiltration: Stealing sensitive Authorization headers
or session cookies by redirecting them to an attacker's server.
    Internal Network Probing: Accessing and transmitting data from
internal services, databases, or cloud metadata endpoints
(e.g., 169.254.169.254) not exposed to the public internet.
    Confidentiality Breach: Accessing sensitive information processed
within the application's server-side context.


Attack Preconditions

    The victim application must use Angular SSR (Server-Side Rendering).
    The application must perform HttpClient requests using relative URLs
OR manually construct URLs using the unvalidated Host / X-Forwarded-*
headers using the REQUEST object.
    Direct Header Access: The application server is reachable by an
attacker who can influence these headers without strict validation from
a front-facing proxy.
    Lack of Upstream Validation: The infrastructure (Cloud, CDN, or
Load Balancer) does not sanitize or validate incoming headers.


Patches

    21.2.0-rc.1
    21.1.5
    20.3.17
    19.2.21


Workarounds

    Use Absolute URLs: Avoid using req.headers for URL construction.
Instead, use trusted variables for your base API paths.
    Implement Strict Header Validation (Middleware): If you cannot
upgrade immediately, implement a middleware in your server.ts to
enforce numeric ports and validated hostnames.

const ALLOWED_HOSTS = new Set(['your-domain.com']);

app.use((req, res, next) => {
  const hostHeader = (req.headers['x-forwarded-host'] ?? req.headers['host'])?.toString();
  const portHeader = req.headers['x-forwarded-port']?.toString();

  if (hostHeader) {
    const hostname = hostHeader.split(':')[0];
    // Reject if hostname contains path separators or is not in allowlist
    if (/^[a-z0-9.:-]+$/i.test(hostname) || 
       (!ALLOWED_HOSTS.has(hostname) && hostname !== 'localhost')) {
      return res.status(400).send('Invalid Hostname');
    }
  }

  // Ensure port is strictly numeric if provided
  if (portHeader && !/^\d+$/.test(portHeader)) {
    return res.status(400).send('Invalid Port');
  }

  next();
});

References

    Fix
    Docs

Severity
Critical
9.2/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity Low
Availability None
Subsequent System Impact Metrics
Confidentiality High
Integrity Low
Availability None
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N

CVE ID
CVE-2026-27739

Weaknesses
Weakness CWE-918

Credits

    @Yenya030 Yenya030 Reporter
    @alan-agius4 alan-agius4 Remediation developer
    @securityMB securityMB Remediation reviewer
    @AndrewKushnir AndrewKushnir Remediation reviewer
    @josephperrott josephperrott Remediation reviewer
    @dgp1130 dgp1130 Remediation reviewer

_____________________________________________________________________


Open Redirect via X-Forwarded-Prefix in Angular SSR
Moderate
alan-agius4 published GHSA-xh43-g2fq-wjrj Feb 23, 2026

Package
@angular/ssr (npm)

Affected versions
>= 21.2.0-next.0 < 21.2.0-rc.1
>= 21.0.0-next.0 < 21.1.5
>= 20.0.0-next.0 < 20.3.17
>= 19.0.0-next.0 < 19.2.21

Patched versions
21.2.0-rc.1
21.1.5
20.3.17
19.2.21

Description

An Open Redirect vulnerability exists in the internal URL processing
logic in Angular SSR. The logic normalizes URL segments by stripping
leading slashes; however, it only removes a single leading slash.

When an Angular SSR application is deployed behind a proxy that passes
the X-Forwarded-Prefix header, an attacker can provide a value
starting with three slashes (e.g., ///evil.com).

    The application processes a redirect (e.g., from a router
redirectTo or i18n locale switch).
    Angular receives ///evil.com as the prefix.
    It strips one slash, leaving //evil.com.
    The resulting string is used in the Location header.
    Modern browsers interpret // as a protocol-relative URL,
redirecting the user from https://your-app.com to https://evil.com.


Impact

This vulnerability allows attackers to conduct large-scale phishing
and SEO hijacking:

    Scale: A single request can poison a high-traffic route, impacting
all users until the cache expires.
    SEO Poisoning: Search engine crawlers may follow and index these
malicious redirects, causing the legitimate site to be delisted or
associated with malicious domains.
    Trust: Because the initial URL belongs to the trusted domain,
users and security tools are less likely to flag the redirect as
malicious.


Attack Preconditions

    The application must use Angular SSR.
    The application must have routes that perform internal redirects.
    The infrastructure (Reverse Proxy/CDN) must pass the
X-Forwarded-Prefix header to the SSR process without sanitization.
    The cache must not vary on the X-Forwarded-Prefix header.


Patches

    21.2.0-rc.1
    21.1.5
    20.3.17
    19.2.21


Workarounds

Until the patch is applied, developers should sanitize the
X-Forwarded-Prefix header in theirserver.ts before the Angular
engine processes the request:

app.use((req, res, next) => {
  const prefix = req.headers['x-forwarded-prefix']?.trim();
  if (prefix) {
    // Sanitize by removing all leading slashes
    req.headers['x-forwarded-prefix'] = prefix.replace(/^[/\\]+/, '/');
  }
  next();
});


References

    Report
    Fix


Severity
Moderate
6.9/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability None
Subsequent System Impact Metrics
Confidentiality Low
Integrity Low
Availability None
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

CVE ID
CVE-2026-27738

Weaknesses
Weakness CWE-601

Credits

    @alan-agius4 alan-agius4 Remediation developer
    @josephperrott josephperrott Remediation reviewer
    @securityMB securityMB Remediation reviewer
    @AndrewKushnir AndrewKushnir Remediation reviewer
    @dgp1130 dgp1130 Remediation reviewer
    @VenkatKwest VenkatKwest Reporter


=========================================================
+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================