Spring Boot Authentication Bypass: Two New CVEs That Enterprise Teams Cannot Afford to Ignore ( CVE-2026-22731, CVE-2026-22733)

Somewhere in your production environment, there is likely an endpoint that is supposed to require authentication. These two new Spring Boot security issues mean that locks may not be engaged. Unauthenticated HTTP requests can reach protected application endpoints in certain Spring Boot Actuator configurations silently, without error, and without any indication the protection failed. No credentials. No exploit chain. Just a request that should have been blocked, and wasn't.

If your applications run Spring Boot with Actuator and Spring Security on the classpath, your security posture may have changed on March 19, 2026 — the day CVE-2026-22731 and CVE-2026-22733 were disclosed. Your vulnerability scanners already know. Your next compliance audit will ask about it.

‍

These vulnerabilities impact different parts of the Spring Boot ecosystem. CVE-2026-22731 affects Spring Boot 3.4.x and later, while CVE-2026-22733 has a broader impact across both 2.x and 3.x versions.

‍

For teams running end-of-life versions of Spring Boot, such as 2.7.x and certain 3.x releases, the upstream Spring project does not provide open-source patches. NES for Spring delivers fixes for affected EOL versions as drop-in replacements, with zero code changes required.

What Are These Vulnerabilities?

CVE-2026-22731 and CVE-2026-22733 are closely related Spring Boot authentication bypass flaws. In each case, Spring Boot's security filter chain fails to enforce authentication on application endpoints that share a path prefix with Actuator infrastructure paths.

CVE-2026-22731 triggers when a custom Actuator health group is mapped to an additional server path, say, /healthz, and the application also exposes an authenticated endpoint under a subpath like /healthz/admin. Spring Boot applies the Actuator's permissive policy to the entire prefix, silently dropping the authentication requirement on the application endpoint.

CVE-2026-22733 is the same failure, but through the CloudFoundry Actuator path (/cloudfoundryapplication). Application endpoints declared under that prefix bypass authentication in identical fashion.

Both share the same CVSS 3.1 vector (8.2 HIGH Score): AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N. Network-accessible, no privileges required, no user interaction, confidentiality impact rated High. Disclosed the same day, by the same researcher — this is a pattern in the framework, not an isolated edge case.

Why This Matters Beyond the Security Team

This Spring Boot vulnerability is not a background ticket. It is an operational problem with consequences across your entire organization.

Your release pipeline may already be blocked. Scanners like Snyk, Tenable, and Veracode indexed these CVEs immediately after disclosure. If your CI/CD pipeline enforces severity thresholds and most enterprise pipelines do, High findings are already surfacing. Unresolved, they block deployments and trigger escalation paths that pull engineering and leadership into triage cycles that were not in anyone's sprint plan.

Your audit window is at risk. SOC 2, PCI DSS, HIPAA, and FedRAMP all require timely remediation of known vulnerabilities. An unpatched Spring Boot authentication bypass in production with documented disclosure and no remediation record is precisely the finding that stalls an audit or forces a written exception with a committed remediation date.

Engineering absorbs the blast radius. When a security finding blocks a release, the cost does not stay in the security column. Sprint plans shift, release dates slip, and engineers context-switch from feature work to remediation triage. The organizational friction of managing an unresolved High CVE compounds quickly across teams.

The business exposure is concrete. An unauthenticated attacker reaching a protected endpoint can extract sensitive data, probe internal APIs, or establish a foothold for further exploitation. In regulated industries, unauthorized data access carries breach notification obligations, regulatory penalties, and customer trust consequences that far exceed the technical incident itself.

Who Is Affected

‍

‍

Spring Boot 3.3.x and 3.4.x have commercial fixes, but only through an active Broadcom Enterprise Support agreement. However, Spring Boot 3.2.x is also affected by CVE-2026-22733 and has no commercial support path available, leaving teams without an upstream or vendor-backed remediation option.

‍

Additionally, for Spring Boot 2.7.x, the final open-source release was 2.7.18 with no ongoing OSS or commercial support beyond that point.

‍

For organizations without Broadcom coverage, or running versions outside that support window, NES for Spring is the actionable path.

Why Upgrading Is Not a Short-Term Fix

The standard advice is simple: upgrade to the patched version. For teams on Spring Boot 4.0.x or 3.5.x, that is the right answer — those patches are available today. For everyone else, that guidance describes a project measured in months, not a fix measured in days.

Migrating from Spring Boot 2.7.x to 3.x requires adopting Jakarta EE namespaces, resolving Spring Framework 6.x breaking changes, and validating compatibility across every dependency in the tree. Even well-maintained codebases absorb that effort over quarters, not sprints. Compounding the challenge, the remaining 3.x line is itself approaching the end of open-source support. For many teams, moving from 2.7.x to 3.x is not a long-term solution, but an intermediate step on the path to Spring Boot 4.0. In practice, that means organizations are being asked to execute multiple major upgrades in sequence, each with significant engineering and validation overhead.

Teams cannot pause a product roadmap to complete a major framework migration under a 30-day remediation SLA let alone plan for another shortly after. This is a structural challenge that runs across the enterprise Java ecosystem, and it repeats for a predictable reason. The open-source model patches the current version and expects the ecosystem to follow. That model works for greenfield applications with dedicated platform teams. It does not work for production systems that have run for years, carry significant integration surface area, and are staffed by teams whose mandate is to ship features, not maintain framework currency. The result is a permanent population of enterprise applications on EOL software, under active security pressure, with no realistic path to an immediate upstream fix.

Security SLAs do not pause for migration timelines. That gap is exactly what HeroDevs is built to close.

How CVE-2026-22731 and CVE-2026-22733 Work: Technical Breakdown

Both vulnerabilities exploit the same failure in Spring Boot's Actuator security filter chain. When an Actuator infrastructure path and an application-contributed endpoint share a path prefix, Spring Boot resolves security policy in favor of the Actuator's permissive configuration, and the application endpoint's authentication requirement is quietly discarded.

The failure is silent. Requests are processed normally, responses are returned, and nothing in the application logs indicates that authentication was skipped. Tests that only validate response status codes will not catch it. Detection requires explicitly asserting that authentication challenges are issued on protected endpoints — a test that is frequently absent from legacy test suites.

While this configuration is generally not recommended, large production codebases often accumulate legacy or inconsistent settings over time. In distributed environments, ‘not recommended’ does not always mean ‘not present’ which is what makes this vulnerability particularly relevant.

The HeroDevs Solution

When your security team sets a remediation deadline on a High CVE, two things need to happen: the vulnerability needs to be fixed, and the fix needs to be documented for your scanner, your auditor, and your compliance framework. A multi-month Spring Boot migration cannot accomplish either on that timeline.

NES for Spring delivers backported security patches, including fixes for CVE-2026-22731 and CVE-2026-22733, for EOL Spring Boot versions as drop-in replacements. No new APIs. No breaking changes. No refactoring. Your application continues running on the same version it runs on today, with patched binaries replacing the vulnerable components.

The contrast is straightforward: a major version migration takes months and carries real risk of regression. NES takes minutes and is designed to minimize disruption. Your security team gets scanner clearance and compliance documentation. Your engineering team keeps shipping. Your leadership team avoids an unplanned migration consuming a quarter of engineering capacity.

NES is not a substitute for modernization — it is the bridge that makes modernization possible on your terms, planned and resourced rather than forced by a compliance deadline.

How to Fix CVE-2026-22731 and CVE-2026-22733

If you are on Spring Boot 4.0.x or 3.5.x: Upgrade to 4.0.4 or 3.5.12. These are OSS releases, available now on Maven Central. No commercial agreement required. Upgrade immediately.

If you are on Spring Boot 2.7.x, 3.2.x, 3.3.x, 3.4.x (without Broadcom support), or any older EOL version: There is no OSS patch. NES for Spring is your path to immediate, verifiable remediation, backported fixes, zero code changes, compliance documentation included.

Conclusion

CVE-2026-22731 and CVE-2026-22733 are on your scanner today. Your remediation clock is running. For teams on supported Spring Boot versions, the fix is a version bump — take it now. For everyone on EOL versions, the upstream project has nothing for you, and a major migration is not something you can complete before your next audit, your next deployment gate, or your next customer security review.

There is no runway here to wait on. NES for Spring delivers the fix for these Spring Boot authentication bypass vulnerabilities on the version you are actually running, in minutes, not months. Your compliance posture is restored. Your team keeps moving. And your migration happens when you are ready, not when a CVE forces your hand.

Don't let an EOL version define your security outcome. Talk to the HeroDevs team and get protected today.

‍