Log4j Zeroday Vulnerability?

Well I think that you can put it in the lucee JVM options, see: Updating Memory Settings :: Lucee Documentation. So I haven’t put it in any file, but the program itself (that is being used to startup lucee)

But as stated this option only is useable if you actually use a log4j version above 2.0, and lucee has a lower version so it ignores this option. I also tried deleting the jar file all together, but lucee just remakes this jar on startup. I don’t use any log4j functions, but perhaps in underlying jar files it is used. So I hope Zackster is correct when stating lucee isn’t effected ^^

1 Like

JVM args are really a concern of the servlet container. Adobe bundles their engine with a hacked up version of Tomcat, which allows them a tighter integration with it. Lucee, on the other hand, ships a vanilla Tomcat version in their installer, but can be installed on any servlet container you like. So really, the question is what servlet container you’re using and how does that software allow you to configure JVM args. On Tomcat/Linux, it’s usually in the setenv.sh file. On Tomcat/Windows, it’s in the properties of the service control like the link above says. If you’re using CommandBox, you can put in the jvm.args property of your server.json.

Yes, version 2.10.x specifically :slight_smile: This is worth noting since Adobe ColdFusion 2018 update 10, for example, ships with Log4j 2.9 which means it’s potentially vulnerable, but the JVM args will not work on it.

Yes, log4j is a required bundle for Lucee, so it’s not an option to remove it if you want Lucee to work! It is re-downloading or re-extracting it since it’s required for Lucee to run.

Yes, it’s used internally for different things. Lucee has its own logging system so I’m not entirely sure if Lucee’s core uses it or if it’s most a dependency for other Apache libs.

The version of Log4j Lucee bundles automatically is not vulnerable. The question really is whether you have any custom jars you’ve dropped in or custom extensions you’ve installed that use a later version of log4j. In which case, the JVM arg may be an effective method of mitigating them (depending on the exact version in use) If you’re not sure if any of your third party libraries use log4j, I posted a scanning tool I wrapped in a Task Runner in the thread Zac linked to above. You can have it scan the entire Lucee home dir and it will recursively check every jar to see if any of them are vulnerable.

1 Like

Yes, but to be clear it’s not really “sad” because the JNDI exploit does not exist in Log4j 1.2.17 :slight_smile: So there’s really no use for the JVM arg there. The Log4j versions you need to be wary of are 2.0 to 2.14.1.


Thanks for your detailed explanation! I know we use a jar file that contains a lot of jar files inside of it, so not really sure if it’s being used inside of that. But looking at it from a different perspective is: what outside people can call what functions? We make internal applications and thus most calls are only for authorized users. So a cfspreadsheet call somewhere inside isn’t really making me nervous. And perhaps a firewall rule for ‘${jndi:ldap://’ could also help if people are still unsure.

WAF rules are more or less useless/provide a false sense of security, because most attacks are now splitting the strings up

1 Like

A post was split to a new topic: Spreadsheet-CFML 3.2.1 just released with log4j 2.16.0

You can recursively scan jar files for vulnerable versions of log4j with this tool

what outside people can call what functions?

It’s not that users of your app can directly invoke Java methods. It would be a matter of tricking your application into logging a message that contained the special string and hoping that message was logged via a vulnerable version of Log4j.

Hey guys, I’m looking into this right now for a client and it’s been a while since I worked with Lucee. I’m basically a newbie now. The server is running on Ubuntu 18 with Lucee final. I checked the log4j which is located at “/opt/lucee/lib/apache-logging-log4j.jar” on the server and it seems to be version 1.2.16. I have a few questions if someone could kindly help me with:

  1. Will this vulnerability affect this server if I don’t do anything?

  2. If this log4j version is an issue, can I just update it with the patched log4j jar file and it will be ok or do I have to do something more to fix this? If yes, where do I find the log4j patched file?

  3. Should I upgrade Lucee to the latest version? If so, which one and will it fix this log4j vulnerability?

Any help is appreciated as it’s been a long time since I worked with Lucee.

Thank you,


Log4j 1.2.16 is not vulnerable to the Log4Shell exploit. That said, Lucee 4.5.5 is very old and has serious seucirty issues of its own. You should update to Lucee 5.3.8 as soon as you can.

@bdw429s , thank you so much for the quick reply, really appreciate it. I will have a look at the lucee upgrade. Will the log4j get updated if I update Lucee?

Even the latest version of of Lucee uses a version of Log4j so old that it is not affected by Log4Shell. So you can update to the latest Lucee and not worry about Log4Shell.


My management is no longer willing to run older version of log4j 1.x or 2.x. It doesn’t matter that 1.2.7 is not vulnerable to log4shell.

And we need a rapid means of keeping up with the latest release of log4j. There have been 3 releases in just the past last week (2.15, 2.16, and now 2.17!!!).

If 5.x can’t be updated quickly to 2.x, how about a build that uses the log4j 1.2 bridge jar?

Or, can we get some guidance on replacing log4j 1.2.7 ourselves?

Lucee can’t afford to stick its head in the sand on this. If it doesn’t respond to this quickly, Lucee 6.x is DOA.

Your management is willing to sponsor a java developer to implement their demands? Mine does

The Lucee project currently has $2,415.20 USD in the bank


@didge I don’t think Lucee is sticking its head in the sand. The Lucee dev investigated this and tested the vulnerability and informed us all way before other software companies did. Lucee isn’t vulnerable.

Really, if your management can’t wait and is not willing and making such demands from an open source project of a 70.000USD yearly budget, then sorry, but the log4jshell impact is the exact result of your managements mentality.

@Zackster @Gert @micstriit Would it be possible to get a rough estimate of the level of work/cost to update all Log4j usage in Lucee? (Understanding, this may also affect bundled 3rd party extensions as well as the core, which LAS has little control over) That way if a company like @didge’s finds it important enough, they can help sponsor the effort.

Last I checked, I’m a Java developer getting paid to investigate and potentially implement a workaround for this, so yeah, my mgmt is not only willing, they’ve already stepped up.

If money is the only issue for this to get fixed quickly and efficiently, then let’s talk, I can’t promise anything, but our alternatives aren’t appealing either.

1 Like

@didge @bdw429s My company would be willing to co-sponsor the efforts to use Log4J2+ in Lucee 5. Let me know if that’s an option.


I’d suggest thinking a bit broader about this situation and asking rather than just donating to fix this problem, why not help fund the Lucee project overall, help avoid the next situation which concerns you?

All of us on the team at LAS would dearly love to have enough recurrent funding to be able to hire a Senior Java Developer to work full time on Lucee.

You know that only 27 companies or individuals have donated more than $500 to the Lucee project since we started on open collective Lucee - Open Collective

I’m guessing there’s a lot of companies who are built on Lucee who aren’t on that list

@Zackster Of course, we’d want the funding to be used appropriately. For what it’s worth, I’m part of Mura Software, and we do contribute via Open Collective. This offer of funding would be in addition to that contribution.

If upgrading to Log4J2 isn’t an option, could we help fast-track the release of Lucee 6? One of our customers has mandated that Log4J(v1) is not used in production, so we’re at your mercy to help us make that happen for them (and the community at large).

1 Like

The current sprint for 5.3.9 includes support log4j2, the initial commit has been made, still a WIP