Critical flaw in Spring Authorization Server (CVE-2026-22752): a crafted client registration can lead to impersonation and data theft — update to 7.0.5 / 1.5.7

A high-severity flaw (CVE-2026-22752) has been disclosed in "Spring Authorization Server," a widely used foundation for login (authorization) integration in enterprise systems. Its severity is 9.6 on the CVSS scale — the common yardstick that rates a flaw out of 10 — placing it in the top "Critical" band.

Spring Authorization Server is part of "Spring," a Java development foundation adopted by many web services and apps, and it is the component used to build an authorization server for secure login integration with external services (OAuth2 / OpenID Connect). When this authorization server has a certain feature enabled, the flaw can be abused by an attacker and lead to impersonation and data leakage.

That said, it is not something anyone can exploit unconditionally. Exploitation requires two preconditions, and the systems that meet them are limited. No real-world attacks have been reported yet, but now that the details are public, affected systems should act early. We explain what happens, whether your system is affected, and how to fix it — in order. Because open-source components can end up bundled without your noticing, the mindset of OSS supply-chain checking also helps when reviewing dependencies.

What happens

In one sentence: when the authorization server has a "window for freely registering apps from outside" (Dynamic Client Registration) open, that window's input checks are too loose, and crafted data can be pushed through it.

The key is a feature called "Dynamic Client Registration." Normally, the apps (clients) that integrate with an authorization server are registered in advance by an administrator. Dynamic Client Registration, by contrast, lets apps be registered automatically from outside once a defined procedure is followed, and it is used by services that handle many integration partners. Only when this dynamic client registration mechanism (RFC 7591) is deliberately enabled is a system affected by this flaw. It is disabled by default, so systems that have not turned it on are out of scope.

Who targets this, and why

The party that can exploit this is someone holding a legitimate "initial access token" — the voucher required to use Dynamic Client Registration. A complete outsider cannot suddenly abuse it; the scenario involves a user allowed into the registration process, or an attacker who obtained a leaked voucher. The more broadly a service accepts integration partners, the wider the pool of people holding that voucher.

What that party does is register a crafted app so that a malicious script runs in the browser of whoever views the admin screen, perform actions beyond their real privileges, or make the server quietly connect to another location. An authorization server is the hub that decides "who is allowed to log in," and shaking it can escalate into impersonated logins or probing into an internal network.

The danger of this flaw is that harm does not stop with the authorization server's administrator. Because the authorization server ties together the logins of many users of a service, a takeover puts those ordinary users' accounts and personal data at risk too. Since the "foundation of authentication and authorization" collapsing has such a wide blast radius, it carries a severity of 9.6.

A technical look

According to the security advisory published by Spring, the root cause is that the Dynamic Client Registration endpoints did not sufficiently validate the client metadata sent at registration time (accompanying information such as the app name and integration URLs).

An attacker holding a valid initial access token can register a client with malicious values embedded in that metadata. As those values are displayed and used on the authorization server's admin or consent screens, they can lead to three impacts. First, Stored Cross-Site Scripting (Stored XSS), where a malicious script runs in the browser of whoever opens the admin screen. Second, privilege escalation, allowing actions beyond one's proper privileges. Third, Server-Side Request Forgery (SSRF), where the server is made to connect to an internal location of the attacker's choosing.

SSRF in particular tends to become a doorway into internal systems that cannot be reached directly from outside, and it risks being used as a foothold to probe the inside of the network where the authorization server sits. Each is a combination of the classic weakness of "trusting input and processing it," but because it occurs at the core of authentication and authorization, the impact is large.

Affected versions and fixes

The affected range and fixes are as follows. Check which version line your system uses, and update to the fixed version on the right. Note that the fixes for the 1.3.x and 1.4.x lines are provided to holders of a commercial Spring Enterprise subscription.

If you are on OSS and still on the 1.3.x or 1.4.x line, the fix is not offered for free, so you will need to consider moving to a still-supported line (1.5.x or 7.0.x). If there are reasons you cannot update right away, the interim workaround is "disabling Dynamic Client Registration," covered in the next section.

What to do right now

The response is broadly two-tiered. First, determine whether your system is affected at all. Only systems that use Spring Authorization Server and have Dynamic Client Registration enabled are actually exposed. Many systems do not use dynamic registration, and in that case there is no need to panic.

If you are affected, the best move is to update to a fixed version (7.0.5 or 1.5.7; Enterprise subscribers, 1.4.10 or 1.3.11). As an interim workaround when you cannot update immediately, if it is not operationally required, disabling Dynamic Client Registration effectively closes this flaw. The vendor also states that no additional mitigation steps beyond updating are necessary.

Easy to overlook is the case where you do not use it directly, but Spring Authorization Server is pulled in inside another library or product. Open-source components can be buried deep in a dependency tree and hard to notice. If you are unsure about the makeup of the software you run, it is reassuring to also review it from the angle of listing out dependencies, as in OSS supply-chain checking. A flaw in the related Spring AI has also been reported before, and regular patching is essential wherever Spring is used.

Bottom line

CVE-2026-22752 is a flaw that exploits loose input checks in Spring Authorization Server's Dynamic Client Registration. Although the severity is a high 9.6, exploitation requires two preconditions — "Dynamic Client Registration is enabled" and "the attacker holds a valid initial access token" — so the systems in scope are limited. The starting point is to confirm whether your system meets these conditions.

If it does, updating to a fixed version (7.0.5, 1.5.7, and so on) is the top priority. When you cannot move right away, disable dynamic registration temporarily to get through the crunch, then proceed with updates on a plan. No real-world attacks have been confirmed yet, but because this flaw touches the foundation of authentication and authorization, affected systems are wise not to defer it. We will add to this article as new information or attacks are confirmed.

Sources

• ▸ Spring official security advisory - CVE-2026-22752
• ▸ NVD - CVE-2026-22752
• ▸ Daily CyberSecurity - Spring Security 7.0 vulnerabilities explained
• ▸ GBHackers - Critical Spring Authorization Server Issue Exposes Systems to XSS and SSRF