[Looking for Charlie's main web site?]

ColdFusion March 2023 emergency update, and what to do about it

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:

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

, 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: 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
Hi Charlie, many, many thanks for this comprehensive blogpost. Much appreciated!
# Posted By Jos | 3/17/23 6:42 AM
Thanks Jos. Such feedback is very much appreciated.
Is there any reason that we can not/should not just remove wwwroot\cf_scripts\cfclient folder? I know that I do not know the actual exploit, so I do not know if it is related to the actual code in this folder or something else.

I know ideally everyone would be on current versions of ColdFusion, but we work with multiple different clients that have different upgrade cycles , and some are waiting for 2023 to come out, so I am looking to support those as much as possible.

If it is not this code, and is someplace else in ColdFusion:
1) Does -Dcoldfusion.cfclient.enable=false work on CF 2016? I am guessing not, but just curious
2) Is there a way that if we are not using CFClient to just remove it from old servers?

Thank you.
# Posted By Matt | 3/17/23 9:41 AM
Thanks, Charlie. Your thoroughness is appreciated, as always.

Question...the CF Admin has an option "Enable mobile's server workflow" to turn on/off. If this is turned off, is the server still vunerable?
# Posted By Paul | 3/17/23 11:26 AM
Many thanks to Charlie for finding this hack and this extensive blog with all the details! As we use IIS, I found using IIS Request Filtering to block the query string was simple, quick, and effective.
# Posted By John D | 3/17/23 2:12 PM
Charlie, I can't imagine being so confident in CF without all of the amazing insights and work that you do to support the community. Thank you!
# Posted By Rich | 3/17/23 2:14 PM
As always Charlie, thank you for taking your time and sharing all this invaluable information with the community! My servers are all good now :-).
# Posted By Giancarlo Gomez | 3/17/23 2:23 PM
Wow, lots of questions, and too many for me to answer at once. Let me take them one at a time, and it will be between client engagements, so apologies for the delay that there will be.

Matt, no, removing cf_scripts is NOT the solution to this problem and it would not help. And yes, I mean even if you or someone you know found evidence that that was used to perpetrate that "specifically crafted URL" I hinted at.

Let me be clear: it's NOT the files in that folder that ARE allowing the hack. So no, the bad guys could use other files. I will have to leave it at that.

Bottom line, it's the _cfclient querystring that is the key to the problem, not the files used in referring to it. I know I'm not giving enough detail for folks to figure things out: and that's the point.

As for the jvm arg, no. As I note in the post, that is NOT something you can "just do" in CF2016. It will mean NOTHING to CF 2016 or 11, or to CF2021 or 2018 before the update is applied. The jvm arg is for someone who APPLIES this update and yet DOES want to be able to use cfclient.

Finally, as for you asking how to remove it from old servers, I'm not aware of any way to. Again, this problem is inherent in how CF itself processed that _cfclient querystring, not some page that was called.

So someone on CF2016 (or 11) should use the other approach I offered, of simply blocking that _cfclient query string. I made that clear. I think you're trying to consider some potential corner cases or alternatives that I might have missed. I get it.

But please let me know if you now feel that you have all the info you need to proceed safely.
Paul, great question. I will try that on a server where I have not applied the update (or the block), to see if the bad guy URL would no longer "work". If so, then yes this would seem a helpful alternative solution.

That said, nothing about the alternatives I offer should require an alternative. It would seem this would lead to the same result. I'm about to enter another client call so can't test it now.
John, Rich, and GC, thanks very much for the kind regards! :-)
Thanks Charlie, owe you a pint!
# Posted By Will Mulder | 3/18/23 7:41 AM
We have CF2016 servers so the advice from Charlie is very much appreciated. I'm so glad the "fix" was easy to do. Thank you for providing this info and confirming it works. You're completely right not to give too much away about how exactly the hack works.
# Posted By Gary F | 3/18/23 6:35 PM
Glad to have helped. Thanks, Gary (and Will).
Thank you so much for this blog post. It had just the right amount of information. Did you see that Adobe also released several other updates for other products with similar wording to the coldfusion bulletin? https://helpx.adobe....
# Posted By Dana | 3/20/23 12:54 PM
Dana, thanks first of course for the kind regards. And yep that's interesting about the other products. Perhaps you're wondering if there's maybe some connection among them all--even to the point of wondering how then this contention about "cfclient" can possibly relate to what those other products also addressed.

I can only say this: of all of the products listed as having updates that day, only AEM is "like" CF (in being a Java-based application server). And what it lists are not the same cve's.

I suspect instead this was Adobe's version of a "patch Tuesday", where they released at once many updates for many products.

If somehow time or insights shared here might show that there's indeed some connection among them all, that will be very interesting.
Charlie, thank you as always for keeping us informed on these important updates. We don't see this level of information/detail from Adobe, which really would be helpful. Regardless, we are grateful for you.
# Posted By Lance | 3/20/23 1:44 PM
Thanks, Lance.
Thanks as always Charlie for the helpful information. We immediately put the quick fix into place for IIS and Apache, and installed the 2021 update over the weekend. Appreciate the detailed information.
# Posted By Tony Brandner | 3/20/23 4:28 PM
Great to hear, Tony, and glad to have helped,
I want to add an update that Rapid7 came out with a blog post/announcement today about a CF vuln:


