CVE-2018-1199: Authorization bypass in Spring Security CO...

In March 2018, Pivotal (the stewards of the Spring portfolio at the time) disclosed CVE-2018-1199, an authorization bypass affecting Spring Security's Cross-Origin Resource Sharing (CORS) integration. The flaw sits at an uncomfortable intersection: browsers' pre-flight CORS mechanism and the servlet filter chain that Spring Security relies on to enforce access control. When an application's CORS configuration and its authorization rules were not aligned, a specially crafted cross-origin request could reach protected logic in ways the application's security configuration did not intend — undermining the assumption that "every request passes through the security filter chain and gets evaluated the same way."

This post breaks down what CVE-2018-1199 actually affected, what we know (and don't overstate) about its severity, and what remediation and detection look like for teams still running old Spring Security dependencies in 2026 — because supply-chain scans routinely still surface this CVE in legacy Java services, forked internal libraries, and vendored dependencies that never got upgraded.

What the Vulnerability Is

Spring Security ships built-in support for CORS, either through Spring MVC's @CrossOrigin annotation or through a CorsConfigurationSource wired into HttpSecurity. The intent is straightforward: let the framework recognize legitimate cross-origin pre-flight (OPTIONS) requests and respond to them correctly, without those pre-flight requests being blocked by authentication or CSRF checks that a real, credentialed request would need to satisfy.

The problem addressed by CVE-2018-1199 is that this convenience path could be exploited under specific configuration conditions. Because CORS pre-flight requests are, by design, unauthenticated (a browser sends them before attaching credentials to the "real" request), any authorization logic that treated CORS-related request handling too permissively risked letting requests slip past the checks that FilterSecurityInterceptor and related components were supposed to enforce. In effect, the parts of Spring Security responsible for saying "this endpoint requires authentication/a specific role" could be circumvented for requests that the CORS-handling code treated as pre-flight or CORS-adjacent traffic, rather than being evaluated as normal protected requests.

The practical risk profile of this class of bug is access-control bypass, not remote code execution: an attacker could potentially reach a resource they should not have been authorized to reach. The blast radius in any given application depends heavily on how CORS was configured, how many endpoints relied on @CrossOrigin, and whether authorization for those endpoints was otherwise defense-in-depth (e.g., also checked at the service or data layer) or relied solely on the Spring Security filter chain.

Affected Versions and Components

Per Spring Security's own advisory, the vulnerability affected:

• Spring Security 5.0.x prior to 5.0.5
• Spring Security 4.2.x prior to 4.2.7
• Older, unsupported Spring Security branches (4.1.x, 4.0.x, and earlier), which received no official patch because they were already end-of-life

The fix was shipped as part of the standard 4.2.7 and 5.0.5 releases rather than as an isolated patch, which is consistent with how the Spring Security team typically handles security fixes — bundling them into the next maintenance release of each supported line. Any application, library, or Spring Boot starter that pinned Spring Security to a version below those thresholds — directly or transitively — inherited the exposure.

This is also a good moment to flag the transitive-dependency problem that makes this CVE relevant to supply-chain security specifically: Spring Boot applications rarely declare spring-security-core or spring-security-web versions explicitly. They inherit them from the Spring Boot parent BOM or from spring-boot-starter-security. Teams that pinned an older Spring Boot version for unrelated reasons (compatibility with an internal library, a slow migration, a vendored fork) often carried the vulnerable Spring Security version forward without realizing it, because nothing in their own code changed.

CVSS, EPSS, and KEV Context

NVD's CVSS v3 scoring for CVE-2018-1199 places it in the Medium severity range, reflecting a network-exploitable issue with low attack complexity but limited impact — consistent with an authorization bypass that depends on the specific CORS configuration in place rather than one that grants broad, unconditional access. Base scores in this range typically require no privileges and no user interaction, which is part of what makes CORS-adjacent bypass bugs worth tracking even at "Medium" severity: an attacker doesn't need a foothold to attempt it.

CVE-2018-1199 is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and we're not aware of confirmed, widespread exploitation in the wild. EPSS scoring didn't exist until 2021 — three years after this CVE was published — so there's no meaningful historical EPSS trajectory to point to; current EPSS percentiles for a CVE this old and this narrowly scoped are, unsurprisingly, low, since the population of internet-facing services still running unpatched Spring Security 4.2.x/5.0.x has shrunk substantially over the years.

The honest takeaway: this is not a headline vulnerability like Log4Shell, and it never was. Its relevance today is almost entirely a supply-chain hygiene question — is this old dependency still lurking somewhere in your build — rather than an active-threat question.

Timeline

• Vulnerable versions in circulation: Spring Security 4.2.x (before 4.2.7) and 5.0.x (before 5.0.5), plus unsupported older branches.
• Disclosure and fix: Pivotal published the security advisory alongside the release of Spring Security 4.2.7 and 5.0.5, following Spring's standard practice of coordinating advisory publication with patch availability rather than disclosing before a fix exists.
• NVD record: CVE-2018-1199 was assigned and published to the National Vulnerability Database, where it remains catalogued with its CVSS v3 vector and a reference back to the Spring Security advisory and GitHub commit history for the fix.
• Downstream propagation: As with most framework-level CVEs, the practical remediation timeline extended well beyond the initial patch release, as the fix had to propagate through Spring Boot parent versions, internal artifact mirrors, and individual application upgrade cycles — the long tail that supply-chain tooling exists to shorten.

Remediation Steps

1. Upgrade Spring Security. Move to 4.2.7+ or 5.0.5+ (or, in any current project, to a supported and actively patched Spring Security line — running an 8-year-old minor version in 2026 carries far more risk from the accumulated CVEs since than from CVE-2018-1199 alone).
2. Audit CORS configuration independently of the version bump. Review every @CrossOrigin annotation and every CorsConfigurationSource bean for overly broad origin, method, or header allowances. A patched Spring Security version doesn't protect you from a CORS policy that's simply too permissive by design.
3. Don't rely on the filter chain alone for authorization. Defense in depth — re-checking authorization at the service or data-access layer, not just at the HTTP filter level — limits the blast radius of any future filter-chain bypass, whether it's this CVE or the next one.
4. Verify the fix reached you. Because Spring Security is almost always a transitive dependency, confirm the resolved version in your build output (mvn dependency:tree / ./gradlew dependencies), not just the version declared in your own pom.xml or build.gradle. BOM overrides and dependency management blocks can mask an outdated transitive version.
5. Check vendored and forked copies. Internal libraries, shaded JARs, and forked starter projects are the most common place this CVE quietly survives long after the "main" application stack has been upgraded.

How Safeguard Helps

CVE-2018-1199 is a textbook example of the class of risk that lives in dependency graphs rather than in code you wrote yourself — which is exactly the gap Safeguard is built to close. Instead of relying on developers to remember that Spring Security 5.0.x needs to be at least 5.0.5, Safeguard continuously inventories every dependency across your services — direct and transitive — and flags known CVEs like this one against the actual resolved versions in your build, not just the versions declared in a manifest.

For a CVE like this one, where severity is real but not critical and there's no KEV or high EPSS signal demanding an emergency patch, Safeguard's risk scoring helps teams prioritize correctly: surfacing it for remediation in the normal patch cycle rather than triggering unnecessary fire drills, while still ensuring it doesn't silently persist for years in a forgotten internal library or vendored fork. Combined with SBOM generation and provenance tracking, Safeguard gives security and platform teams a durable answer to the question that matters most for supply-chain risk: not just "are we vulnerable today," but "will we know the next time an old dependency like this resurfaces in a new service."