Download Firefox -  a safer, easier to use web browser. Return to - Leap into the online experience! Return to - Leap into the online experience! - Leap into the online experience!

Project News :.

The latest project to launch was the site for Gorilla Offroad Company. Aside from their main site, a social media strategy was develop to launch the company into various industry specific automobile enthusist discussion board communities as well as popular social media fronts like Facebook, Pinterest, and Twitter.

Valid XHTML 1.0 Transitional

Valid CSS!

Section 508 Compliant

powered by: Macromedia ColdFusion MX

made with: Macromedia Dreamweaver MX

What is RSS

XML - often denotes RSS Feed information.

Macromedia - ColdFusion Programming
white horizontal rule

ColdFusion News :.

To bring a little life to my site, I've pulled a couple What is RSS Feeds into this page. You can currently choose between the technology related news stories from the following news sources:

You are currently viewing and RSS Feed from Pete Freitag's Blog.

How I cut AWS Lambda Java Cold Start Times in Half

It is rare that a simple JVM argument change can have a dramatic impact on execution times, but in the case of AWS Lambda adjusting the Tiered Complication settings can have a really big impact on performance in many (but not all) cases.

The change I made was to add the JVM arguments:

-XX:+TieredCompilation -XX:TieredStopAtLevel=1

On AWS Lambda you can do this by simply adding the environment variable:

JAVA_TOOL_OPTIONS = -XX:+TieredCompilation -XX:TieredStopAtLevel=1

This chart below shows the average execution time of a Java (more specifically written in CFML and using FuseLess) Lambda Function over the course of two days. I've annotated where I made the change and you can see average execution times cut in half, cold start times also cut in half (though the chart doesn't show that). Before enabling the flag I was seeing cold start times of about 3.6 seconds, after the flag average cold start time was around 1.2 seconds.

Chart of average lambda execution time before and after jvm change

Note that this particular java lambda function that I used for testing does have some highly intensive invocations that might take up to 30 seconds to execute, after the change I didn't see any executions going above 15 seconds.

What is TieredCompilation and what is TieredStopAtLevel?

That graph is probably leading you to wonder what is TieredCompilation in java. As you may know the JVM translates your bytecode (class files) into machine code at runtime. This step can take a lot of resources if the compiler wants to make it optimal, it might add counters so it can figure out where the hot spots are and then perform further optimizations. This works great and leads to awesome performance on the JVM when your server is running for a long time. In a way the JVM self tunes itself over time, at runtime.

When you are running on a serverless environment like AWS Lambda your runtime will only survive for a short period of time (as little as a few minutes, but no more than a few hours) before being destroyed. The assumption that the JVM default configuration makes is servers will run for a long time, and it should optimize the parts of the code that run the most over time. By setting the TieredStopAtLevel flag to 1 we are telling the JVM not to insert profiling code that is used for runtime measurements and optimizations. In essence we are telling the JVM, don't try to be too smart, don't optimize for the future - this code may never run agin, just execute the code, and in the process we are saving CPU cycles and yielding faster execution.

I learned about this technique from AWS, so it makes me wonder why they don't just enable it by default on all Java Lambda Functions? I think all Java Lambda functions could see a lower cold start time with these flags set, but possibly not a lower overall average execution time like I saw. It really depends on how well your code can be optimized by the jvm, and how many executions run before the lambda container is recycled. It is certainly worth your time to experiment and see if this flag will improve your Java Lambda Cold Start and Average Duration execution times. Such large performance gains are often not so easily found.

While my experience was specific to AWS Lambda running Java, I'm sure if you are running Azure Cloud Functions on Java, or Google Cloud Functions on Java you could use the same tip to cut your cold start times and hopefully your average duration as well.

Other ways to improve Java Cold Start Times

  • Deployment Size - I've found that the total size of your deployment can make a big difference in the Java Cold Start execution time. Going from a 50mb deployment zip to a 15mb zip can make a big difference. Upon Cold Start, Lambda has to download your zip from the network, and then extract the zip to the file system.
  • RAM - Increasing the amount of RAM that your Java Lambda has will reduce the ColdStart time, for Java I think the Lambda should have at least 1GB of memory (I usually run around 2-3GB). But it's not just about the RAM, because increasing the RAM will also give the Lambda instance more CPU power, which is helpful on Cold Starts.
  • Avoid Nested Jars - Avoid nesting jars within jars within jars if you can. This is just creating busy work for the CPU to extract upon cold start.

(Thu, 07 Apr 2022 20:56:00 GMT)
[view article in new window]

Spring4Shell and ColdFusion

I've had a bunch of people ask me if ColdFusion / Lucee servers need to worry about the recent Java vulnerability in Spring, nick named Spring4Shell, or more formally known as CVE-2022-22965.

To the best of my knowledge ColdFusion and Lucee do not make use of the Java Spring Framework by default, and do not include any of the vulnerable Spring jars by default. Disclaimer: I haven't done an exhaustive analysis, and I haven't checked every single version of ColdFusion or Lucee.

I used JFrog's Spring Tools scanner to scan both a ColdFusion 2021 and a Lucee 5.3 installation, neither returned any findings.

According to Spring's blog entry about this issue you may be impacted if you are:

  • Running on JDK 9 or higher
  • Apache Tomcat as the Servlet container.
  • Packaged as a traditional WAR and deployed in a standalone Tomcat instance. Typical Spring Boot deployments using an embedded Servlet container or reactive web server are not impacted.
  • spring-webmvc or spring-webflux dependency.
  • Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions.

Most ColdFusion Servers would be running JDK 9 or higher, and Apache Tomcat, but probably do not have the spring-webmvc or spring-webflux dependency.

I have had some people tell me FuseGuard was catching some Spring4Shell exploit attempts. You might see FuseGuard's Scope Injection Filter block requests that look like this:


(Thu, 07 Apr 2022 02:36:00 GMT)
[view article in new window]

Order by NULL Values in MySQL, Postgresql and SQL Server

If you have a column that may contain NULL values, and you want sort on that column with an ORDER BY clause, which comes first the null values or the non null values?

This is something that I have to look up, or simply test each and every time I need to know, so I figured it would be good material for a blog entry.

NULL Values First on MySQL or PostgreSQL

If you want the columns with null values to show up first, then sort ascending.

SELECT * FROM orders
ORDER BY date_shipped ASC

This would show orders that have not shipped first, and then the orders sorted by date_shipped ascending.

NULL Values Last on MySQL or PostgreSQL

If you want the NULL values to show up after column values, use a DESC sort direction in your order by clause:

SELECT * FROM orders
ORDER BY date_shipped DESC

This query would show the most recently shipped orders first, and orders that have not shipped yet would be last.

Here's a DB Fiddle so you can run the above example on MySQL or PostgreSQL.

SQL Server works the Opposite

Now, I found that SQL Server actually will sort the opposite way, and put the null values first when you sort ascending, and the null values last when you sort descending. Interesting, but also something to be aware of if you are trying to write cross database SQL.

Null Sorting by Database Engine

MySQLPostgreSQLSQL Server

(Thu, 10 Mar 2022 23:03:00 GMT)
[view article in new window]

CloudFlare Authenticated Origin Pulls on Nginx or Apache

If you are using CloudFlare in front of your web server, it is a good idea to setup CloudFlare Authenticated Origin Pulls. When this is enabled and properly configured only CloudFlare will be able to connect to your origin web server directly.

An example setup on nginx might require that you add something like this:

ssl_client_certificate /etc/cloudflare/cloudflare-origin-pull-ca.pem;
ssl_verify_client on;    

On Apache it might look like this:

SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /etc/cloudflare/cloudflare-origin-pull-ca.pem

In both examples I'm referencing a file: /etc/cloudflare/cloudflare-origin-pull-ca.pem this is CloudFlare's CA Certificate which you can grab from their site here. This public CA certificate is used to sign the client certificate on CloudFlare's edge servers that is used when requesting your origin server. The ssl_verify_client on or SSLVerifyClient require instruct your web server to reject any connections that are not signed by the CA certificate.

While it is pretty straight forward to setup if you miss something you might see a 400 Bad Request error like this:

400 Bad Request
No required SSL certificate was sent

Here are some things you can check if you see that error:

  • Make sure you have checked the Authenticated Origin Pulls checkbox in CloudFlare Dashboard under SSL/TLS then Origin Server.
  • Make sure you have set your SSL/TLS encryption mode to "Full" or "Full (Strict)" in the CloudFlare Dashboard, it won't work if your encryption mode is set to Flexible or Off.
  • Make sure you have restarted or reloaded the configuration on your web server

(Fri, 28 Jan 2022 00:46:00 GMT)
[view article in new window]

Log4j 1.x Vulnerability Mitigation Guide

Almost every day I see someone asking what to do about log4j 1.2 / 1.x versions. It can be quite a lot of wrap your head around, and it can't be answered easily in a sentence or two. So here's my attempt at providing some clarity and solutions for the millions of applications that are still using Log4j 1.x

TLDR: Apache Log4j 1.x does have vulnerabilities that are unpatched. Many configurations are not impacted by the vulnerabilities by default. Log4j 1.x is EOL so there are no fixed 1.x versions. You can patch the jar files yourself by removing the vulnerable class files. It's not a simple upgrade to go from Log4j 1.x to 2.x in most cases.

Current List of Log4j Security Vulnerabilities

As of December 28, 2021

CVE-2017-5645 published on April 17, 2017

In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.

Log4j 2.x Vulnerable: Yes, fixed in version 2.8.2

Log4j 1.x Vulnerable: Yes, see CVE-2019-17571

Mitigating CVE-2017-5645 on Log4j 1.x
  • Upgrade to latest version of log4j 2
  • or remove SocketServer.class and SocketAppender.class from your jar files
  • or ensure you do not run a log4j SocketServer, and your log4j configuration does not use a SocketAppender

Most log4j implementations do not use the SocketServer or the SocketServer appender, you'd have to enable a SocketAppender in your configuration, then start a log4j server like this:

java -classpath log4j.jar 4712

Most log4j implementations are simply writing logs to a file, not distributing logs to another server.

CVE-2019-17571 published on December 20, 2019

Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.

Log4j 2.x Vulnerable: Yes, same as CVE-2017-5645

Log4j 1.x Vulnerable: Yes, all versions no fixed version published

Mitigating CVE-2019-17571 on Log4j 1.x

Same steps as above under CVE-2017-5645.

CVE-2020-9488 published on April 27, 2020

Improper validation of certificate with host mismatch in Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender.

Log4j 2.x Vulnerable: Yes, fixed in 2.13.2

Log4j 1.x Vulnerable: Yes, all versions no fixed version published

Mitigating CVE-2019-17571 on Log4j 1.x
  • Upgrade to latest version of log4j 2
  • or remove SMTPAppender.class and SMTPAppender$1.class files from your jar files
  • or ensure your log4j configuration does not use a SMTPAppender

CVE-2021-4104 published on December 14, 2021

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

Log4j 2.x Vulnerable: No, but similar to CVE-2021-44228

Log4j 1.x Vulnerable: Yes, all versions no fixed version published

Mitigating CVE-2021-4104 on Log4j 1.x
  • Upgrade to latest version of log4j 2
  • or remove JMSAppender.class from your jar files
  • or ensure your log4j configuration does not use JMSAppender

CVE-2021-44228 published on December 10, 2021

Log4j 2.x Vulnerable: Yes, fixed in 2.15.0

Log4j 1.x Vulnerable: Configurations without JMSAppender are Not impacted according to Log4j Security Page, see CVE-2021-4104 above.

CVE-2021-44228 is the very serious / critical Remote Code Execution Vulnerability known as Log4Shell.