...but they don't connect it readily to this one. Even so, I am fairly confident that what they are finding is the RESULTING bad-guy file that I discussed in this post as the second aspect of the vuln (the "arbitrary code execution", or their ability to cause placement of a bad-guy file on your server.)

Sadly, the Adobe technote and PSIRT/APSB bulletin as well as Mitre CVE's don't give enough detail to readily allow Rapid7 and others to connect the dots to this vuln and the update from last week. And they likely are unaware of my post here.

But I wanted to point this out in case others finding or following this post may "wonder" if that is some "new hack". I really don't think so. Once those folks dig further they should find that the root cause was this _cfclient querystring and the rest of the "specifically crafted url" (which I can't share, as it would allow perpetration of the hack).

Bottom line: get your CF2021 and 2018 updated to the March updates (6 and 16, respectively), or get the block of the _cfclient querystring var in place, all as discussed above.

This addresses CVE-2023-26360 but not CVE-2023-26359, correct?
# Posted By James | 3/22/23 12:17 PM
I assume the "this" is this post (as the update definitely addresses both). As for your question, I'm afraid I can't really know. There's not enough detail in those CVEs to tell.

I suspect you're asking because in the apsb, my name is associated only with the one CVE. You're likely wondering if perhaps my post only covers SOME of the vulns identified in the apsb.

Again, bottom line: folks should apply the update (which clearly prevents the very serious hack as I'd reported to them days before), or implement at least the block I'd offered--whatever is the cve/s that it relates to. I'm afraid Adobe just didn't offer more to help on your question.
Thank you so much for this blog post,it help me a lot.
I notice Adobe rate this cve as CVSS 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N), the Integrity and Availability Impact are None.If this vulnerability can lead to arbitrary code execution, i think the Integrity and Availability Impact should be High.So I wonder if the official patch actually fixes this vulnerability(CVE-2023-26360)
Look forward to your reply, thank you again.
It absolutely does. I also don't understand their scoring or attribution. But I can say with 100% confidence that this update prevents the vulnerability I describe, including both the arbitrary file read and the arbitrary code execution.
Thank you for your reply.In addition, You mentioned that if I were attacked, i will see .log or .xml in my cfclasses folder, What is the reason for this? Can I defend against this vulnerability by prohibiting the generation of .xml and .log under this directory? It's easier for me.
The class files are evidence of the hack having been perpetrated, they are NOT the MEANS of the attack, anymore than a fingerprint should be defended against in a crime.

The thing to defend against is the _cfclient in the query string, as discussed (to death) in the post. Here again, the mere presence of that string is not THE HACK, but it's the WAY it's used: just like how a gun in a robbery alone will not kill or wound anyone, but can be USED to do so.

Since these questions remain for you, I think you'd find value in reading the post again, from the top. It was a LOT to take in. I'd hope on second reading any questions would be more completely answered.
A detailed analysis of the vulnerability and the underlying vulnerable components has been published here -- https://attackerkb.c...
# Posted By Brian | 3/30/23 9:59 AM
It's certainly an interesting effort they've done. They're concluding attack effort is indeed something quite different from what the hackers I saw did, though what they shown is bad enoug).

Some will benefit from their effort, sure, but of course some will also use it to effect perpetration.

I was careful NOT to show the "how", but we can't control what others may say and do. Anyway, thanks for the heads up.
Charlie, you've done it gain. Thanks so much for such detailed response to this; in my case helped me to not just shrug shoulders and say we are on CF2016, not much we can do! And yes I know, my client IS looking to upgrade asap.
# Posted By Bill Tudor | 4/6/23 9:36 AM
Thanks, Bill, and glad to have helped! :-)
Charlie - thanks for the thorough document - very much appreciated like everyone else.

We've added the Request Filtering in IIS to deny the _cfclient query string on all of our servers and applied the patch to most of them. We are running Java 11.0.11 in most cases but the Security Bulleting mentions:

Adobe recommends updating your ColdFusion JDK/JRE to the latest version of the LTS releases for JDK 11. Applying the ColdFusion update without a corresponding JDK update will NOT secure the server. See the relevant Tech Notes for more details.

To your knowledge, is it a requirement to update Java to 11.0.18 to be fully patched?

Thanks in advance.
# Posted By Mike Pelant | 4/12/23 5:53 PM
Thanks, Mike. And to that verbiage you quote, it's an understandable question/confusion.

It's simply there in every CF update--because SOMETIMES an update they do MAY presume to leverage also some aspect of a latest JVM version. But note they are not specific about that (ever), and I am not aware of this fix having anything to do with Java.

That said, given that CF runs on Java it is indeed always wise to run on the latest update of the JVM version which your CF version supports (for the sake of its own security and bug fixes). And for CF2021 and 2018, that is currently (only) Java 11: and the latest 11 is 11.0.18 which came out in January. (11.0.19 will come out next week, FWIW.)

Before you may update the JVM, note that I did a blog post on that 11.0.18 update where I mentioned 3 related issues: one for people moving to 11.0.17 or above, one for people moving to 11.0.11 or above (but you're already there), and one for anyone running the JDK installer for 11.0.18 or above. See that post here:


I would plan to do another post when the next JVM updates come out next week.
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting