NOW LIVE! Adobe ColdFusion 2023 and 2021 March 2024 security updates

[Saurav_Ghosh]

Revision history

• 13 Mar 2024: Added the impacted scopes and related code samples to both the tech notes.
• 14 Mar 2024: Add the Docker image locations of the updates.

We are pleased to announce that we have released security updates to ColdFusion (2023 release) Update 7 and ColdFusion (2021 release) Update 13.

This update includes several security fixes to ensure the safety and security of our systems. These changes address potential vulnerabilities and threats and are part of our ongoing commitment to protecting your data and privacy.

For more information, view the security bulletin,  APSB24-14.

Where do I download the updates from

Download the updates from the following locations:

• ColdFusion (2023 release) Updates
• ColdFusion (2021 release) Updates

These updates address some significant changes in variable scope and cfdocument. In addition, we've updated a few libraries and packages.

For more information, view the following tech notes:

• ColdFusion (2023 release) Update 7
• ColdFusion (2021 release) Update 13

Are the Docker images available

The images are available on the Docker hub and ECR.

Please update your ColdFusion versions and provide us with your valuable feedback.

[Charlie Arehart]

It's very important that people read the technote before "just applying this update". There is a very important (and fundamental) change in how CFML processes variables, with regard to searching for scopes when no scope is indicated on a variable name (at least in many cases. See newer comments below.), as the update changes CF's default behavior for an application setting called searchimplicitscopes. That was introduced in CF2016, and it defaulted to true, but this update changes that to default to false.

This is almost certainly a BREAKING change in many CF apps--and it's a change Adobe has implemented for the sake of security, it seems. For more on that, see the technote. (Update: for more on what apps might break, see my later comments below.) 

At a minimum I want to call out that if you may have code that WOULD break (with the second two being for when you must favor compatibility over security), there are 3 available solutions to the problem. You can either:

• change your code (to scope variables as needed)
• change your application.cfc or cfm to enable searchimplicitscopes=TRUE
• change ALL CF processing by adding instead a JVM argument to CF's startup

  • -Dcoldfusion.searchimplicitscopes=true

These are discussed further in the technote. And note that this new JVM arg will NOT be supported in the next and future releases, so you will NOT be able to rely on that 3rd option beyond CF2023. You will instead need to consider either of the first two options.

(I'm just a messenger here. I have nothing to do with the change or how it was implemented. I just help people solve problems, and this is going to be one for many as they deal with it, and for a long time to come as they later a) apply this update, b) move to CF2021/23 and apply this update, or c) move from earlier cf versions to later ones.)

There's also much more to the update beyond this one issue, so again READ the update technote. Update: read also the many comments here as well as a blog post I did that night of the update (taking into consideration many of the comments and questions raised here). 

[sdsinc_pmascari]

I feel some better explanation of the scope change is needed.  Are we now required to scope all variables, even those declared in the same script?  Realizing scoping is best practice, many may have some older code that lacks some variable scopes.

For instance, will the following code throw an error when searchimplicitscopes=FALSE?

<cfoutput>
<cfloop from="1" to="5" index="i">
    #i#
</cfloop>
</cfoutput>

If the above code errors, does the above code need be rewritten to be?

<cfoutput>
<cfloop from="1" to="5" index="i">
    #variables.i#
</cfloop>
</cfoutput>

[Charlie Arehart]

Paul (sdsinc_pmascari, and everyone else who will of course be quite concerned about this change), I can report that:

• that code runs fine even after the update. No need to add the variables scope there
• better still: you need not wait for applying this update to determine such things. The searchimplicitscopes was added as an app-level configurable setting in CF2016.
  • So one could create a test app in which they set  this.searchimplicitscopes=false in your application.cfc (or add searchimplicitscopes=false as an attribute to cfapplication in application.cfm), and then test such code
  • Or of course, just change it in their existing apps to test its impact on their apps
• Here is just one example of some code that DOES fail, as of the change:

  • <cfset url.test=1>
    <cfoutput>#test#</cfoutput>

  • I've never found any good single resource that clarifies what will and won't fail per the change (of that app setting, let alone this change today of its default)
• Most important: changing that searchimplicitscopes to true (in your application or per that new jvm arg) will revert the behavior, before or after today's update

[Charlie Arehart]

OK, I can add more clarity on the implicit search matter.

Sadly, neither of the two pages linked to in the release notes clarify it as well as they could (neither this one about variable scopes nor the other one about application variables). But instead this one on the cfapplication tag does better. As it notes about the searchimplicitscopes (from when it was added in CF2016):

 This attribute covers look-up in the following implicit scopes:

• CGI
• URL
• Form
• Cookie
• File
• Client

So that's why it does NOT affect CF code finding a variable in the variables scope (like shown in Paul's example above) but DOES affect finding the URL scope in the example I showed.

That may still leave questions, so I can also confirm that having searchimplicitscopes set to false (or off) does NOT affect code:

• referring to "unscoped" query column names within a query loop
• referring to "unscoped" variable names which were defined using var (or the local scope) within a CFC method or UDF
• referring to "unscoped" variable names which were themselves created without any scope in a CFC method or UDF (which end up in the variables scope)
• referring to "unscoped" variable names of arguments in a CFC method or UDF

As I/the community may gather more/refine knowledge on this, I hope to come back and update this comment. In the meantime, hope it's helpful.

Bottom line: if you have code that has unscoped variables where the variable is found (implicitly) in the above-named scopes (CGI, URL, form, cookie, file/cffile, client), you will need to attend to this matter with either of the 3 approaches in my first comment.

[sdsinc_pmascari]

Charlie,

Thanks, per usual, for your swift and thorough responses.  The CF community owes much to the work you do to keep us informed

[Charlie Arehart]

Thank you, sir. I do love doing it. Since I spend my days helping people solve CF problems (as a consultant, and then also in the forums here and elsewhere), I'm fortunate to be in a great position to see a lot (that I can share) and to also foresee a lot (that I can warn about).  🙂

Thanks for your frequent contributions here as well! 

[Maxwell Turner]

"... add searchimplicitscopes=false as an attribute to cfapplication in application.cfm"

This would let me test my site to see if I will have some variable scope issues after the update?

How would I add this to Application.cfm to test my (developer) site?   What tags surround 'searchimplicitscopes=false'

Thanks

[Charlie Arehart]

Maxwell, the point was that making that change would allow you to test the impact NOW, BEFORE doing the update. The update forces the change. This lets you force it now for the sake of testing.

As for your second question, my words you quoted have the answer, but more explicitly, expand your cfapplication to add:

<cfapplication ...whatever you may have... searchimplicitscopes="false">

(And again, those using application.cfc would just set it in the this scope.) 

But it seems somehow my words did not convey that. I'm open to feedback on how I miight have said it more clearly. 

[Maxwell Turner]

Hi Charlie,

I understood when you said I could make the change in Application.cfm to test the impact now (before I update). 

What I did not understand was how to apply the change ... I have very little experience in application.cfm (sorry), and did not know what "as an attribute to cfapplication" meant until you wrote:

<cfapplication ...whatever you may have... searchimplicitscopes="false">

Another stupid question:  What does "...whatever you may have..." mean?

I added <cfapplication searchimplicitscopes="false"> to my application.cfm ... is that all I need to do?

If what I added is correct, I'm screwed!  My entire site stopped working!  It will take months to fix this, and I'm not entirely sure how to fix it?

Am I to understand that if the variable came from a FORM, it must now be referenced as #form.variablename# or if it came from an URL, #url.variablename# ... etc?

This is terrible!  I won't be able to run this update for a loooong time while I struggle through my rather large site!

Maxwell

[DevScreen]

If you are application.cfm file, then you need to use CFSET to add:
<cfset application.searchimplicitscopes=TRUE>
Setting that to true will mean it will continue to work the way it used to before the update.

[DevScreen]

My above answer is incorrect.  If you are using application.cfm file then you have already updated it correctly.  If you are using <cfapplication> tag as your very first line, such as: <cfapplication name="myapp" clientmanagement="yes">.

You need to change it to: <cfapplication name="myapp" searchimplicitscopes="TRUE" clientmanagement="yes">. It's very much possible that your entire site stopped working because the tag is not supported until you apply the latest patch. Perhaps someone at Adobe can confirm this.

[Maxwell Turner]

Oooooh, I get it now ... if I already have a <cfapplication> tag, just add searchimplicitscopes="TRUE or FALSE" to it., otherwise, add the tag <cfapplication searchimplicitscopes="false"> to application.cfm.

Don't create a 2nd <cfapplication> tag.  (feel so much like a noob).

Pretty sure it's working (I have not applied update 7  to my CF2023).

with, <cfapplication searchimplicitscopes="false"> - sites fails instantly (and it is not obvious why, but some early testing tells me it is due to "unscoped" variables.  My entire site has "unscoped" variables!  DOH!)

with, <cfapplication searchimplicitscopes="true"> (or no tag at all) - site works like normal. 

What a nightmare!  Will be months to figure all this out!  I may never be able to update!

Maxwell

[Dave Watts]

It's one line you have to change, though, right? I haven't tried it, but it seems like you could prep for this by adding the attribute to your CFAPPLICATION tags now and not worry about it.

Dave Watts, Eidolon LLC

[Maxwell Turner]