CVE-2021-45046 published on December 13, 2021

Log4j 2.x Vulnerable: Yes, fixed in 2.16.0

Log4j 1.x Vulnerable: Not impacted according to Log4j Security Page

DOS, RCE vulnerability.

CVE-2021-45105 published on December 18, 2021

Log4j 2.x Vulnerable: Yes, fixed in 2.17.0

Log4j 1.x Vulnerable: Not impacted according to Log4j Security Page

DOS vulnerability.

CVE-2021-44832 published on December 28, 2021

Log4j 2.x Vulnerable: Yes, fixed in 2.17.1

Log4j 1.x Vulnerable: Not impacted according to Log4j Security Page

RCE when attacker can control log4j configuration.

CVE-2022-23302 published on January 18, 2022

JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to.

Log4j 2.x Vulnerable: No

Log4j 1.x Vulnerable: Yes

CVE-2022-23305 published on January 18, 2022

By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout.

Log4j 2.x Vulnerable: No, Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries.

Log4j 1.x Vulnerable: Yes

This can allow for SQL Injection depending on how the JDBC Appender is configured.

CVE-2022-23307 published on January 18, 2022

CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was included as a component of Apache Log4j 1.2.x where the same issue exists.

Log4j 2.x Vulnerable: No

Log4j 1.x Vulnerable: Yes

Chainsaw is a log viewer GUI that is contained within the java package org.apache.log4j.chainsaw within log4j-1.2.17.jar.

Log4j 1.x Is No Longer Supported

The Apache Log4j 1.2 project page clearly states On August 5, 2015 the Logging Services Project Management Committee announced that Log4j 1.x had reached end of life... Users of Log4j 1 are recommended to upgrade to Apache Log4j 2.

The Log4j Project Maintainers have had their hands full with the issues in Log4j 2, and are understandably not at all interested in doing much to help log4j 1.x users. You'll have to either upgrade to Log4j 2, or get creative.

Is it easy to upgrade from Log4j 1 to Log4j 2?

No, it's not as simply as simply swapping out the jars unfortunately. If that were the case, we would probably have seen a lot more people using v2 that are still on v1.

The Log4j 1.2 Bridge

There is a log4j 1.2 bridge or adapter, which allows software written for Log4j 1.2 to use Log4j version 2 jars instead. I haven't investigated this fully yet, but it looks like for some software you might be able to use this to drop a bunch of jars in the right places. I'll post more info here after I investigate it more.

Checking log4j configuration for vulnerable Appenders

Log4j is very configurable, so you can configure it either from a configuration file, or at runtime. It is much harder to determine what appenders are being used at runtime (you need to review the source code). To review the configuration, search your file system for files containing log4j.appender or any of the following:

  • SocketAppender
  • SMTPAppender
  • JMSAppender
  • JDBCAppender
  • log4j.appender.server
  • log4j.appender.jms

The files may be either a properties file or an XML file, some common log4j configuration file names are:

  • log4j.xml
  • logger.xml
  • logging.xml

If you were using the SocketAppender you might see a hit like this in a file:

For the JMSAppender it might look like this:

And for the SMTPAppender like this:

Removing vulnerable classes from Log4j 1.x jars

In case you were not aware, a jar file is just a zip file, you can use any zip command to operate on them. For example using the command zip -d file.jar 'path/to/ClassName.class' you can remove a class from a jar file on Linux or a Mac.

Important: Make a backup of the jar files first before modifying them, and stop any running servers or java processes first.

To remove the JMSAppender class from a Log4j 1.2.17 jar:

zip -d log4j-1.2.17.jar 'org/apache/log4j/net/JMSAppender.class'

You will see output like this if it works:

deleting: org/apache/log4j/net/JMSAppender.class

If the jar path is incorrect, or it doesn't have the class you will see:

zip warning: name not matched: org/apache/log4j/net/JMSAppender.class

Or if you want to multiple vulnerable classes in one shot:

zip -d log4j.jar 'org/apache/log4j/net/JMSAppender.class' 'org/apache/log4j/net/SocketAppender.class' 'org/apache/log4j/net/SocketServer.class' 'org/apache/log4j/net/SMTPAppender$1.class' 'org/apache/log4j/net/SMTPAppender.class'

To make sure it worked, you can list the files contained in the jar file by running:

jar -tf log4j-1.2.17.jar

Or if you have unzip installed:

unzip -l log4j.jar

If possible, rename your jar file to something like log4j-1.2.17-patched-2021-12-20.jar so that it is more obvious that it was patched. Depending on how your java server or process starts, the jar file path may be in the classpath. Sometimes however all jar files in a directory are loaded into the classpath, so you can name it whatever you want, just be sure to remove the unpatched jars.

Now start your java server, or application again and test to make sure it still works.

Potentially Vulnerable Classes in Log4j 1.2

Here's a table listing the classes you might want to remove from a log4j 1.2 jar file:

Class FileCVE

DISCLAIMER: The content (and links) on this page are provided as is, without warranty of any kind. Use at your own risk. You should consult with your software vendors to ensure that you are properly protected.

(Thu, 23 Dec 2021 23:52:00 GMT)
[view article in new window]

Log4Shell Vulnerability Timeline

When I created a blog entry covering Log4Shell log4j on ColdFusion, and said I would update it as new information comes in, I didn't realize I would be updating it several times a day for the past week.

I think this Log4Shell / Log4j issue can be confusing to keep track of with all the new developments, so I decided to create a timeline.

I will try to keep this timeline updated as the story develops (why do I do this to myself :-)

Issue discovered by Chen Zhaojun of the Alibaba Cloud Security Team, and reported to the Apache Software Foundation.
Earliest known exploit attempt 2021-12-01 04:36:50 UTC reported by CloudFlare.
Log4j released version 2.15.0 (mitigates the known attack vectors at the time)
Issue was made public on Twitter
CVE-2021-44228 published, Apache log4j Security Page updated. The world starts patching, and begins to realize the significance of this issue.
Log4j 2.16.0 is released removing the vulnerable class all together, a less severe DOS issue was fixed (CVE-2021-45046).
CVE-2021-45046 is published.
CVE-2021-45046 is upgraded from moderate to critical, as it was determined that a remote code execution vulnerability was still possible in 2.15.0.
Log4j 2.17.0 released.
CVE-2021-45105 published, log4j 2.16.0 and below vulnerable to a DOS.
Log4j 2.17.1 released, CVE-2021-44832 log4j 2 through 2.17.0 vulnerable to a RCE when attacker can control configuration.
Additional Log4j 1.2 vulnerabilities published: CVE-2022-23307, CVE-2022-23305, CVE-2022-23302

Sources Used:

(Sat, 18 Dec 2021 21:51:00 GMT)
[view article in new window]

How to get Log4j Version at Runtime in Java

Here's how you can get the version of Log4j you are using at runtime using Java:

Java Code to Get the Log4j Version at Runtime


The above only works on version log4j2 (log4j version 2), and is based on jar file manifest information. There doesn't appear to be a getVersion() method or function in the log4j package.

ColdFusion / CFML Code to get Log4j Version at Runtime

If you are using ColdFusion / Lucee or CFML, you can run this snippet:

createObject("java", "org.apache.logging.log4j.util.PropertiesUtil").getClass().getPackage().getImplementationVersion()

Checking log4j2.formatMsgNoLookups at runtime

I picked the PropertiesUtil class in my above example because it appears that it can be used to check for the Java system property log4j2.formatMsgNoLookups or potentially the LOG4J_FORMAT_MSG_NO_LOOKUPS at runtime.


I haven't fully tested the above in all scenarios, but it looks handy so I thought I'd share it.

Checking a System Property at Runtime with Java

Here's a generic way to check a system property value at runtime in java:


The value will be null if it is not defined.

