Ahmed ElSayed: As a general rule - if you have any indication your installation has been compromised by any means, you must reset your installation. Patches usually only help to prevent the initial exploit to happen, once you have been hacked, they won't help. If I read the article correctly, the exploit still needs CVE-2023-22515 which if unpatched will give you admin priviledge on your instance - once that has happened all bets are off. I wouldn't consider this to be a new exploit.

Hi arestaut,

We are having the same errors as yourself.
When we try this in non-prod, our instance is not coming up at all.

Did you face the same problem? or you are able to bring up the application with these changes successfully?

Hello Atlassian team,

No update on my comments about the proposed mitigation that seems uneffective?

Hi everyone. Since many articles say that "the vulnerability cannot be used for data leakage", that is not 100% true.

We noticed that when you reset confluence with this CVE the %CONFLUENCE_HOME%/attachments directory is still full of files, there may be thousands of them. It is pretty easy to extract all of them and then determine their extensions with Linux `file` command.

For example:

file /var/lib/confluence/attachments/v4/191/28/77273124/77273124.1
/var/lib/confluence/attachments/v4/191/28/77273124/77273124.1: PNG image data, 442 x 170, 8-bit/color RGBA, non-interlaced

We are not sure that the hackers do steal the files before running the ransomware and crypting the files, but you can investigate network activity to see any outbound traffic in your particular case.

That's exactly my understanding, but it's difficult to make sure:

• That's why I'm asking directly here.
• If the provided mitigation does the exact opposit (remove all access methods from protection) of what is needed here, it's kind of serious, isn't it ?

Please @Atlassian team, can you confirm the mitigation steps are correct ?

@arestaut: Indeed from my understanding it looks like this block would remove all access methods from protection, which is probably not the intended result - shouldn't it be just

<http-method>*</http-method>

or just no specification whatsoever?

See https://javaee.github.io/tutorial/security-webtier002.html

• http-method or http-method-omission is used to specify which methods should be protected or which methods should be omitted from protection. An HTTP method is protected by a web-resource-collection under any of the following circumstances:
• If no HTTP methods are named in the collection (which means that all are protected)

• If the collection specifically names the HTTP method in an http-method subelement

• If the collection contains one or more http-method-omission elements, none of which names the HTTP method

Hi Atlassian Team,

We have upgraded our Confluence in 7.19.16. Please confirm, our Confluence is safe from this vulnerability ''CVE-2023-22518'' now ? or do we need to take any more action? For eg: need to add any patch or something.

Also, after upgrade any plugin is vulnerable or Confluence is vulnerable due to any plugin?

Please confirm.

Thanks,
Amit

Hello,

Outdated Confluence Server admin here. I tried to apply the "interim measures to mitigate" and patched my web.xml file. Then restarted the Confluence Tomcat, and here is what I found in the atlassian-confluence.log:

2023-11-08 10:22:08,629 ERROR [localhost-startStop-2] [ContainerBase.[Standalone].[localhost].[/Confluence]] log For security constraints with URL pattern [/json/setup-restore.action] the HTTP methods [*] are uncovered.
2023-11-08 10:22:08,632 ERROR [localhost-startStop-2] [ContainerBase.[Standalone].[localhost].[/Confluence]] log For security constraints with URL pattern [/json/setup-restore-progress.action] the HTTP methods [*] are uncovered.
2023-11-08 10:22:08,632 ERROR [localhost-startStop-2] [ContainerBase.[Standalone].[localhost].[/Confluence]] log For security constraints with URL pattern [/json/setup-restore-local.action] the HTTP methods [*] are uncovered. 

I tried to look for the <http-method-omission> possible values on the web and couldn't find anything relevant.

Can you confirm the mitigation listed on top of this issue is working ? Is it normal I have these ERROR in my log?

Can somebody please explain - for 4 or more years issue was not found.

Then it is found and after few days, someone has used this vulnerability.

Conclusion  - this was an advertisement? Seriously, I am confused.

Also Ars Technica article mentions data exfiltration and lateral movement after exploit.

