CVE-2026-22741

What it actually does

When Spring MVC or WebFlux resource-chain caching is enabled together with encoded-resource resolution, an unauthenticated remote requester can, while the resource cache is still empty, cause static assets to be stored under the wrong encoding. Subsequent cache hits then serve incorrectly encoded JavaScript, CSS, or other static files, which can break client-side rendering and produce an application-level denial of service. Confidentiality and integrity of application data are not affected; impact is limited to availability of cached static content.

Why it matters to the business

Users may see a broken front end (blank pages, failed scripts, unstyled UI) until caches are flushed or the process is restarted, causing service disruption, support load, and possible revenue or SLA impact for public web applications. Likelihood is constrained: CVSS is 3.1 (network, high attack complexity, user interaction, availability-low), EPSS is about 0.0024 and flat over 30 days, exploit maturity is none, and the issue is not in CISA KEV and is not associated with ransomware. Risk is highest for internet-facing Spring apps that enable static resource caching plus encoded-resource resolution; unused or unconfigured resource chains are not affected. Published 163 days ago with no reported in-the-wild campaigns, so treat as a standard patch item rather than an emergency KEV-style outage.

How an attack unfolds

An attacker first confirms the target uses Spring MVC or WebFlux with the resource chain, caching, and encoded-resource resolution enabled, and that the resource cache has not yet been populated (for example after a restart or cold start). They then send crafted requests for static resources that cause the resolver to cache an asset with an incorrect encoding. Later legitimate browsers retrieve those poisoned cache entries and fail to parse or execute the assets, denying service to the front end. No privileged access is required, but conditions are strict (empty cache, specific configuration, and user-facing clients that consume the poisoned assets), and there are no named APT groups, KEV listings, or public exploit kits associated with this issue.

How to fix it

Upgrade VMware/Broadcom Spring Framework to a vendor-patched release that corrects encoded-resource caching. This advisory did not include exact fixed version numbers; obtain current patched versions from the official Spring Framework security advisory and release notes for the 5.x/6.x line you run, then upgrade all MVC and WebFlux applications. Until you can patch: disable resource-chain caching, disable encoded-resource resolution if not required, avoid serving encoded static variants through the chain, and ensure static assets are served from a CDN or reverse proxy that does not share Spring’s in-process resource cache. After upgrade, restart application instances so any poisoned in-memory resource cache is discarded. Track the Spring security mailing list and GitHub advisories because fixed-version lists may be published after this write-up.

How to confirm the fix worked

Inventory apps for spring-webmvc or spring-webflux, resource-chain/cache configuration, and EncodedResourceResolver (or equivalent encoded-resource support). Confirm the running Spring Framework version is one listed as fixed in the official advisory. After upgrade, restart, then request representative static assets (with and without encoding-related headers such as Accept-Encoding) and verify Content-Encoding and body bytes match the files on disk. Confirm the resource cache does not retain a mismatched encoding across subsequent requests. Review config to ensure caching plus encoded-resource resolution is not re-enabled on unpatched builds. Negative check: unpatched apps with both features on remain theoretically exposable whenever the resource cache is empty.

Typical attack path

1. Identify a Spring MVC or WebFlux application that serves static resources through the resource chain with caching and encoded-resource resolution enabled.
2. Time access for a cold or empty resource cache (process start, cache flush, or first hit of a given resource).
3. Issue requests that cause the encoded-resource resolver to store static files under the wrong encoding in the resource cache.
4. Allow subsequent legitimate client requests to be served the poisoned cached assets.
5. Observe client-side failures (broken scripts, styles, or media) that amount to a front-end denial of service until the cache is cleared or the process is restarted.

How to detect it

There are no public exploits, named threat actors, or KEV/ransomware associations, so hunting is configuration- and symptom-based rather than signature-based. Look for a cluster of client errors immediately after an application restart or cache clear: browsers failing to load JS/CSS, MIME/encoding mismatches, or a spike in 200 responses for static paths whose bodies do not match known-good hashes. Review access logs for first-hit static-resource requests (especially with unusual or multiple encoding-related headers) against apps that use Spring resource-chain caching. On hosts, dump or inspect the in-process resource cache after a suspected event and compare cached bytes and encoding metadata to files on disk. Application logs around ResourceHttpRequestHandler / EncodedResourceResolver and reverse-proxy logs showing Content-Encoding that does not match Accept-Encoding are useful. Absence of these symptoms plus a patched Spring version strongly indicates the issue was not exploited.

• EncodedResourceResolver
• ResourceHttpRequestHandler
• Accept-Encoding
• Content-Encoding: gzip
• Content-Encoding: br
• Cache-Control: max-age

What your security team should do

• Prioritize internet-facing Spring MVC/WebFlux apps that enable resource-chain caching and encoded-resource resolution; internal-only or non-caching static setups can be queued with normal patching.
• Upgrade Spring Framework to the patched releases published in the official Spring security advisory; do not wait for a KEV listing given this is a low-severity DoS with no known exploits.
• Until patched, disable resource-chain caching or encoded-resource resolution, and flush/restart instances after any suspected cache poison.
• Add configuration checks (IaC/policy) that flag EncodedResourceResolver combined with a caching resource chain on unpatched Spring versions.
• Because EPSS is low and stable and exploit maturity is none, do not divert incident-response surge capacity; fold into the regular framework upgrade cycle and verify completion.
• Document cache-flush and restart runbooks so operators can restore a broken front end quickly if poisoning is ever observed.