If you've not heard, a new update has been released (March 14, 2023) for ColdFusion 2021 and 2018. Despite what you may hear, this is an URGENT (rated "Priority 1" by Adobe) update that everyone should apply ASAP, for reasons I will explain in this post. In fact, Hackernews reported yesterday (Mar 16) that the U.S. Cybersecurity and Infrastructure Security Agency (CISA) had issued an urgent warning about this, giving federal agencies a deadline to apply the update.

TLDR; For some folks, the above may be all you need to hear: you may be dropping your coffee and donuts now to get the update applied. Still others will see this "huge post" and think, "crap, I don't have time for this". For you, skip to the bottom and its "concluding key points". You can then decide what you think you do or don't "need to know" and pick and choose from the sections as you like.

Finally, for those who prefer because of the importance of all this to be led more carefully through understanding things (in a way that's worked for the many people I have helped so far this week, and is far more than either Adobe or Hackernews has shared), please do read on.

As indicated in the technotes for the update, it "addresses vulnerabilities that could lead to arbitrary code execution, arbitrary file system read , and memory leak." The first two especially should get your attention.

After pointing to and offering information on obtaining the available CF update, I'll go further to discuss:

• be careful about thinking "this vulnerability doesn't apply to us" (I've seen many people coming to incorrect conclusions)
• what the vuln enabled (a hack which is scary, that could be easily perpetrated on any CF instance from CF2021 to CF11, prior to this update)
• how might you check if you were hit with the hack?(something not mentioned in Adobe's security bulletin, update technotes, or other announcements)
• what if you find you WERE hit?
• how to protect yourself without the update, if you need time to get the update deployed--which will also help those on CF2016 and CF11, as Adobe no longer updates those but they are also vulnerable to this hack
• some tips to address trouble some have had applying the update
• additional protections you could consider to help temper such hacks

Before moving on, I do want to clarify further the first point above: the hack I discovered CANNOT be perpetrated against Lucee (as it never implemented the cfclient feature that is being leveraged), but note that it CAN be perpetrated against Commandbox (if using an adobe cfengine prior to this this update). Granted, most devs may trust that the random port Commandbox exposes by default is one that "no one can get to", but do note that if that may have be configured to be exposed otherwise (such as via a web server like IIS, Apache, or nginx), then of course anyone who COULD access that web server may be able to run CF requests against it, and thus they could run the kind of request behind this hack (more on that below).

I. About the updates for CF2021 and 2018

Before offering my elaborations on things, let's get some basic points about the updates out of the way.

First, the updates are CF2021 update 6 and CF2018 update 16, and as usual the updates should appear in your CF Admin and be downloadable/installable from there, if your server has internet access (or at least the domains for the updates are accessible: www.adobe.com and cfdownload.adobe.com). Otherwise you can obtain and apply the updates manually, as discussed in the update technotes. (Note that the manual update steps differ between CF2021 and CF2018.).

(BTW, if you obtained the jar or zip to apply the update manually to CF2021, you may find that the manual update process failed to work correctly. Adobe fixed that and issues an updated version of the jar and zip for CF2021. Just go get it again.)

For more on the updates, see the Adobe discussions in the following resources. It's great that they have taken many steps to spread the word, though they've been rather spartan and perhaps not as clear as they could be about the vulnerability (thus more to follow in this post):

• The technotes for CF2021 update 6 and CF2018 update 16. As always, the technote has information on obtaining and applying the update, including important information if you may be skipping from updates earlier than the immediately precending one (more on that topic later here)
• The APSB (Adobe Product Security Bulletin) regarding the security vulnerability (or in this case, vulnerabilities) addressed by this security update, APSB 23-25, which includes the "Priority 1" rating I mentioned above, and the CVSS scores of the vulnerabilities (the highest being 9.8 out of 10), as well as the CVE/CWE classifications of the vulns. Again, I will share more on the reason for the high score in the next section.
• Adobe's blog post about the update on the CF portal (including comments from others)
• Adobe's forum thread about the update, in the CF Community Forums (including comments from others)
• Adobe's Facebook post about the update on the CF programmer's group (with comments from others)
• Adobe's Slack channel mention of the update (with comments from others)
• No post still as of today, Mar 15, on Adobe's twitter account

II. Be careful about thinking "this vulnerability doesn't apply to us"

Before I jump into the details about the vuln (and the hack), I want to address a few points where I have seem people making incorrect conclusions about what they have read or heard regarding this vuln and the hack that can be perpetrated.

First, the technotes indicate that with the update Adobe has "disabled cfclient by default". Now, some are misreading that as being about the "client variables" feature in CF, but it has nothing AT ALL to do with that (and whether you use them or not).

Far more important, DO NOT hear that mention of cfclient and conclude, "Oh: we don't use that, so we can relax." No, no, NO! That's like saying you don't need to worry about a vulnerability in your home's window locks because you "only enter the house through the door"! It's the BAD guys who were leveraging a vuln that is merely RELATED to an aspect of the cfclient feature--whether you and your code use that feature or not! But yes, the update WILL disable that cfclient feature (and thus this vuln).

Finally, some are saying, "oh, our servers aren't open to the internet". That, too, is NOT going to protect you. If you have connected as web server (like IIS or Apache) to CF, for any app at all, then a call made into that web server that got to CF could be used to perpetrate this hack. It does NOT matter if users need to "login" to your app: this request won't even go against "your app" but against "CF", itself. And the same thing is true of the built-in web server (used for the CF Administrator, typically, such as at port 8500). Anyone who DOES have access to that port could potentially try to use the hack URL.

With that as preface, let's move on first to the vuln and the hack it enabled.

III. What the vuln enabled: seriously bad stuff

As is the nature of security bulletins, the resources above are rather spartan in their indications of what was possible if this vulnerability was perpetrated against your server. While it's true that discussion of such hacks is a very sensitive subject, and I will not offer here HOW to perpetrate the hack, I WILL at least offer more info to help you try to find out WHETHER the hack was perpetrated against you.

But let's start with better clarifying what the update technotes and APSB bulletin mean when the vuln "could lead to arbitrary code execution" and "arbitrary file system read", what that means is that a bad guy could use a specifically crafted URL to view ANY file that CF could access. Yep, that's bad.

But it gets worse: they could also then use a specifically crafted URL to cause a CFM file to be placed on your server in a web accessible folder, like the cfusion/wwwroot, while also pulling down into that file (from a remote server) CFML that offered a "shell" which then would allow the hacker to basically perform any action that CFML could perform, including querying your databases, add/change/delete files, export data or files off your server, and more. Yes, very, very bad. Now do I have your attention?

This would be classified as a zero-day--and in fact I was so wishing I could tell folks about it sooner, but I was embargoed from discussing it until the update was released. Let me add also that while I found it with a client a couple of weeks before (when I reported it to Adobe), I also found evidence on another client's server that the "bad guy URLs" causing the hack were attempted as far back as Dec 2022. (Again, I wish I could share the details of the URL, but I can't--but that's why I share below the importance of searching your logs for the appearance of the _cfclient query string value.)

What's the connection to CFClient?

And now do you see how this problem has NOTHING to do with "whether you use cfclient or not"? So what's the connection to cfclient? I'll just leave it at the fact that this "specifically crafted URL" was leveraging something that CF's "cfclient" feature enabled. It's not something YOU might ever use, but it was something the bad guys figured out THEY could leverage to perpetrate this hack. Again, I will show later how you can look for evidence indicating whether someone had perpetrated the attack.

As for this cfclient feature, which offered to enable mobile device support, it never really took off. But it was added in CF11, which is why the vulnerability extends also to CF2016 and CF11--which again are are no longer updated by Adobe, so there will be no fix offered by them for this. See below for how you can protect yourself if you are still on those old versions--which have still other significant security vulnerabilities that have been fixed only in later CF versions. (Again, it's because Lucee never implemented the cfclient feature at all that it is not vulnerable to this specific hack.)

How it is I am so confident of what I'm sharing here

And I can clarify that I know exactly what the "specifically crafted" URL was that enabled the ability to view any file and cause creation of a shell script to then allow performing any action. I found the vulnerability (while helping a client who detected the file creation, thankfully), and after gathering more evidence and information I reported it to Adobe (and to Pete Freitag, who later added some more valuable insight), and Adobe then implemented this fix.

And I can confirm that after applying the update (or the protection I'll share for those who can't apply the update), that bad guy URL could no longer view files or cause creation of the bad guy shell script file.

I should add that there is that mention of a 3rd characteristic of the vulnerability that's "fixed" by this update: a "memory leak". Note that the discussion of that in the APSB relates it to "path traversal". I know that the part of the hack I saw did also leverage "path traversal" (allowing the "specifically crafted url" to point to files in any folder it had access to, on the same drive/file system that CF was installed on). I had not myself noticed any aspect of this involving a memory leak, but folks should take this into consideration as simply another reason to apply the update.

What if you DO use cfclient?

If somehow you (or some CFML app on your server does) USE the cfclient feature, note that the update disables that by default. Adobe took this "scorched earth" approach to block the serious nature of this vulnerability. But note that the update technotes clarify that if you DO use cfclient then you would likely NEED to use the offered JVM argument to re-enable that feature (

: it's false by default as of and after this update). As I don't use that feature, I can't speak to the details of the impact of that JVM argument on its functioning.

But note that the technotes also offer yet ANOTHER JVM argument related to this,

) that controls whether the cfclient feature can cause "reading" of any extension other than a CFC (which I won't elaborate on here). I would STRONGLY recommend that you NOT enable that to be true unless you find you must--and in that case I would suggest you reach out to Adobe to discuss this further, using their [email protected] email address.

To be clear, both these JVM arguments are NEW as of this update. They would have no impact at all (and would be simply ignored) if you try to use them with an update of CF earlier than these two from March 2023.

IV. How might you check if you were hit with the hack?

So assuming you'll either apply the update (as discussed above) or the other protection I offer below (if you can't apply the update), you may still wonder: "how can I know if the bad guys" hit my server?

To be clear, this is something not covered at all in Adobe's security bulletin, update technotes, or other announcements. Indeed, I am walking on thin ice in adding this discussion, but I think it's important because it's not enough to know you "fixed the castle door"...if the bad guys got into the castle before you fixed that door.

While I can't say I can help you prove with 100% confidence whether the hack was perpetrated on your server, I can at least offer a couple of means by which you can look for evidence that would be left behind if it happened. Think of it as looking for fingerprints.

(And of course I can't offer here the "specifically crafted URL" that would allow you to confirm THAT the hack COULD be perpetrated--valuable though that would be--because doing that would expose to the bad guys--whether out in the wild or perhaps in your own organization--who could use that to again a) display any file CF can access or b) lead to the creation of a file on your server. Instead, let's focus on a) finding any evidence and b) closing that door--whether with the update or otherwise.)

Evidence #1: Look in the CF cfclasses folder, for files following a certain pattern

As some may know, when one executes CFML (makes a request for a CFM or CFC file), CF will compile that CFML into Java, and there's a setting in the CF Admin ("save class files", on the "caching" page, which is enabled by default) to have such a compilation saved into a folder within CF, called cfclasses, located at CF's cfusion/wwwroot/WEB-INF/cfclasses folder (if you have more than one instance, that would be [instancename]/wwwroot/WEB-INF/cfclasses folder). The primary benefit of this saving of the compiled class file is so that on a CF restart, the compilations need not happen all over again.

Any time a file is created and first run, or if it's run after the CFML source is edited, the class file for that file (in that folder) would be updated. (Technically, if you have the related "trusted cache" setting turned on, then editing a file would not cause recompilation until a CF restart or clearing of the template cache...but this is getting into the weeds relative to the point of this post.)

Anyway, the pattern of file names in that cfclasses folder is that they all start with "cf", then they have the filename and extension but with a 2e for the ".", so that an index.cfm would be cfindex2ecfm, then that's followed by a number which represents a form of a hash of the original CF file's location. (I have a post from 20 years ago with more on that.)

Well, if the vulnerable "specifically crafted URL" is executed, causing display of a log file or xml file, you would find in that cfclasses folder a file with the pattern not of *2ecfm* or *2ecfc* but instead

or , indicating that somehow a .log or .xml file ended up there. Again, I am NOT going to disclose the "specifically crafted URL" that would be needed to make that happen, and there's no way anyone could determine it from what I am sharing...though again I realize that some would argue I'm already "sharing too much".

You can search this folder using either the simple search feature in Windows File Explorer, or the Linux Find command, or any other tool that facilitates searching for files by name. (For Windows, I highly recommend the free tools File Locator Lite and Ultrsearch, both of which I've blogged about before.)

And while I'm trying to share in this section enough info for someone to at least TRY to check if any such file appears there, let me warn that before you rely on this completely, there some caveats to consider:

• If you find you don't have ANY files in the cfclasses folder, then someone has unchecked the "save class files" feature in the CF Admin. In that case, you can't use this folder to find this "evidence"
• Similarly, if you DO have files in that folder but none are recent, then there's a good chance someone turned that setting off in the past--so that the files you see are leftovers from when it WAS enabled. If that's it IS disabled, then it means again that you can't use the information in this folder as the "evidence" I propose. If the "save class files" IS enabled, this lack of recent files could just mean you've not had any new or recently edited CFM files.
• Do be careful not to over-react if you DO find some file matching the *2elog* pattern: if what follows the 2elog in the file name is NOT numbers (again, representing a form of a hash of the location of the file), then that's NOT evidence of the representation of a .log file having ended up here. More specifically, if you see some filename with a pattern like something2elogin2ecfm followed by numbers, that merely means the name of the file was something.login.cfm, and the ".log" within that is not representing a file EXTENSION of .log--which again would be followed by numbers in the pattern of files here
• Finally, this "evidence" I refer to is related to that "specifically crafted URL" which I found had been used to perpetrate the hack on clients (yes, more than one) who I helped in finding and researching this hack. I can't know for sure if there are other evidences of other aspects of the vuln(s) fixed by this

Even if somehow you can't rely on the evidence above, there is still other evidence you can look for.

Evidence #2: Web server access logs (tracking each request coming in)

Another place to look for evidence of this hack having been perpetrated is in your web server's access logs, which should be logging every incoming request (for static files as well as CF requests). Both IIS and Apache (the primary web servers supported by ColdFusion) do log requests by default.

Again, I can't give out here the details of the "specifically crafted URL" (to have you look for or try that), but I feel I can safely disclose just a tiny tidbit that at least was distinctive in that URL--and we can then look for that in our web server access logs. And it's related clearly to the feature that the update disables by default: cfclient.

More specifically, if you look in your access logs for any requests having been made with a querystring including the phrase:

(an underscore before cfclient), that will either be there for legitimate use of the cfclient feature (which I've still not seen in the wild, in all the servers have helped people in mitigating this, so far), or it would/could be an illegitimate/illicit/hacky use. If you find one and are concerned, you can send it to me (contact info on the right) and I could confirm or deny.

Let me note at this point also that below I talk about also how/why you may want to search for the uuencoded variant of that _cfclient string as:

You should look for that as well, as the web server access logs would track it as having come in that way. But good news is that the BLOCKING features I discuss below DO properly decode that before checking for the string to block (so you don't need to "block" that querystring).

(And it may help some readers to know that the "query string" in a URL is the portion that follows a filename and then ?. In CFML, we regard those as "url variables". And in web server logs, the query string is always logged by default, after the file name--typically separated with a space, FWIW, and NOT with a ?.)

As I noted in the last section, you can use tools to make it easy to search for that string (which do the job far better than Windows search, for instance, or even better than the file search features of popular editors like VS Code, Sublime, and Notepad++, as well as traditional CF editors like CFBuilder, Dreamweaver, HomeSite+, and so on.) But, if you do use any such tool to search the IIS or Apache logs on Windows, be sure to "run it as admin", so that it can see all the log files. Linux users will of course tend to favor grep as their go-to tool for searching files by content. On Windows, I favor again File Locator--and I'll note that its "Pro"/paid version has the ability to search through files that are zips, which may be important if your web server logs might get zipped up after some period of time.

(And if you may use the tool, GrepWin, as I found some of my clients using, be sure to change it from doing a "regex" to a "text" search, as well as change its "limit search" feature from the default of only searching files where "size is less than 2000k", changing that to search files of "all sizes".)

There's indeed much more I could say on this topic of searching your web server access logs. At some point I may do another post with more on things such as the following:

• How to find where your IIS access logs are (including making sure you look at the folders for the logs for EVERY site)
• How to find where your Apache access logs are
• Tools that make searching through such logs easier, from built-in ones, to ones you can easily add, to saas-based logging tools you might leverage
• Why it's important in IIS to run any such local tool "as admin" to make sure you are looking into folders that you might be blocked from, even if you ARE an admin
• Why it's important to beware, notice, and deal with the fact that something may have been enabled on your server to zip up the web server access logs after some period of time, which could make them harder to search
• Why it's important to make sure all sites ARE logged, and that they reflect current traffic being tracked (again, so as to make sure you can trust your search results)
• Why I would propose it's important to search first to see/confirm how many days of log files you have, relative to the number of sites you have, so you can trust the sites ARE being logged
• Why I would also propose you do a sanity check to make sure that whatever search tool or feature you use DOES find some string that you know DOES exist in those web server logs
• How the cf built-in web server and undertow web server within Commandbox (if you are using that with CF) do not by default log requests, and how to enable them if you wanted to

While I know that some reading this post may "need" that additional info now, the post is already long and taking very long to write. People want the key details and are awaiting my delivering that. So these topics will have to wait for another post.

Again, the previous section's "evidence" has so far been a more accurate predictor of whether the hack was perpetrated on a given CF server. (Indeed, as for that last bullet point in the list above, that discussion would ALSO apply if a request was made with that "specifically crafted url" against either the CF built-in web server or the Commandbox undertow server running with CF.)

Beware encoding

That said, I will note again one last thing: some may want to point out that bad guys will often encode a querystring or its values. Indeed, when I first encountered this hack with a client, much of the querystring WAS encoded: specifically URL-Encoded UTF8 Unicode, so lots of it was %'s and two-digit number. (There are useful tools to allow you to encode/decode such strings, such as this and this and this.)

But a key point here is that the web server access logs (for IIS and Apache) will indeed log the URL exactly as it came in, so it's true that if this string were encoded, it would be encoded in the logs and you'd need to consider looking for that. (This is the sort of stuff that can make talking about all this so difficult, as there are so many angles to consider.)

But I will say this: I never saw the _cfclient phrase encoded in the cases where the hack had been successful (per the other evidence above). But if you may want to look for that _cfclient as a url-encoded uft-8 unicode string, the value is: %5f%63%66%63%6c%69%65%6e%74.

But let's move on to other matters.

V. What if you find you WERE hit?

This is tough news to share, but I've told you how bad the vuln is. If you DO find evidence that the bad-guy URL was used on your server, you will be able to see readily in the web server access logs what this "specifically crafted URL" was.

And as for the first part of the hack, where they could "see any file", at the end of the URL you may find you would be able to see the path and name of the file that they attempted to view. (If it's encoded, use that urldecoder.org web site that I'd just mentioned, which will decode the string into clear text for you.) If they file/path they requested is valid, they were able to see that file. That's bad enough.

The worse news is if you find they ran a variant of the URL that did MORE than just view files. Again, I can't offer an example, but if you find that any of the requests (with that _cfclient query string and more) refers to cfhttp or cfexecute, for example, that's part of how they were able to perhaps cause a file to be placed on your server: typically that shell script that then allows them to call that page to do about anything.

So first, you may wonder, "where should I look for the file they may have placed there?" And the fact is that they could put it ANYWHERE that CF could write to, but in my experience helping people they were putting one or more files in the cfusion/wwwroot folder (which normally is served only by requests to the built-in web server. But there's a little-known behavior CF has where it WILL look into the cfusion/wwwroot (or your [CF]/[instancename]/wwwroot if running multiple CF instances in CF Enterprise or Developer) for a requested file, if it's not found in the root for your site in your web server (IIS or Apache, typically). So again that's where they would write such a file (this has been a characteristic of the past few similar remote file execution vulns in CF). But again it could be in ANY folder CF could access, and that was web-accessible so that they bad guy could access it.

Second you may wonder, "how can I know if they DID put a file somewhere?". Again, that's hard to know. The URL may give you a clue, but once they put one file in place they could then call that to put still other files in place: indeed, they could edit your OWN files, modifying them in some nefarious way. And this is of course the nightmare scenario: you'd understandably be panicked, wondering "goodness, what all could they have modified"? So this is why I focused above on helping you find evidence of their having even perpetrated the hack, if that's possible to find. At least if it's not, you can worry LESS (though not completely).

Third, you could use the search tools (discussed elsewhere in this post) to find files on the server with a modified date/time that is on or since the date that you found the hack attempt, looking both in any site webroot or in the cf wwwroot (and subfolders).

Fourth, do you use version control/git/etc? If so, you could compare a last known good version of the code from BEFORE the date you found the hack was perpetrated. That may help you readily detect unexpected changes on the source files in your server. Even if you do not, do you perhaps have a local copy of the code that you only "push up to the server"? If so, you could compare THOSE two codebases. For that comparison task I will note that I love the tool BeyondCompare for this job (and which works on Windows, Mac, and Linux--and has a free trial that's 30 days of USE rather than 30 days from install). It can even do a compare over FTP if you may still be working that way. It just does a better job comparing folders, files, and simply text than any other tool I've ever used. I realize everyone has their favorites. For more on it, see a post I did in the past.

(I will mention toward the end of the post how there are also file change detection tools that one could put in place to help warn or even BLOCK such unexpected file writes, so that you know of the problem BEFORE it happens. That is how the first client I helped did detect the problem, which led to our digging in and then my identifying how it had been perpetrated, which I then reported to Adobe.)

Finally, as for the bad-guy shell script, if that got put on your server, again you may see calls made to that file (whose name would be indicated in that second kind of hack URL, but which could be random). Sadly, the calls to that shell script (CFM page) will be form post's, and nothing logs what gets passed to form posts: not web server logs, not CF logs, not even FusionReactor (the popular monitor for CF). I do realize that if you find many post calls to such a shell script, there will be nothing you can do but lament terribly about what may have been done. And I realize that for some, they may feel this situation might warrant their rebuilding the machine from scratch, perhaps taking stronger security measures going forward. Again, I talk about some of those you might consider, toward the end below.

Let's move on now to how folks can protect themselves, especially those who have NOT yet been hit with the hack (but those who have may want to consider this also).

VI. How to protect yourself if you need time to get the update deployed, or are on CF2016 or 11?

While applying the update is the best "medicine" against this hack, I do realize that some folks may still "need time" before they can arrange to perform this update: maybe they can't restart CF during the day (despite the urgency of this update), or perhaps they wisely want to test against dev/test/qa/staging first (which is always smart). If they're reading this now and won't be able to do the CF update for hours (or even days), must they remain vulnerable? No.

Recall that I discussed above one of the evidences of the hack was an incoming URL with a querystring having the value of "_cfclient" (without the quotes). There is additional info beyond that, of cou

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed