CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian's Confluence

Vulnerability Overview#

Confluence is a collaboration product developed by Atlassian, widely used for knowledge sharing, document collaboration, and centralized information storage.

CVE-2023-22515 is a privilege escalation vulnerability that allows an attacker to create a new administrator account in the following affected versions:

8.0.0 < Confluence < 8.2.3
Confluence < 8.3.3
Confluence < 8.4.3
Confluence < 8.5.2

Analysis#

Since this issue is already patched, I followed the usual workflow and diffed the changes. I used the 8.5.1 and 8.5.2 JARs for comparison:

![image-20231012132908575](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012132908575.png)

The notable change is that several classes were removed/added.

Removed:

ServerInfoAction
ServerInfoFilter

Added:

ReadOnlyApplicationConfig
ReadOnlySetupPersister

The two ReadOnly* classes extend existing classes and act as “hardened” wrappers: they throw UnsupportedOperationException on setters to prevent modifications, effectively making the objects read-only to reduce risk.

This is reflected in the BootstrapStatusProviderImpl change: the original this.delegate.getApplicationConfig(); becomes return new ReadOnlyApplicationConfig(this.delegate.getApplicationConfig());

![image-20231012141836976](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012141836976.png)

Next question: where are these properties being set? Looking at interceptors and the official description, SafeParametersInterceptor immediately stood out:

![](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012194917943.png)

![image-20231012153302736](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012153302736.png)

It injects form parameters into action properties, so this is very likely the relevant path. The interceptor contains a number of safety checks (especially around the @ParameterSafe annotation), and there is a doInterceptor implementation:

![image-20231012195013625](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012195013625.png)

I tried jumping to the parent class but my IDE couldn’t resolve it (Cannot find declaration to go to). I was lazy, so I searched the documentation and then checked the source on GitHub:

![image-20231012161818082](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012161818082.png)

![image-20231012160933343](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012160933343.png)

After reading the code, the issue becomes clear: after obtaining the action it only checks NoParameters and then calls setParameters:

![image-20231012162618100](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012162618100-1697122530365-2.png)

For Struts-style vulnerabilities, the usual processing chain is: interceptor → Action.

This XML defines an interceptor named params and binds it to com.atlassian.xwork.interceptors.SafeParametersInterceptor:

![image-20231012173735463](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012173735463.png)

Then we look for reachable trigger points. Searching for params yields something promising:

![image-20231012173531182](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012173531182.png)

![image-20231012173550112](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012173550112.png)

![image-20231012204057094](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012204057094.png)

After checking the stacks, it appears that any action not using setupStack is potentially usable (in my tests, only validatingStack or the default stack worked; other stacks were reachable but didn’t create the user, not sure why):

![image-20231012204203122](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012204203122.png)

That’s the end of the analysis.

Reproduction#

Set up a test environment:

![image-20231012114259263](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012114259263.png)

![image-20231012163733457](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012163733457.png)

The sqlserver version was too old, so I gave up on that path (just kidding).

I ended up using PostgreSQL instead:

![image-20231012172942216](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012172942216.png)

Once the initial setup page was reachable, I opened Burp and visited /setup/setupadministrator-start.action. It could no longer enter the registration flow:

![](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012204451547.png)

After overwriting the relevant properties and refreshing, the admin setup flow became available again:

![](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012210036843.png)

After the new admin is created, confirm the result:

![image-20231012205136650](./CVE-2023-22515 Critical Privilege Escalation Vulnerability in Atlassian’s Confluence/image-20231012205136650.png)

RCE has already been discussed by others. I plan to look for a more convenient route; if I find anything, I’ll write a follow-up.