Correct @Dave Watts , I suppose I could just set searchimplicitscopes="true" and apply the update, but this scares me because once the update is applied (and for some reason there are problems), there is no going back and I am in panic mode big time.  I cannot afford my site being down at all!

Seems safer to NOT apply the update, and set searchimplicitscopes="false" in application.cfm on my developer server and slowly go through my site and fix the errors, and once everything works fine with the setting on "false", upload the updated files to my production server, then apply the update and remove the searchimplicitscopes attribute from application.cfm.

Or am I thinking backwards on this?  I'm VERY stressed and perhaps not thinking straight.  In any case, this has created a giant mess for me.

Maxwell

[DevScreen]

@Maxwell Turner That's one way to do it, but you will end up holding your production server back from necessary (and much needed) security updates.  If you updated your Developer server, and added searchimplicitscopes="true", then what makes you nervous that same thing won't work on your production server?

[Charlie Arehart]

Right, on what devscreen just said and Dave before that. Maxwell, take a breath. This is not something to panic over. It's a priority 3 security issue per Adobe's doc, not a p1. And there's nothing you'd do that can't be undone.

I get that you're stressed. The info in this opening post, and the technotes, is pretty terse. We've tried to add more context here. But different folks come from different levels of experience.

I've written my blog post (mentioned elsewhere here) to provide more context. For folks under stress, they should stop, read it (5-10 mins) and the technote, and then decide the best course for them. There's no one right solution for everyone. (But many people freeze up when presented options they don't fully understand. That's why I provide more info, but it's not everyone's cup of tea...and only helps those who take the time to consider it.) 

Take your time to get clarity. Assess the above and my post. Then if you still have questions, ask them. 

[Maxwell Turner]

Okay, you guys convinced me to try install the update:

On Developer Server: install went fine. Added searchimplicitscopes="true" and all is good.

On Production Server:  Took a long time and finally got this message on a dialog box

"Server taking too long to restart.  You will have to manually restart server and check update status"

- I did a manual restart.

- tried to open the administrator, and it failed, but the browser window told me I needed to "INSTALL ADMINISTRATOR".  Open cfroot\bin\cfpm.bat and type "install administrator".  I did and it worked!

- The update did not install.  Gave me the option to re-download or install. 

- it also said (in red):

"There were errors in the previous install of this update.Please refer to the logs in the folder 'instalDir'\bundles\updateinstallers\ and fix the root cause before re-applying the hotfix again."

- I did, however there were no log files, just the .jar for udpate 6 (hotfix-006-330617.jar) and update 7 (hotfix-007-330663.jar).

- Went back to administrator and I re-downloaded and re-installed ... same result

- At some point I tried my website, and it errored out with the message:  Document package not found.  Open cfroot\bin\cfpm.bat and type "install document".

- This also worked

So, currently my website is up and administrator tells me Update 7 is available:  Re-download or Install

Don't know what to do

[megha1997]

@Maxwell Turner In your <ColdFusion installation directory>/<instance_folder>/hf-updates there should be a folder created in the name of update 7. This will contain hotfix installation log. Could you please check the error logged there and share?

[Maxwell Turner]

@megha1997  I actually had my IT guy take a snapshot of my server before I began.  After all of the above I was worried I had messed my server up (even though I finally  got my site and Administrator back up) , so I called him an hour ago and told him to do a restore.  Just tried, and can't get into my server anymore.  Tommorrow it will be back to where I started from, today.

I'm afraid to try again tommorrow because it seems certain I'll have the same result, but I suppose I might have to in order to get a peek at the log.  Weird that it told me to look into the <install dir>\bundles\updateinstallers\ ... never thought of looking in hf-updates.  Just checked my developer server hf-updates ... the file called upates.xml?

Max

[megha1997]

@Maxwell Turner Inside hf-updates there should be a folder that is named after update 7 version, and within that there should be a log file whose name has the date/time of the install

[Charlie Arehart]

@Maxwell Turner, if you'll read my blog post, I discuss one problem people can experience,, including what to look for and how to solve it--and why it doesn't happen to everyone. Again, the post is here.

Separately, if you just want it working (cf with the update applied), I can help via remote screenshare consulting, likely in less than a hour (perhaps much less). You won't pay for time you don't find valuable. More on my rates, approach, satisfaction guarantee, and online calendar at carehart.org/consulting. 

[megha1997]

@Maxwell Turner Sharing ColdFusion Support email id here - cfsup@adobe.com 

Kindly share the logs and setup details there, we will look into it.

[sam36089278tyot]

Changing searchimplicitscopes to true saved me so much time. Thank you!

[DevScreen]

That's a temporary solution until you can fix your code. If you set that to true, the vulnerability still exists. The goal should be to fix your code, so you don't need to set that flag.