Are you at Atlassian sure that your statement about no data exfiltration holds?

https://arstechnica.com/security/2023/11/critical-vulnerability-in-atlassian-confluence-server-is-under-mass-exploitation/

As described by my colleague @Emanuel in the Atlassian partner page for this CVE (not everyone will have access to this though): 

 

1. This vulnerability is exploited in the wild by now!
   1. You also mentioned that there is a active exploit in the update from Nov 3, 2023
      1. “We received a customer report of an active exploit ** […]“
2. Attacker can exfiltrate instance data (in form of attachments)
   1. Attacker uses security vulnerability to upload customized XML with Admin user
      1. Instance data inside DB gets overwritten
      2. Attachments are not affected by the restore process and are left intact
   2. Attacker uses Admin user to install customized plugin (which opens/contains a remote shell)
      1. Attacker uses this shell to transfer attachments

Is this vulnerability related to CVE-2023-22515, specifically to the command bootstrapStatusProvider.applicationConfig.setupComplete=false?

So, if the status is not false, you can't initiate the setup so that it will stop the above vulnerability. Or restore didn't require the flag.

My personal understanding is that you use Feature Release/Non-LTS when you can update at short notice.
For me, feature releases are short-lived versions.

Confluence 7.20.0 was release 4 October 2022, more than 12 months ago.

What kind of support then exists until the EOL in October 2024, if you even do not provide security updates?

Hi @james Ponting,

Please update the CVE bulletin to reflect your below statement. The fixed version column says "7.19.16 or later" which is misleading

Confluence 7.19.16 is a safe version. Please note that no versions of Confluence 7.20 contain these fixes.

Because of this missing info in CVE bulletin, we had to upgrade our production instance twice. 7.x -> 7.20.x -> 8.x.y

Hi All,

Just replying to a couple of additional comments.

Please see previous question and answer comments at

• Initial comment
• Follow up comment 1

b0a542f84953

Can you explain, why no fix for 7.20.3 exists? According to following page, version 7.20 still has support until 4 Oct 2024:

https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html

The above policy relates to Atlassian Support (the support team). This extract is from the page you've linked, explaining this difference (emphasis added)

Atlassian supports feature versions for two years after the first major iteration of that version was released (for example, we support Jira Core 7.2.x for 2 years after Jira 7.2.0 was released).

For versions that are supported, customers can raise issues via https://support.atlassian.com. If a bug is discovered, it will be prioritized based on our Bug Fixing Policy and may require you to upgrade to the version which includes the fix. For critical security bugs, please see our Security Bugfix Policy on which versions we will backport critical security fixes.

You can review our security bug fix policy at Security Bugfix Policy - Atlassian. For convenience, the relevant part is

Issue new bug fix releases for:

• Any versions designated an 'Long Term Support release' that have not reached end of life.
• All feature versions released within 6 months of the date the fix is released.

Confluence 7.20.0 was release 4 October 2022, more than 12 months ago.

71be91585e71

Is it feasible to take a backup from 7.20.0 and read it on a Confluence machine with version 7.19.16?

Thx, Paul

Unfortunately not due to compatibility reasons. Users of Confluence 7.20 should upgrade to a fixed version of Confluence 8.

27daaf800950

> Note: These mitigation actions are limited and not a replacement for patching your instance; you must patch as soon as possible

Could you elaborate on this? Does it make the instance safe or not?

Please upgrade your instance with urgency commensurate with the severity of the announced vulnerability.

Upgrade now.

44af37692e1b

Can you confirm the information in https://github.com/ForceFledgling/CVE-2023-22518 is complete and correct?

If so, we were not vulnerable, which was however not possible to understand from the very limited information shared by Atlassian. Out of fear, uncertainty and doubt we updated quickly to a poorly tested 7.19.16 version and are facing severe issues with the file descriptor leaks ever since. Not happy. Atlassian support finally started to be constructive only today - after two days since we logged the incident with them.

I have not reviewed the findings in the link you've provided, but would note the README.md states that "all versions are affected".

I can confirm that all versions of Confluence listed as affected versions on CVE-2023-22518 - Improper Authorization Vulnerability In Confluence Data Center and Server are affected.

Thanks,
James Ponting
Engineering Manager - Confluence Data Center

Can you confirm the information in https://github.com/ForceFledgling/CVE-2023-22518 is complete and correct?

If so, we were not vulnerable, which was however not possible to understand from the very limited information shared by Atlassian. Out of fear, uncertainty and doubt we updated quickly to a poorly tested 7.19.16 version and are facing severe issues with the file descriptor leaks ever since. Not happy. Atlassian support finally started to be constructive only today - after two days since we logged the incident with them.

Note: These mitigation actions are limited and not a replacement for patching your instance; you must patch as soon as possible

Could you elaborate on this? Does it make the instance safe or not?

Is it feasible to take a backup from 7.20.0 and read it on a Confluence machine with version 7.19.16?

Thx, Paul

Can you explain, why no fix for 7.20.3 exists? According to following page, version 7.20 still has support until 4 Oct 2024:

https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html

Thank you, James. I also remember issues with an h2 CVE and the resulting upgrade issues in our Spring projects. Since we only use it for testing, we did not upgrade h2. We are now moving to Testcontainers with Postgres. This is the reason why h2 is never recommended for more than testing.

So if you add the (vulnerable) h2 driver, it should work, but I think you have to stay on 1.4 because 2.x will cause compatibility errors.

Hi All,

Just replying to a couple of additional comments.

Please see this comment for additional questions and answers.

eae43f3df324

CC: bd5310009274 | 86b6336aa0d9 | 44af37692e1b

"H2 databases are not intended for production use. Please reach out to Support via https://support.atlassian.com if you need assistance here."

I beg your pardon??? Are you kidding me - has it become company policy to destroy working configurations in the LTS branches? The purpose of an LTS branch is to provide updates with the guarantee of not removing any functionality. Especially not if there isn't a good reason for it! I have a strong feeling that I could just readd the H2 jar.

This is unbelievable. And yes we do have a good reason to use H2 in our setup, and anyway you are forcing customers to do a potentially major infrasructure change to be able to apply an absolutely critical security update.

We were actually considering to migrate our server instances (we are using multiple instances of nearly all your product line) to DataCenter, even though the price increase is ridiculous. However the absolutely botched handling of this incident (not only this specific issue, but also the communication and the other issues cropping up here, as well as the severity of the incident in itself), have finally convinced us to move away from your company as quickly as possible.

we are still on 7.19 LTS and have intended to stay there as long as possible, while preparing a migration to other technologies. This is a testing and public demonstration instance for which the limited capabilities of H2 have been absolutely sufficient. H2 is still listed as a compatible platform for 7.19, and while it is not intended for production use, just ripping it out on an LTS branch is a no go - it also makes me wonder what other functionality has been messed up in this release.

Is there any specific reason to have removed this?

I understand the frustration this may have caused you.

You can find the details of database support on our Supported Platforms page. The functionality in question may have worked but was not supported in this release, and was marked as deprecated.

The change in question was introduced in Confluence 7.19.10 which was release 19 June 2023. It was in response to two critical vulnerability disclosures in the h2 database and we were unable to upgrade due to compatibility reasons.

• https://security.snyk.io/vuln/SNYK-JAVA-COMH2DATABASE-2331071 - 9.8 Critical (since decrease to 8.1 by some vendors)
• https://security.snyk.io/vuln/SNYK-JAVA-COMH2DATABASE-2348247 - 9.8 Critical

As bd5310009274 noted, although we do not recommend it, you can restore the h2 database jar file to the Confluence class path in order to restore this functionality. Please be aware this could introduce additional risk.

If you need additional assistance with anything, please reach out to Support via https://support.atlassian.com.

Thanks,
James Ponting
Engineering Manager - Confluence Data Center

Thank you for the explanation, Jasmine. For me, this sounds like a valid use case. Confluence 7.19.16 still ships atlassian-h2-server-integration-3.0.2.jar so it looks like its not fully removed.
Simply adding the h2.jar to the Classpath should do the trick (org.h2.tools.* comes from the h2.jar)

@Atlassian
This sounds like an unintentional change for the 7.19 LTS Branch?

Confluence 7.20.0 is a safe version?

If not then what version do we need to upgrade/patch to?

Patrick,

we are still on 7.19 LTS and have intended to stay there as long as possible, while preparing a migration to other technologies. This is a testing and public demonstration instance for which the limited capabilities of H2 have been absolutely sufficient. H2 is still listed as a compatible platform for 7.19, and while it is not intended for production use, just ripping it out on an LTS branch is a no go - it also makes me wonder what other functionality has been messed up in this release.

Is there any specific reason to have removed this?

"H2 databases are not intended for production use. Please reach out to Support via https://support.atlassian.com if you need assistance here."

I beg your pardon??? Are you kidding me - has it become company policy to destroy working configurations in the LTS branches? The purpose of an LTS branch is to provide updates with the guarantee of not removing any functionality. Especially not if there isn't a good reason for it! I have a strong feeling that I could just readd the H2 jar.

This is unbelievable. And yes we do have a good reason to use H2 in our setup, and anyway you are forcing customers to do a potentially major infrasructure change to be able to apply an absolutely critical security update.

We were actually considering to migrate our server instances (we are using multiple instances of nearly all your product line) to DataCenter, even though the price increase is ridiculous. However the absolutely botched handling of this incident (not only this specific issue, but also the communication and the other issues cropping up here, as well as the severity of the incident in itself), have finally convinced us to move away from your company as quickly as possible.

Is there a way to identify an attack in the logs?

Based on many comments here, it seems this issue is related to Java vulnerability and file descriptor (open file) in Linux. As we are aware, the file descriptor concept is different between Linux and Windows. As a simple conclusion, you can't trigger file descriptors the same as Linux in Windows Server.  Can Atlasian engineer confirm if this vulnerability is related to this topic (Java and file descriptor)? 

Below are the detail comparison between Windows and Linux file descriptor management.

In both operating systems, file descriptors are low-level handles that represent open files, pipes, sockets, and other resources. They are used by applications to access these resources.

However, Linux uses simple integers for file descriptors, while Windows uses a more complex data type called "HANDLE." This is because Windows needs to store more information about each file descriptor, such as the security context and the process ID.

Another difference is that Linux uses an event notification mechanism called epoll to handle file descriptors efficiently. Epoll allows an application to register file descriptors for events such as read readiness and write readiness. The application is then notified when one of the registered file descriptors is ready for I/O.

Windows Server uses a similar mechanism called IOCP (Input/Output Completion Ports). IOCP allows an application to initiate an I/O operation and then be notified when the operation is complete. This allows a small set of worker threads to handle many I/O operations asynchronously, providing an efficient model for managing large numbers of simultaneous connections or I/O-intensive tasks.

Here is a table that summarizes the key differences between file descriptor management in Windows Server and Linux:

drive_spreadsheetExport to Sheets
Overall, file descriptor management in Windows Server and Linux is similar. However, there are some key differences, such as the use of different data types for file descriptors and different event notification mechanisms.

Which operating system is better for file descriptor management depends on your specific needs. If you need to handle a large number of concurrent connections or I/O-intensive tasks, then Windows Server's IOCP mechanism may be a better choice. If you need a more lightweight and flexible solution, then Linux's epoll mechanism may be a better choice.

Hi All,

I'm going to provide some answers to questions in here, to try and keep things moving.

General Questions

What versions are impacted?

If you are running a version of Confluence not on the "Fixed Versions" list, you are vulnerable and must immediately take the actions listed at CVE-2023-22518 - Improper Authorization Vulnerability In Confluence Data Center and Server.

All prior versions are vulnerable. Upgrade now.

Are there additional mitigations or workarounds?

The source of truth for mitigations and workarounds is CVE-2023-22518 - Improper Authorization Vulnerability In Confluence Data Center and Server.

Please monitor this page for updates as we will post them there.

What if I'm running SSO or 2FA?

Neither of these mitigations is currently available. Please see the above response.

I'm on Confluence 7.20.x. What should I do?

You will need to upgrade to a fixed version of Confluence 8.

Specific Questions

24bbed8b71ce

When are the docker images 7.19.16 going to be available.

You are asking users to go to a version that doesn't have a docker or helm deployment for.

This has since been rectified.

We had immediately kicked off the creation of these images, however we were sending so many things to Docker Hub that we were getting throttled by multiple systems. We'll need to look at this for future incidents.

27daaf800950

Guys, is it really too hard to explain what exactly is being abused and how so that we could filter requests out on our proxy? We did that with 2023-22515 where you did described at least one attack vector (and we needed to figure out the other one)...

We understand your frustration with the limited information we're able to share regarding the vulnerability details and always aim to be as transparent as possible so our customers can best inform their security approach. At this time, we're unable to disclose the details you've requested without putting added risk on instances that have not yet been patched.

Our priority is protecting our customers' data, and we appreciate your understanding. We will share more information about the vulnerability as soon as it is safe to do so.

dd587efd2042

Does Atlassian or anyone know how attacker take advantage of this Vulnerability? and if there is any mitigations action we can take as we are running a super big instance (unlimited user) and also publish on internet so it would take much time to upgrade.

With regards to the first part of the question, please the the CISO's comment on CVE bulletin.

You need to upgrade. We do support upgrading without downtime via Upgrade Confluence without downtime.

2ec6c2802944

We are using the 7.13.8 version and in the next 2 months we are moving to another platform and now our instance is exposed to the Internet. and we don't have the license what do we need to do?
Is an upgrade still required?
for an upgrade, we first need to go for the 7.17.1 version and thereafter we need to do an upgrade if is renewal required here.

You'll need to reach out to our Support team via https://support.atlassian.com.

eae43f3df324

Upgrade to 7.19.16:

contextInitialized An error was encountered while bootstrapping Confluence (see below):
java.lang.NoClassDefFoundError: org/h2/tools/Server

Please tell me you haven't removed H2 support for this critical bugfix!!!

EDIT: Yes you have!!! Please undo this ASAP aka NOW!

H2 databases are not intended for production use. Please reach out to Support via https://support.atlassian.com if you need assistance here.

641bf4342896

is it by any means, possible that you changed the web.xml in confluence/web-inf to the "new" 8.5.x format while in the 7.19.x LTS range?

in a high risk update? srsly?

The current format has been in place since Confluence 7.15.0 as I understand. There are changes in the file since then, but the format has remained the same. There may be some misalignment here.

8943d5bd9843

To avoid confusion, I'm not quoting your question here. You have linked to a previous CVE announcement. Please see CVE-2023-22518 - Improper Authorization Vulnerability In Confluence Data Center and Server.

b881c4428b3b

Does it help if we put confluence instance behind, e.g. Cloudflare Web Application Firewall?

No as that would leave the application available on the internet. Please see CVE-2023-22518 - Improper Authorization Vulnerability In Confluence Data Center and Server.

44af37692e1b | 38f2f35e1866

We have updated to 7.19.16 as advised. Now Confluence is not closing thousands of file descriptors an hour, which has already caused downtime and we will need to periodically restart the service.

All of the leaked/unclosed file descriptors are for files with user avatars. Some of them are opened hundreds of times!

As bf31e0818161 mentioned, this is very likely related to CONFSERVER-80171: Confluence leaking file descriptors on Linux with Java 8 (fixed in Confluence Server and Data Center 7.19.7) as avatars are attachments in Confluence. I've described the problem on the ticket, but the challenge is it might not be Atlassian code causing this issue. To short circuit your reaching out to Support, I would recommend upgrading to Java 11 in staging to validate if that fixes the problem. Java 11 has noteworthy performance benefits, and has been supported for a long time now.

Outside of this, I would recommend engaging with Support via https://support.atlassian.com.

73d53917d30c

@Atlassian can you please advise if it's safe to upgrade to 7.19.16 or if we should move to an 8.x version. Thanks!

Confluence 7.19.16 is a safe version. Please note that no versions of Confluence 7.20 contain these fixes.

To finish, I would ask you all to continue to monitor our CVE bulletin CVE-2023-22518 - Improper Authorization Vulnerability In Confluence Data Center and Server.

I hope this helps.

Thanks,
James Ponting
Engineering Manager - Confluence Data Center

No issues so far with 7.19.16.

Debian 12
OpenJDK 64-Bit Server VM Temurin-11.0.21+9 (build 11.0.21+9, mixed mode)
PostgreSQL 15

SSO (CAS) still working as expected

 @Jasmine Möller
Whats your use case for H2? Support for H2 has ended with Confluence 8

@martin.palecek
JDK8 (which is EOL) is marked with a warning on this page: https://confluence.atlassian.com/conf719/supported-platforms-1157467959.html - and to be honest: Java 11 support has been included for a few years now.

We have external SSO in place for user authentication, does this still affect our config?

@John Price I have seen https://jira.atlassian.com/browse/CONFSERVER-80171 earlier today. It looks somewhat different. In our case it is not attachments that leak file descriptors. It's user avatars and nothing else than user avatars in our case. The rate of leakage seems somewhat proportional to the rates of the requests the server is handling. https://jira.atlassian.com/browse/CONFSERVER-80171 seems to have been fixed in 7.19.7. It should not be present in 7.19.16 unless there is a regression.

We are on Java 8 and that's how it stays till February when we are forced to migrate from Server to Data Center. It was working just fine until today morning when we upgraded due to this very alarming unauthenticated data loss vulnerability at the advice from Atlassian CISO.

As per https://confluence.atlassian.com/conf719/supported-platforms-1157467959.html Java 8 is a supported platform. The page mentions issues with Oracle Java 1.8.0_25, 1.8.0_31,  Java 1.8.0_45. We are on none of those.

@Atlassian can you please advise if it's safe to upgrade to 7.19.16 or if we should move to an 8.x version. Thanks!

@martin.palecek your comment worried me so I asked about it on our open priority support case.  Is there any chance you are still running Java 8 and having a recurrence of this:  https://jira.atlassian.com/browse/CONFSERVER-80171?

I don't want the rest of us to panic about the CVE patch unless it's a general problem.  We actually do have one site on Java 8 so we'll be upgrading Java as well.

We have updated to 7.19.16  as advised. Now Confluence is not closing thousands of file descriptors an hour, which has already caused downtime and we will need to periodically restart the service.

All of the leaked/unclosed file descriptors are for files with user avatars. Some of them are opened hundreds of times!

Hoping for a quick fix! This is worse than ever.

# lsof -p $(pgrep -f /wiki) |awk '/attachments/ {print $9}' |sort |uniq -c |sort -g |tail
    143 /srv/atlassian/confluence/data/attachments/ver003/nonspaced/44/111/361294/15958642/2
    143 /srv/atlassian/confluence/data/attachments/ver003/nonspaced/9/228/88228259/88718585/1
    147 /srv/atlassian/confluence/data/attachments/ver003/nonspaced/140/69/124819390/127634535/1
    162 /srv/atlassian/confluence/data/attachments/ver003/nonspaced/183/111/361433/15958498/2
    167 /srv/atlassian/confluence/data/attachments/ver003/nonspaced/67/110/360567/15958278/2
    174 /srv/atlassian/confluence/data/attachments/ver003/nonspaced/44/118/40618294/43360941/1
    186 /srv/atlassian/confluence/data/attachments/ver003/nonspaced/43/118/40618293/40626636/1
    188 /srv/atlassian/confluence/data/attachments/ver003/nonspaced/188/33/85783938/107383117/1
    202 /srv/atlassian/confluence/data/attachments/ver003/nonspaced/99/248/205498849/205507038/1
    479 /srv/atlassian/confluence/data/attachments/ver003/nonspaced/30/110/360530/15958384/2

Does it help if we put confluence instance behind, e.g. Cloudflare Web Application Firewall?

Further information on this exploit and how to harden against it would really be helpful for those not having capacity to do this on a (by now: weekly) basis.

It also doesn't really spark confidence in your "Cloud Product" being safe, especially in context of each new "LTS" update on 7.19.x branch seemingly removing more and more functionality.

I feel like there's a vulnerability every month. Last month we upgraded Confluence for security reasons too. Are you guys going to give us a workaround this time?

These latest Confluence updates/patches include bundled Tomcat v9.0.82. Prior to this Confluence update, the highest bundled version was Tomcat v9.0.76. If you look at the Apache Tomcat v9 vulnerabilities webpage, you'll see a list of issues and CVEs that exist between Tomcat v9.0.76 and v9.0.81. Workarounds to the listed Tomcat vulnerabilities may require more resources than patching respective Confluence instance(s); resources required for patching vary depending on each entity's deployment of Confluence.

Speculation
===
It is feasible that pre-patched Confluence includes additional vulnerabilities - hence "improper authorization." Attackers can also implement all of the attack vectors listed below in tandem to gain "improper authorization." 

Vulnerabilities Listed for Tomcat between v9.0.76 and v9.0.81
===

• DoS
• Request Smuggling
• Info Disclosure
• Open Redirect

@krzystof: That's a different CVE...

If we use instant re-direct to an external IdP (Salesforce) for authentication, is this vulnerability (undescribed as it is...) still applicable?

What is the workaround (we are under 7.19) ?  and we will patch it manually.

Is Confluence 7 really affected? Here it says that only versions above 8 are affected [FAQ for CVE-2023-22515 | Atlassian Support | Atlassian Documentation|https://confluence.atlassian.com/kb/faq-for-cve-2023-22515-1295682188.html] and here that all versions.. [CVE-2023-22518 - Improper Authorization Vulnerability In Confluence Data Center and Confluence Server | Atlassian Support | Atlassian Documentation|https://confluence.atlassian.com/security/cve-2023-22518-improper-authorization-vulnerability-in-confluence-data-center-and-confluence-server-1311473907.html?subid=1623690046&jobid=106268094&utm_campaign=confluence-security-advisory_EML-17425&utm_medium=email&utm_source=alert-email] Anyone knows how it is?

I got the same question as Adam Labus. We can only upgrade to 7.20.3. Will it work?

is it by any means, possible that you changed the web.xml in confluence/web-inf to the "new" 8.5.x format while in the 7.19.x LTS range?

in a high risk update? srsly?

Upgrade to 7.19.16:

contextInitialized An error was encountered while bootstrapping Confluence (see below):
java.lang.NoClassDefFoundError: org/h2/tools/Server

Please tell me you haven't removed H2 support for this critical bugfix!!!

EDIT: Yes you have!!! Please undo this ASAP aka NOW!

What is meant by All versions? Do you really mean that for the past 4-5 years (or even more) this was not found? How does your security testing then work? 

Rilwan Ahmed, 

Probably because the cloud version is always up-to-date and maintain by Atlassian directly, which is not the case for Data Center versions, This is one of the main purpose of Cloud ...

Oh look, here's yet another critical security vulnerability popping up, just perfectly timed to push people towards the unaffected cloud version.

Hi team,

We are using the 7.13.8 version and in the next 2 months we are moving to another platform and now our instance is exposed to the Internet. and we don't have the license what do we need to do?
Is an upgrade still required?
for an upgrade, we first need to go for the 7.17.1 version and thereafter we need to do an upgrade if is renewal required here.

Does Atlassian or anyone know how attacker take advantage of this Vulnerability? and if there is any mitigations action we can take as we are running a super big instance (unlimited user) and also publish on internet so it would take much time to upgrade.