CVE-2024-38821

What it actually does

The flaw allows an unauthenticated remote user to bypass Spring Security authorization rules protecting static resources in certain Spring WebFlux applications. It is only applicable when the application is reactive WebFlux, uses Spring static resource handling, and applies a restrictive authorization rule to those static resources instead of permitting them publicly. When exploitable, requests that should require authentication or authorization may be served directly, exposing protected files or content and potentially undermining application integrity assumptions tied to those resources. The CVSS vector indicates network exploitation with low complexity, no privileges, and no user interaction, with high confidentiality and integrity impact and no direct availability impact.

Why it matters to the business

Applications that rely on Spring Security to protect static files may unintentionally expose restricted content such as internal documentation, downloadable files, client-side application bundles, configuration-like artifacts, or other sensitive resources. If protected static assets influence application behavior, attackers may also abuse unauthorized access to tamper with workflows or gather information for follow-on attacks. Although this issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported mature public exploit in the provided data, the high CVSS score means exposed internet-facing WebFlux applications should still be prioritized. The supplied affected-product metadata references Ubuntu jasper packages and fixed package versions, which appears inconsistent with the Spring WebFlux description; organizations should validate both application dependency exposure and any distro package advisory mappings before treating the listed package fixes as complete remediation.

How an attack unfolds

An attacker first identifies a target application built on Spring WebFlux and enumerates common static resource locations such as asset, webjar, CSS, JavaScript, image, documentation, or download paths. The attacker then sends unauthenticated HTTP requests to resources that the application owner intended to protect with Spring Security rules. Under the vulnerable circumstances, Spring's static resource handling and authorization configuration can allow the request to bypass the intended access control decision, returning content that should have required authentication or a specific role. The attacker can repeat this process to collect restricted files, inspect client-side bundles for endpoints or secrets, retrieve protected documents, or map application functionality for additional attacks. There is no indication from the provided data that this vulnerability is in CISA KEV or actively exploited by named threat actors, but exploitation requires only network access if the vulnerable configuration exists.

How to fix it

Upgrade affected Spring components to versions containing the vendor fix for this authorization bypass. Because exact Spring fixed versions were not provided in the input, consult the official Spring advisory for the specific Spring Security/Spring Framework release line in use and update all affected application dependencies consistently. Review WebFlux security configuration for static resources and avoid relying on vulnerable patterns that apply non-permitAll authorization rules to Spring static resource support without verifying enforcement. If immediate upgrade is not possible, mitigate by moving sensitive static resources behind explicit controller endpoints or another authorization-enforced serving path, restricting access at a reverse proxy or gateway, and removing sensitive material from static resource directories. Re-test all protected static paths with unauthenticated requests after any configuration change. The provided fixed-version data lists Ubuntu jasper package fixes, specifically 1.900.1-14ubuntu3.5 for Ubuntu 14.04 LTS and 1.900.1-debian1-2.4ubuntu1.2 for Ubuntu 16.04 LTS; apply those package updates where that package advisory is applicable, but do not treat them as remediation for a Spring WebFlux application unless inventory confirms the advisory mapping is correct.

How to confirm the fix worked

Confirm whether each application is a Spring WebFlux application, uses Spring static resource handling, and applies restrictive authorization rules to static resources. Validate dependency versions against the official Spring advisory and confirm patched versions are deployed in all runtime artifacts, containers, and build pipelines. Perform unauthenticated HTTP tests against every static resource path intended to be protected and verify the response is 401, 403, or an application-approved redirect rather than HTTP 200. Repeat the tests with users of different roles to confirm role-based access behaves as designed. Review reverse proxy, CDN, and application caching layers to ensure they are not serving previously exposed protected resources after the application is patched. For Ubuntu systems where the jasper package advisory applies, verify installed package versions meet or exceed 1.900.1-14ubuntu3.5 on Ubuntu 14.04 LTS or 1.900.1-debian1-2.4ubuntu1.2 on Ubuntu 16.04 LTS.

Typical attack path

1. Identify an internet-accessible or internally reachable Spring WebFlux application.
2. Probe common static resource paths such as /static/, /assets/, /webjars/, /css/, /js/, /images/, /docs/, or download directories.
3. Send requests without authentication cookies, bearer tokens, or other credentials.
4. Compare responses against expected authorization behavior, looking for HTTP 200 responses where 401 or 403 should be returned.
5. Download any exposed static resources that were intended to be restricted.
6. Analyze retrieved content for sensitive data, internal endpoints, application logic, or information useful for follow-on compromise.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs from the application, reverse proxies, API gateways, load balancers, WAFs, CDNs, and service mesh ingress for unauthenticated requests to static resource paths that should have required login or a specific role. Focus on HTTP 200, 206, or 304 responses for protected static resources where the same path normally produces 401 or 403 for unauthenticated users. Correlate requests with authentication/session logs to identify responses served without a valid session cookie, bearer token, mTLS identity, or expected authorization context. Look for enumeration behavior: many requests across common static directories, source map files, webjars, downloadable documents, or client-side bundles from the same IP or user agent. Compare pre-patch and post-patch behavior for the same URLs. If exposed static resources may have contained sensitive information, preserve logs and retrieved-file metadata, identify all downloaded objects, and assess whether the exposed data enables credential theft, endpoint discovery, business-data access, or follow-on attacks. There are no named threat actors or ransomware campaigns in the provided data, so detection should emphasize behavior-based evidence rather than actor-specific indicators.

• GET /static/
• GET /assets/
• GET /webjars/
• GET /css/
• GET /js/
• GET /images/
• GET /docs/
• GET /download
• GET /downloads/
• GET /public/
• GET /resources/
• GET /META-INF/resources/
• GET /favicon.ico
• GET /robots.txt
• GET /sitemap.xml
• GET /static/js/
• GET /static/css/
• GET /assets/index
• GET /assets/main
• GET /app.js
• GET /main.js
• GET /bundle.js
• GET /runtime.js
• GET /vendor.js
• GET /polyfills.js
• GET /swagger-ui/
• GET /swagger-ui.html
• GET /api-docs
• GET /v3/api-docs
• .js.map
• HTTP/1.1" 200
• HTTP/1.1" 206
• HTTP/1.1" 304

What your security team should do

• Prioritize inventory of Spring WebFlux applications that expose static resource paths and use Spring Security authorization rules on those paths.
• Patch affected Spring dependencies according to the official vendor advisory; rebuild and redeploy applications rather than only updating source manifests.
• If Ubuntu jasper exposure is separately confirmed, apply the listed fixed packages for the relevant Ubuntu LTS releases, while separately remediating Spring WebFlux exposure.
• Create unauthenticated regression tests for all protected static resource locations and add them to CI/CD security validation.
• Inspect access logs for successful unauthenticated requests to static resources that should have returned 401 or 403, especially before the patch window.
• Remove secrets, internal documentation, environment data, source maps, and sensitive client-side configuration from static resource directories.
• Add reverse proxy or gateway-level deny rules for sensitive static paths as a temporary compensating control where rapid application patching is not possible.
• Monitor vendor advisories and exploit intelligence despite the current non-KEV, low-EPSS, and no-known-mature-exploit status.