Lucee CVE-2024-55354 Security Advisory, April 2025

Impact

Lucee is vulnerable to a protection mechanism failure that can let an attacker run code that would be expected to be blocked and access resources that would be expected to be protected.

This patch is strongly recommended for multi-tenant and shared hosting environments.

To be clear, this is not a Lucee Admin vulnerability and the majority of Lucee installations will not be exploitable unless an attacker has the ability to write files to the server.

If you are using your own VPS / Server, i.e you have root or Administrator access, it is unlikely you are using shared hosting, if in doubt contact your Hosting provider / System Admin to confirm.

Adobe has also announced a similar ColdFusion CVE today.

Stable Releases

These mitigations listed below are already available since Lucee, 6.1.1.118, as such 6.2.0.321 and the 6.2.1 RCs all support this currently ( the mitigation mechanism was previously added in 6.1.1.114-SNAPSHOT, and 6.2.0.154-SNAPSHOT before this vulnerability was reported)

Patches - 5.4.7.3 LTS

Today we have just published a 5.4.7.3 (Long Term Support) stable release with support for this mitigation.

If you are upgrading from 5.4.7.2, as this is a minor patch, these updates can be safely, immediately applied via the Lucee Server Admin, Under Services → Updates

Or by downloading the .lco core update from https://download.lucee.org/ and copying into your server’s deploy folder,

For older versions, you will need to upgrade to a supported version.

Mitigation

The mitigation can be enabled by setting the following Java System Property or Environment Variable and restarting Lucee

  • System property: -Dlucee.compiler.block.bytecode=true
  • Environment variable: LUCEE_COMPILER_BLOCK_BYTECODE=true

If you are using (or suspect you are using) a shared hosting provider, please contact them to confirm they have applied this mitigation, you will not be able to apply this yourself.

These settings will prevent all pre-compiled CFML (Java bytecode) from being run directly as files with a .cfm or .cfc extension.

This will not affect how CFML source code files with a .cfm or .cfc extension are compiled at runtime.

This will be disabled by default in the next major release, Lucee 7.

References

5 Likes

Apologies for the typo in the alert to our wonderful sponsors (face palm emoji)

Thank you for supporting us!

1 Like

Thanks. The fix works for me!

2 Likes

How have you confirmed the fix works ? I don’t think there is proof of concept code for this ?

Do you think we’d make this announcement without confirming it works?

This is now enabled by default since Lucee 7.0.0.178

https://luceeserver.atlassian.net/browse/LDEV-5485

No of course not :slight_smile:

But that doesn’t mean there’s a public POC or IOC.

Is there one ?

I broke the 7.0 build enabling this!

1 Like

This is interesting for me as years ago we obfuscated our source code through pre-compiling to bytecode, effectively replacing the CF source files with bytecode files of the same filename in the packaged web server (to stop clients hacking at the product without permission, ensure integrity etc).

Wouldn’t have guessed it would bypass all the usual safeguards. Out of curiousity, was there a stance (official or otherwise) on bytecode precompilation, and has that changed due to this CVE?

If you can write to the file system, the fox is already in the hen house right, what format the files are in really doesn’t matter? whatever works for you ™

This is CVE was primarily concerned with shared hosting with sandboxing via web context restrictions.

2 Likes

I don’t know what “sandboxing via web context restrictions” means, but we’ve taken the view that if an attacker can write to the web root, all bets are off anyway, if they put bytecode or cfexecute in the file it doesn’t really matter, it’s gonna run.

1 Like

in multi mode, you can lockdown each web context via the server admin, by setting restrictions on which tags/etc can run and what directories are accessible via cfml file functions.

dates back to when servers were small and expensive and shared hosting was a more of thing, before VPS / docker etc. As the world has changed, it’s why 7 is moving to only single mode

1 Like

Ah ha, cheers, that makes sense why it ends up with a fairly high CVE score, even though an attacker still needs arbitrary write in the web root to trigger it.

as @Brad_Wood likes to say, with ACF, everything is a 10!