Checking a Environment Variable value at Runtime in Java

To check for the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable at runtime you can use:


Checking the System Property / Environment Variable in CFML

Using CFML you can run this chunk of code to test:

//(c) Pete Freitag / Foundeo Inc :
system = createObject("java", "java.lang.System");
prop = system.getProperty("log4j2.formatMsgNoLookups");
evn = system.getenv("LOG4J_FORMAT_MSG_NO_LOOKUPS");
if (isNull(prop) && isNull(env)) {
    writeOutput("System Property / Env Var Not Defined");
} else {
   if (!isNull(prop)) {
   } else {


In java you can have multiple class loaders, and potentially multiple versions of log4j running in your application at once. This code example only shows what version of Log4j the class loader that runs it has.

I strongly recommend that you scan your jar files as well. More info on CVE-2021-44228 here.

(Wed, 15 Dec 2021 21:07:00 GMT)
[view article in new window]

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

There is a critical security vulnerability (CVE-2021-44228 aka Log4Shell) in the java library log4j which is a popular logging library for java applications. It is included in both Adobe ColdFusion and Lucee for example.

Putting together some info to help sort this issue out as it pertains to ColdFusion and Lucee users. I'll update this entry as needed.

TLDR: Adobe ColdFusion users should upgrade to either ColdFusion 2018 update 14 or ColdFusion 2021 Update 4 (both now use log4j version 2.17.2). Lucee has released version with Log4j 2.17.2, earlier versions used log4j 1.x.

What versions of log4j are vulnerable to CVE-2021-44228?

According to the Log4j Security Page:

Versions Affected: all versions from 2.0-beta9 to 2.14.1. Fixed in Log4j 2.15.0.

Here's the jira issue for when the JNDI lookup feature was added in 2.0-beta9: LOG4J2-313

Another CVE: CVE-2021-45046 (2021-12-14)

It appears that the fix in 2.15.0 and the JVM mitigation was incomplete. Version 2.16.0 was released.

CVE-2021-45046 Upgraded to Critical (2021-12-17)

Another issue was found in 2.15.0, a more serious / critical RCE. Fixed in 2.16.0

Another CVE: CVE-2021-45105 (2021-12-17)

A Denial of Service (DOS) issue in 2.16.0 and below, fixed in 2.17.0

Another CVE: CVE-2021-44832 (2021-12-28)

Log4j versions 2.17.0 and below are vulnerable to a RCE when the attacker can modify the log4j configuration. 2.17.1 was released to address this issue.

How can I mitigate this issue?

Here's a list of possible mitigations, initially sourced from LunaSec's blog:

  • Update your log4j jars to latest patched version of Log4j 2: 2.15.0 (see CVE-2021-45046) 2.16.0 (see CVE-2021-45105) 2.17.0 (see CVE-2021-44832) 2.17.1
  • Add JVM arg: -Dlog4j2.formatMsgNoLookups=true (only works on log4j 2.10.0 and up). Incomplete fix, still has DOS see above: CVE-2021-45046, CVE-2021-45105, CVE-2021-44832
  • According to Microsoft's Response to this issue, you can set an environment variable instead of the JVM argument: LOG4J_FORMAT_MSG_NO_LOOKUPS=true - incomplete for CVE-2021-45046, CVE-2021-45105, CVE-2021-44832
  • All of the above require restarting the java process (restart ColdFusion or Lucee).

A few additional mitigations that you can consider:

  • Use your network firewall to ensure that no egress internet traffic leaves the server. This might be tricky depending on your requirements, but if the server cannot make a network request to the internet, this has a big impact on the severity of this. This could also be done at the jvm level using a java security policy or sandbox security in ColdFusion. You may still have DOS issues to consider with this approach.
  • If you cannot use the jvm arg because you have log4j2 2.0 - 2.10.0 and for some reason cannot update to version 2.17.0 then it should be safe remove the offending JndiLookup.class class file from the jar. Details. You may still be vulnerable to CVE-2021-45046, CVE-2021-45105.
  • Many Web Application Firewalls (WAF) provide detection / blocking of Log4Shell attack patterns. However you should never treat a WAF as a 100% solution. Many if not all WAF patterns could be evaded, but they can still block many attempts (defense in depth). FuseGuard a WAF written in CFML has added a Log4ShellFilter in version 3.4.0

Adobe ColdFusion

Adobe ColdFusion 2018 and 2021 include potentially vulnerable versions of log4j2. I notified the Adobe Product Security Incident Response Team (PSIRT) early Friday (2021-12-10) morning of the issue. Adobe has published a KB article on 2021-12-14, and on 2021-12-17 released ColdFusion 2021 Update 3, and ColdFusion 2018 Update 13 to address CVE-2021-44228 and CVE-2021-45046 by updating log4j to version 2.16.0.

To address CVE-2021-45105 and CVE-2021-44832 apply ColdFusion 2018 update 14 or ColdFusion 2021 Update 4 (which updates log4j version to 2.17.2). Previous advice from Adobe is no longer relevant after update 4/14 KB article 1, KB Article 2

Some versions early versions of ColdFusion 2018 include a version of log4j before 2.10.0 and greater than 2.0 which means that JVM arg mitigation doesn't work, so you would need to update to the latest version first.

My suggestion for people using ColdFusion would be to update to the latest patched version of ColdFusion, and then add the JVM arg -Dlog4j2.formatMsgNoLookups=true to the java.args line in your jvm.config file. Then if you are on CF2018/2021 follow their KB article to update log4j to version 2.17.0 (or 2.17.1)

Update 2022-05-10 Adobe released ColdFusion 2021 update 4, ColdFusion 2018 update 14 which update log4j version to 2.17.2

Update 2021-12-17 Since Adobe has released an update for 2018, and 2021 which bring the log4j version to 2.16.0, I still don't think it is a bad idea to add the JVM mitigation, incase there are any third party libraries on your server now or in the future.

ColdFusion 2016, update 17 appears to ship with log4j-1.2.17, see info below about log4j 1.x versions.

Discussion about this issue can be found on Adobe Forums.


From what I have seen, lucee ships with log4j 1.2.x which is not listed as an affected version for CVE-2021-44228. See more details about log4j 1.x below.

The Lucee team has posted a message stating: Lucee is not affected by the Log4j JNDI exploit.

Where else should I look?

You might have a third party library that uses log4j as a dependency. Here's a list of some examples:

  • spreadsheet-cfml - version 3.1.0 included log4j-api-2.14.1.jar, version 3.2.1 has been released which includes log4j-api-2.16.0.jar. Version 3.2.0 included log4j-api-2.15.0.jar

It is a good idea to scan your server hard drive for files with log4j in the name, for example on linux servers you can run this:

find / | fgrep log4j

Fixinator has been updated to scan for vulnerable log4j jars, and also flags spreadsheet-cfml@3.1.0if installed or listed as a dependency in your box.json. Fixinator does not do a deep scan within jars at this time. Some have found this tool handy for scanning jars: Log4JShell-Bytecode-Detector.

CISA has created a log4j affected products db which you can check.

Are only certain versions of Java Vulnerable?

There is a lot of confusion around this point. My understanding is that the version of java might make some attack vectors (such as JNDI LDAP) safe by default, but not all attack vectors. So the possibility still exists in any version of java from my understanding.

Is log4j 1.x vulnerable to CVE-2021-44228?

Again, it is not currently listed as an affected version, but it is also considered end of life, and they do not plan to fix any issues (including prior security issues already known). According to comments on here it appears that the JMSAppender in log4j 1.x may have a similar issue , however you'd need to have the JMSAppender enabled. You can check to make sure you are not using the JMSAppender to confirm.

Update: JMSAppender issue has been given identifier: CVE-2021-4104

Check log4j configuration to make sure you don't use JMSAppender or SocketAppender (CVE-2019-17571) such as:

  • logger.xml

I have published a ton more info specific to Log4j 1.2.x vulnerabilities.

Here's some java or CFML code you can call to check the log4j version at runtime.

DISCLAIMER: The content (and links) on this page are provided as is, without warranty of any kind. Use at your own risk. You should consult with your software vendors to ensure that you are properly protected.

(Sat, 11 Dec 2021 00:25:00 GMT)
[view article in new window]

Listing loaded OSGI Bundles in Lucee

Here's a quick code snippet that will output a list of OSGI java bundles and bundle versions that are loaded / installed on Lucee:

engine = getPageContext().getCFMLFactory().getEngine();

bundleContext = engine.getBundleContext();

//array of org.osgi.framework.Bundle objects
bundles = bundleContext.getBundles();

for (b in bundles) {
  writeOutput(b.getSymbolicName() & ":" & b.getVersion() & "<br>");

Here's a link to run the code on trycf. It was inspired by the "getBundles" action of the cfadmin tag (source).

You might be wondering why not just use the cfadmin tag, well it requires a password for all operations, which makes sense for many of the operations, but I don't think it should be necessary to list the bundles.

(Wed, 15 Sep 2021 22:14:00 GMT)
[view article in new window]

Replacing Twitter Share / Follow Widget Buttons with CSS

While looking at the PageSpeed Insights for my blog I noticed that the Twitter widgets I was using to display a twitter follow button and a tweet / share button were causing some page speed issues. Specifically the TBT (Total Blocking Time), LCB (Largest Contentful Paint) saw an impact. Overall it was taking about 151 KiB and blocking the main thread for 56ms.

Here's an example of what I was using:

<a href="" class="twitter-follow-button" data-show-count="true" data-size="large">Follow @pfreitag</a>
<script async src=""></script>

That loads the following button:

Taking a look at this script, it replaces the button with an iframe, it's just quite simply overkill for what it does.

Replacing the Twitter button with pure CSS

It should be easy enough to replace this button with a pure css implementation. First, we should replace with a twitter intent to follow url, for example: We can also get rid of data-show-count="true" data-size="large" in the link. One thing our new solution won't have is that nice follower count, but I can live without it. It would be possible to add that back in again, perhaps using a hard coded count to keep it efficient.

Finally here's the css we are using to make the button look similar to the twitter follow button:

.twitter-follow-button, .twitter-follow-button:visited {
    background-color: #1b95e0;
    color: #fff;
    border-radius: 4px;
    height: 28px;
    font-weight: 500;
    font-size: 13px;
    line-height: 26px;
    padding: 8px 8px 8px 30px;
    text-decoration: none;
    background-image: url('/images/twitter.png');
    background-repeat: no-repeat;
    background-size: 16px 13px;
    background-position: 8px 10px;
.twitter-follow-button:hover {
    background-color: #0c7abf;

One thing you'll note is that we are using an image for the twitter logo, if you want to make the button even more efficient you can just use something like this:

.twitter-follow-button, .twitter-follow-button:visited {
    background-color: #1b95e0;
    color: #fff;
    border-radius: 4px;
    height: 28px;
    font-weight: 500;
    font-size: 13px;
    line-height: 26px;
    padding: 8px;
    text-decoration: none;
.twitter-follow-button:hover {
    background-color: #0c7abf;

Another good reason to remove the twitter JavaScript is that it also makes the Content-Security-Policy for twitter buttons much easier to implement.

A comment from Jan pointed out a third, really good reason to create a simple css twitter button is that it also improves the privacy of your web site visitors. When you have third party JavaScript loading from other sites it allows them to track visitors across the internet which they are probably using to build advertising profiles.

To see an example of the pure CSS button take a look below the end of this entry.

(Wed, 07 Jul 2021 20:19:00 GMT)
[view article in new window]

© The connection to the FREITAG's RSS feed has timed out - please try again later. We are sorry for any inconvenience this may have caused.