https://confluence.atlassian.com/doc/confluence-security-adv... is updated with a workaround that you can apply manually now.

Posting this high here so it can be seen.

Hacked together a quick and dirty shell script to install on my boxes in a repeatable way... Hope this helps others that find themselves in this situation.

https://gist.github.com/noahbailey/0260efa836b4ea67163cbfeef...

And now the same link has the released update versions. And more details: https://jira.atlassian.com/browse/CONFSERVER-79000

Part of the fix is a patched version of xwork 1.0.3, originally released in 2005, which has had several CVEs past 1.0.3. Yikes.

Which is very strange, they usually have at least a workaround or URL to block.

There are now manual steps for mitigating the vulnerability.

See https://confluence.atlassian.com/doc/confluence-security-adv...

It is strange that they didn't have mitigation steps earlier, but I'm guessing Atlassian announced this immediately since it was already being exploited.

They’ve suggested blocking ${ in the request

Using nginx in front of my local confluence server (not listening on the internet) and used the following:

  location ~\* \$\{. {
          deny all;
  }

but this only helps if this vulnerability is triggered using the request uri otherwise it's useless

Anyone know how you'd quote it for Apache rewrite?

        RewriteEngine On
        RewriteCond %{REQUEST_URI} ^.*\${.*$
        RewriteRule ^/(.*) https://google.com [R=302,L]

seems to work ...

The security advisory from Atlassian says blocking ${ "may reduce your risk". That's a far cry from being a fix.

I really worry about these sort of claims. I'm seeing pushback from people about shutting servers down because it's insisted "a WAF is protecting us now", and that's based on a "may reduce risk".

I would worry about just using that blocking pattern. They mention OGNL injection and ${ is just one pattern you can go after. There's also #{, %{, #var, and more.

Same issue with log4shell. "Why are you bugging us? We already applied <mitigation posted 2 weeks ago that has since been disproven>."

posting a snippet for HAProxy in case its helpful to someone else (or if others have recommendations on how to better do this)

  http-request deny if { path -m sub ${ }
  http-request deny if { query -m sub ${ }
  http-request deny if { path -m sub $%7B }
  http-request deny if { query -m sub $%7B }
  http-request deny if { path -m sub %24%7B }
  http-request deny if { query -m sub %24%7B }

Sorry what now? You cannot simply block the current attackers control addresses (they actually do give you these) or domains. First they could be either VPN users or "residential proxies" aka legitimate people with a botnet on their pc. Second the attacker - or anyone else who now knows it exists - can just change URLs or IPs. They can change the exploit signature so anti-virus and IDS systems can't trivially see it.

The ONLY correct solution here is to bring the servers offline until there is a patched version to upgrade to. Anything else would be a terrible idea.

_sometimes_ there is only one config setting that's affected, or some other often lesser-used feature that can be disabled. But it highly depends on the method used.

GP meant that oftentimes exploits use a specific entry point on the public surface and blocking access to it acts as a stop-gap measure.