Skip to main content

Angular EUVDEUVD-2026-38269

| CVE-2026-54266 HIGH
Use of Weak Hash (CWE-328)
2026-06-15 https://github.com/angular/angular GHSA-39pv-4j6c-2g6v
8.8
CVSS 4.0 · Vendor: https://github.com/angular/angular
Share

Severity by source

Vendor (https://github.com/angular/angular) PRIMARY
8.8 HIGH
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
vuln.today AI
6.9 MEDIUM

Network-reachable SSR app, but requires a victim to click a crafted link (UI:R), a precomputed collision and SSR-cacheable sensitive endpoint (AC:H); poisoned cache crosses SSR-to-client trust boundary (S:C) with high confidentiality and limited integrity impact.

3.1 AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:L/A:N
4.0 AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/angular/angular).

CVSS VectorVendor: https://github.com/angular/angular

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

6
Analysis Updated
Jun 22, 2026 - 17:00 vuln.today
v3 (cvss_changed)
Analysis Updated
Jun 22, 2026 - 17:00 vuln.today
v2 (cvss_changed)
Re-analysis Queued
Jun 22, 2026 - 16:52 vuln.today
cvss_changed
CVSS changed
Jun 22, 2026 - 16:52 NVD
8.8 (HIGH)
Source Code Evidence Fetched
Jun 15, 2026 - 17:53 vuln.today
Analysis Generated
Jun 15, 2026 - 17:53 vuln.today

DescriptionCVE.org

Angular's HttpTransferCache caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in TransferState using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters).

The cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions.

An attacker can easily find a query parameter string (e.g., q=aaCAZMMM for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., /api/user/profile). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the TransferState cache.

Impact

When the application attempts to retrieve the cached response for the sensitive endpoint (such as the user's profile), it receives the attacker-controlled response instead. This results in:

  • State Poisoning: The application runs with attacker-forged data, which can lead to bypassing client-side security controls or DOM-based Cross-Site Scripting (XSS) if the data is rendered unsafely.
  • Information Leakage: If the sensitive response is mistakenly associated with the attacker's search results and rendered on the page, the victim's sensitive data may be disclosed to the attacker.

Patched Versions

  • 22.0.1
  • 21.2.17
  • 20.3.25

Framework-Level Fix

The logic has been updated to use a cryptographically secure SHA-256 hash algorithm for generating TransferState cache keys in HttpTransferCache. The cache keys are now 256-bit hexadecimal strings.

Workarounds

If you cannot upgrade immediately, configure your HttpClient requests to skip transfer caching for sensitive endpoints:

ts
this.http.get('/api/user/profile', {
  transferCache: false
});

Alternatively, disable the HTTP transfer cache globally in your application bootstrap config:

ts

import { provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser';

export const appConfig = {
  providers: [
    provideClientHydration(
      withNoHttpTransferCache()
    )
  ]
};

Credits

This vulnerability was discovered and reported by CodeMender from Google DeepMind.

AnalysisAI

Cache key collision in Angular's @angular/common HttpTransferCache allows remote attackers to poison Server-Side Rendering (SSR) cache entries and replace responses for sensitive endpoints with attacker-controlled content. The weak 32-bit DJB2-like polynomial rolling hash used for TransferState cache keys is trivially brute-forceable, enabling state poisoning, DOM-based XSS, and information leakage when a victim follows a crafted link. No public exploit identified at time of analysis, but the vulnerability was discovered and reported by Google DeepMind's CodeMender and is patched in Angular 22.0.1, 21.2.17, and 20.3.25.

Technical ContextAI

The flaw is in @angular/common's HttpTransferCache mechanism, which serializes HTTP responses gathered during SSR into TransferState so the client can reuse them during hydration without re-issuing requests. Cache keys are derived from request method, response type, mapped URL, body, and sorted query parameters - but were hashed with a custom 32-bit DJB2-like polynomial rolling hash. CWE-328 (Use of Weak Hash) captures the root cause: a 32-bit non-cryptographic hash provides only ~4.3 billion buckets, allowing collisions to be found in seconds with simple brute force. Because retrieveStateFromCache lookups are keyed solely on this hash, a colliding pair of requests share one cache slot and the later-stored response silently replaces the earlier one. The fix in PR #69153 (commit 5f36274) switches the algorithm to SHA-256 hexadecimal keys, removing the collision attack surface.

RemediationAI

Vendor-released patch: upgrade @angular/common to 22.0.1, 21.2.17, or 20.3.25 depending on your major version line, per GHSA-39pv-4j6c-2g6v (https://github.com/angular/angular/security/advisories/GHSA-39pv-4j6c-2g6v); the underlying fix is in PR https://github.com/angular/angular/pull/69153 / commit 5f36274da3f961430ae72865159afa02a1dd9133, which replaces the 32-bit hash with SHA-256. Users still on 19.x have no upstream fix and should plan a major-version upgrade. As a workaround until upgrade, opt sensitive HttpClient calls out of the cache with transferCache: false (e.g., this.http.get('/api/user/profile', { transferCache: false })) - this incurs an extra client-side round-trip per protected endpoint but immediately removes the collision risk for that response. Alternatively, disable transfer caching globally by registering provideClientHydration(withNoHttpTransferCache()) in the application bootstrap providers, accepting the latency cost of re-issuing all SSR HTTP requests on the client.

Share

EUVD-2026-38269 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy