ZeroPath at Black Hat USA 2026

Spring for GraphQL CVE-2026-41856: Overview of Authorization Bypass via Annotation Detection Failure in Type Hierarchies

A brief summary of CVE-2026-41856, a high severity authorization bypass in Spring for GraphQL where security annotations are silently ignored in controller type hierarchies. Includes patch details and affected version information.

CVE Analysis

10 min read

ZeroPath CVE Analysis
ZeroPath CVE Analysis

2026-06-11

Spring for GraphQL CVE-2026-41856: Overview of Authorization Bypass via Annotation Detection Failure in Type Hierarchies
Experimental AI-Generated Content

This CVE analysis is an experimental publication that is completely AI-generated. The content may contain errors or inaccuracies and is subject to change as more information becomes available. We are continuously refining our process.

If you have feedback, questions, or notice any errors, please reach out to us.

[email protected]

Introduction

A silently failing authorization layer is arguably worse than having no authorization at all, because it creates a false sense of security while leaving data exposed. CVE-2026-41856 is exactly that scenario: Spring for GraphQL's annotation detection mechanism fails to resolve security annotations on @Controller methods defined within type hierarchies, causing @PreAuthorize, @Secured, and similar authorization checks to be completely bypassed at runtime without any error or warning.

Spring for GraphQL is the official Spring integration for building GraphQL APIs in Java, jointly developed by the Spring team and the GraphQL Java team. Given Spring Boot's dominance in enterprise Java microservices, Spring for GraphQL is the default choice for organizations adding GraphQL endpoints to their Spring applications. This vulnerability, carrying a CVSS 7.5 (High) score, affects every release branch from the project's initial 1.0.0 GA through the latest 2.0.3, meaning no production deployment was safe prior to the June 10, 2026 patches.

Technical Information

Root Cause: Bridge Method Resolution Failure

The vulnerability's root cause lies in how Spring for GraphQL resolves annotations on @Controller data fetcher methods when those controllers participate in Java type hierarchies (extending abstract classes or implementing generic interfaces).

In Java, when a class implements a generic interface, the compiler generates synthetic "bridge methods" to preserve polymorphism after type erasure. For example, if an interface declares User fetchUser(Long id) and a concrete class implements it, the compiler may generate a bridge method with erased parameter types that delegates to the actual implementation. Spring for GraphQL's HandlerMethod bridged method matching logic is responsible for tracing these bridge methods back to the original declarations where annotations live.

The pre-patch code failed to correctly match the erased types of these bridged methods back to the original interface or abstract class methods that carried the security annotations. This meant that when Spring Security's @EnableMethodSecurity infrastructure asked "does this method have a @PreAuthorize annotation?", the framework answered "no" even when the annotation was clearly present on the interface or parent class method.

As documented in issue #1469, a scenario like the following would trigger the vulnerability:

interface UserController { User fetchUser(@Argument A arg1, @Argument B arg2); } abstract class AbstractUserController implements UserController { @Override public User fetchUser(Long arg1, C arg2) { } } class ConcreteUserController extends AbstractUserController { }

When resolving the handler method for ConcreteUserController, the framework would fail to find annotations on the parameters and, by extension, security annotations placed on the interface method, because the bridged method resolution did not correctly map back through the type hierarchy.

Three Required Conditions

The Spring advisory explicitly states that a Spring for GraphQL application is vulnerable only when all three of the following conditions are true:

  1. Spring Security is on the classpath: The application includes Spring Security as a dependency. Most production Spring Boot applications meet this condition.
  2. @EnableMethodSecurity is in use: The application activates method level security via this annotation, which is required for annotation based authorization on data fetchers.
  3. @Controller classes exist within a type hierarchy: Controller classes extend other classes or implement interfaces, which triggers the annotation resolution failure path.

If any one of these conditions is absent, the vulnerability is not triggered. However, the first two conditions are extremely common in enterprise Spring Boot deployments, making the third condition the key differentiator for actual exposure.

CVSS Vector Breakdown

The CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, which breaks down as:

MetricValueMeaning
Attack VectorNetwork (AV:N)Exploitable remotely via GraphQL HTTP endpoints
Attack ComplexityLow (AC:L)No specialized conditions required
Privileges RequiredNone (PR:N)No authentication needed
User InteractionNone (UI:N)No user action required
ScopeUnchanged (S:U)Impact confined to the vulnerable component
ConfidentialityHigh (C:H)Access to protected data fetchers exposes sensitive information
IntegrityNone (I:N)No data modification capability
AvailabilityNone (A:N)No denial of service capability

The vulnerability is classified under CWE-284: Improper Access Control, a pillar level weakness that encompasses failures in access control enforcement.

Attack Flow

An attacker would exploit this vulnerability through the following sequence:

  1. Reconnaissance: Identify a Spring for GraphQL endpoint, typically exposed at a path like /graphql. GraphQL introspection queries (if enabled) can reveal the schema, including data fetchers that would normally require authorization.
  2. Craft GraphQL queries: Send standard GraphQL queries targeting data fetchers that are backed by @Controller methods within type hierarchies. These are the methods where security annotations like @PreAuthorize("hasRole('ADMIN')") would normally gate access.
  3. Bypass authorization silently: Because the annotation detection mechanism fails to resolve the security annotations, Spring Security's method security interceptor never fires. The data fetcher executes as if no authorization constraint exists.
  4. Exfiltrate data: The attacker receives the full response from the data fetcher, accessing data that should have been restricted to authorized users only.

The attacker does not need to bypass authentication directly. Instead, the authorization layer silently fails to engage. This is particularly dangerous because application logs and monitoring may show no authorization failures, since from the framework's perspective, no authorization check was configured on the endpoint.

Co-occurring Vulnerabilities

CVE-2026-41856 was patched alongside two other Spring for GraphQL vulnerabilities in the same release cycle:

CVEDescriptionClassification
CVE-2026-41856Annotation detection bypass in type hierarchiesHigh (CVSS 7.5)
CVE-2026-41699Unsafe deserialization in paginated GraphQL queriesCritical (CWE-502)
CVE-2026-41700WebSocket session hijackingNot yet fully classified

An unpatched deployment may face authorization bypass, remote code execution through deserialization, and session takeover through WebSocket hijacking simultaneously.

Patch Information

On June 10, 2026, the Spring team released patched versions addressing CVE-2026-41856. The fix was implemented by Brian Clozel (bclozel) and backported across all supported branches.

The complete fixed version matrix from the official Spring advisory:

Affected VersionsFixed VersionAvailability
2.0.0 through 2.0.32.0.4OSS (Maven Central)
1.4.0 through 1.4.51.4.6OSS (Maven Central)
1.3.0 through 1.3.81.3.9Commercial (Broadcom/Tanzu)
1.0.0 through 1.0.61.0.7Commercial (Broadcom/Tanzu)

The fix corrects the HandlerMethod bridged method matching logic to properly walk the inheritance chain and resolve annotations on methods declared in parent classes and interfaces, even when bridge methods are involved due to type erasure. No configuration changes are required after upgrading.

Notably, version 1.4.6 is marked as the last open source release of the 1.4.x generation, with the 2.0.x line now being the actively maintained OSS branch. Users on the older 1.3.x or 1.0.x lines will need a Tanzu Spring commercial support subscription to access their respective patches.

The vulnerability was responsibly disclosed by Bofei Chen.

Important note: The GitHub Advisory (GHSA-phxq-526m-79px) marks patched versions as "Unknown" in the Dependabot ecosystem, meaning automated dependency update tools may not yet flag this CVE. Organizations should not rely on Dependabot alone and should manually verify their Spring for GraphQL version.

Additional Mitigation Considerations

For organizations that cannot immediately upgrade:

  • Apply HTTP URL security as a defense in depth layer: The Spring GraphQL security documentation states that "the path to a Web GraphQL endpoint can be secured with HTTP URL security to ensure that only authenticated users can access it." While this does not differentiate among different GraphQL requests on a shared endpoint, it provides a coarse grained barrier that limits exploitation to authenticated users only.
  • Restructure controller hierarchies: Since the vulnerability requires @Controller classes within type hierarchies, organizations could consider restructuring controllers to avoid inheritance patterns as a temporary workaround. This is not a replacement for patching.
  • Patch all three co-occurring CVEs: Given that CVE-2026-41699 and CVE-2026-41700 were patched in the same release, organizations should upgrade to address all three simultaneously.

No official workaround has been published by the Spring team.

Affected Systems and Versions

The vulnerability affects all releases of Spring for GraphQL from the project's initial GA through the versions immediately preceding the patches:

  • Spring for GraphQL 2.0.0 through 2.0.3
  • Spring for GraphQL 1.4.0 through 1.4.5
  • Spring for GraphQL 1.3.0 through 1.3.8
  • Spring for GraphQL 1.0.0 through 1.0.6

A deployment is vulnerable only when all three conditions are met:

  1. Spring Security is present on the classpath
  2. The application uses @EnableMethodSecurity for authorization
  3. @Controller classes are implemented within type hierarchies (extending abstract classes or implementing interfaces)

Applications that do not use Spring Security, do not use method level security annotations, or define all controller methods directly on concrete classes without inheritance are not affected.

Vendor Security History

Spring's security track record reveals a recurring pattern of annotation detection failures alongside other notable vulnerabilities:

YearCVE(s)Issue
2022CVE-2022-22965 (Spring4Shell)Remote Code Execution via data binding
2025CVE-2025-41248, CVE-2025-41249Method level security annotation detection failure in Spring Security
2025CVE-2025-22228Authentication bypass in spring-security-crypto
2026CVE-2026-41856, CVE-2026-41699, CVE-2026-41700Annotation detection bypass, deserialization, WebSocket hijacking

The CVE-2025-41248 and CVE-2025-41249 pair is particularly relevant. Those vulnerabilities affected Spring Security 6.4.0 through 6.4.9 and 6.5.0 through 6.5.3, and involved the same class of failure: the framework failing to detect method level security annotations, leading to authorization bypass and exposure of sensitive data. The recurrence of this pattern across Spring Security and now Spring for GraphQL suggests a systemic challenge in how the Spring ecosystem resolves security metadata in complex class hierarchies.

Broadcom's response through the June 2026 update, described as the largest Spring security update ever, signals institutional investment in security. However, the fact that CVE-2026-41856 affects every version from 1.0.0 onward underscores that even well maintained frameworks can carry latent security defects for years before discovery.

Threat Intelligence

As of June 11, 2026, there is no confirmed evidence that CVE-2026-41856 is being actively exploited in the wild. The CVE does not appear on the CISA Known Exploited Vulnerabilities Catalog, and no public proof of concept exploit code has been identified.

However, several factors warrant attention:

  • The CVSS attack complexity is Low and requires no privileges, meaning exploitation is straightforward once a vulnerable endpoint is identified.
  • Spring's dominance in enterprise Java makes it a high value target. Spring4Shell demonstrated that Spring vulnerabilities attract rapid weaponization by threat actors.
  • Recent precedent from other ecosystems shows exploitation windows shrinking dramatically. CVE-2026-33626 in LMDeploy was exploited within 12 hours of disclosure.
  • The 2026 VulnCheck Exploit Intelligence Report found that while only approximately 1% of 2025 CVEs were exploited in the wild, Spring related CVEs have historically exceeded this average due to their wide deployment surface.

No specific threat actor attribution exists for this vulnerability at this time. Organizations should monitor threat intelligence feeds and the CISA KEV catalog for updates.

References

Detect & fix
what others miss

Works with
  • GitHub
  • GitLab
  • Bitbucket
  • Azure DevOps Services
  • Jira
  • Linear
  • Slack
  • Security Compass
Security magnifying glass visualization