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.

[Sireex]

Well, it's working now. I reinstalled the update, and it seems to be working now. Very strange, there were no errors when I checked the update logs.

[Charlie Arehart]

Sireex, FWIW I'll note that this update (like some, but not all others) includes updates to the underlying modules/packages. As such, we can no longer rely solely on looking at the update's log (within hf-updates) to find issues the update might have caused.

The issue is that the module/package updates are finalized in the first startup of cf that happens AFTER the update. And so we need to look at the cf logs instead, both coldfusion-out.log and coldfusion-error.log, and specifically at the log lines during that first startup after such an update. There you may see that something went amiss related to the pdf package.

Of course, the good news for you is that a reinstall (or perhaps just a cf restart) seems to have solved the problem for you. You might see something tracked about that in the log lines after that next restart.

But maybe you won't. Again, I add this info as a POSSIBLE help, and one which may help still other readers. We have a lot of balls to juggle in managing a cf server, and sometimes they slip in oddly-sized ones--or even a milk jug instead. But juggle them we need to, as the show must go on.  🙂 

[Adam36099131ak4s]

Currently, as of 10:13 GMT the URL 'cfmodules.adobe.com/bundlesdependency.json' is missing the update 13 packages. The update of my live system to 13 this morning via CFAdmin applied the core update but none of the packages, it removed the existing packages which have been flagged for update by Adobe. After re-installing the Administrator package via CFPM I noticed it installed version 11 and not 13, this is when I checked the packagesurl and noticed its missing any reference to update 13. This worked fine in my Dev environment on Wednesday (13th). For whatever reason it looks like the online version of bundlesdependency.json is incorrect.

I also noticed when viewing the Update 13 URL from any other region than US (uk for example), the links to the hotfix installer and zip repository go to hotfix version 12.

[hannah18]

Hi @Adam36099131ak4s, 

I am able to see the update 13 packages in https://cfmodules.adobe.com/bundlesdependency.json

Few things you could check:

1. Was the core update applied successfully? You can check the hotfix logs in <cfhome>/cfusion/hf-updates/hf-2021-00013-330286 for the same. 

2. Clearing the browser cache. 

3. Delete the felix-cache folder in <cfhome>/bin and restarting server. 

Also, when you said you viewed Update 13 URL from UK region which shows hotfix version 12, which url were you specifying? Is it the updates url or packages url? 

Thanks,

Rochelle

[Adam36099131ak4s]

Hi, earlier I did clear my cache a number of times and tried the URL from other non-CF devices, each time the 13 package updates did not show. Although more recently I have tried again and I was able to see them occasionally, but more often they are still missing when browsing to the URL (and clearing my cache between attempts). Is the URL load balanced by any chance? If so perhaps the json file has been updated on some but not all servers? Can you try clearing your cache and trying again?

This sounds very silimar to the issue Maxwell was having on the 14th. His applications look to have been removed also.

Thanks.

[Adam36099131ak4s]

Snip from a browser with cache cleared.

[hannah18]

We are getting it checked.

Meanwhile, sharing ColdFusion Support email id here - cfsup@adobe.com if needed

[Adam36099131ak4s]

Ive reattempted my live upgrade this morning with the same issue as yesterday. Applying it via the CFAdmin console results in Core being updated fine BUT the packages flagged by Adobe for update being uninstalled, I'll attach a snip of before and after from CFPM.

I firmly believe this is because of an issue with the bundlesdependency.json file. The installer log shows the version 13 packages being downloaded which I can see in the bundles folder - the .zip and .jar for each one are there. However, the bundles\bundlesdependency.json file has no reference to the version 13 packages in it, even though its date modified timestamp shows its been updated.

Ive tried clearing cache's before running the update, Ive tried deleting the felix-cache folder all with the same result. Plus, Im still having issues browsing to https://cfmodules.adobe.com/bundlesdependency.json and seeing the references to update 13 packages. This is on multiple devices after clearing caches etc. Im in the UK if that makes any difference. The does seem to be a rabbit off with the version of bundlesdependency.json you are offering at the moment.

Lastly, I restored our dev environment to before the update on the 13th (which ran without issue). When I apply the the update to it today it has exactly the same package problems as our Live above.

Ive updated my cfsup case with this mornings finding.

Thanks.

[Andrew36147034g3jm]

Having exactly the same issue here. If I navigate to https://cfmodules.adobe.com/bundlesdependency.json directly in my browser, I see lots of mentions of "2021.0.13". However, if I do a wget from my server for that same file and look at the contents, there are no mentions of "2021.0.13".

This meant that when doing the update via coldfusion administrator, the main update worked but packages were removed/uninstalled and the CF admin stopped working.

[Adam36099131ak4s]

Looks like they've made some backend changes to resolve the issue. Ive manually updated my system to 13 so unable to verify, but hopefully its resolved for anyone else having the same problem. From ColdFusion support-

"Thanks for letting us know. Could you please confirm one thing if possible. Please enter this package URL (https://www.adobe.com/go/coldfusion-packages) in your browser and confirm if you see the update 13 modules there. We did make some changes from the blackened so there is no caching issue and hopefully it should appear now. "

[Andrew36147034g3jm]

Can confirm that attempting the update again via the CF Administrator worked for us today (20th) with no issues.

[megha1997]

Good to know! Thanks for the update

[Ian2511417122lu]

We have installed ColdFusion 2021 Update 13 from command line (as server cannot access the internet).

The ColdFusion services are running using a service account (XXX). The commands are run from PowerShell running as the service account. We have used this method for the last few updates.

After the installation is completed we see the following warning in the hotfix log:

Move Folder:              Destination: C:\Users\XXX\109052.tmp\dist\cfusion
                          Status: WARNING
                          Additional Notes: WARNING - There was a problem copying C:\Users\XXX\109052.tmp\dist\cfusion

We have done a quick check of the application and CF Admin and it seems to be working but are concerned there may still be an issue. Before running installer, we stop ColdFusion services and IIS website.

What could be causing this warning?

[hannah18]

Hi,

If FatalErrors or NonFatalErrors in the hotfix log is 0, the installation is successful. Nothing to worry there. 

We will still look into the warning and find the root cause for the same. We will work on fixing that in the upcoming updates. 

-Rochelle

[Charlie Arehart]

Saurav (or others at Adobe), please change the update technote, which has very unfortunate erroneous wording in its introduction of the change regarding implicit scope searching. It says:

Starting with this update, ColdFusion will default to searchimplicitscopes=FALSE and if a variable name is not prefixed with a scope identifier, an error is returned.

That last phrase is NOT true. It's not that ANY unscoped variable will fail.

Instead, it's that an unscoped variable will fail if can ONLY be resolved by one of the scopes now blocked by the change (such as form, url, cookie, and such, which can be modified from outside the request). But if such an unscoped variable CAN be resolved by a scope that's local to the request (like variables, local, arguments, the query scope, and such), then it will NOT error (and does NOT "need" to be scoped, though it can be useful if it is.)

The wording above (on both technotes for CF2023 and 2021) should be changed to NOT say that "if a variable name is not prefixed with a scope identifier, an error is returned". That's not accurate.

[Saurav_Ghosh]

Thank you, Charlie. I've made the changes.

[Charlie Arehart]

Saurav, thanks of course for the quick response.  But I'm afraid the word choice is still incorrect. It now says:

Starting with this update, ColdFusion will default to searchimplicitscopes=FALSE and if a variable name is not prefixed with a scope identifier, it can only be resolved by one of the impacted scopes (see below), which can be modified from outside the request. 

It's definitely NOT that with the change, the default is that an unscoped variable "can only be resolved by one of the impacted scopes (see below).". It's that they CANNOT., which is what must be conveyed. 

And yes, the REASON the change was made is that scopes in that list (including form, url, etc)  "can be modified from outside the request".

I realize you want to be succinct. The challenge seems to be in saying things in as few words as possible, yet still accurately.

I'll add that it doesn't help that the searchimplicitscopes attribute (created 8 years ago) was named as it was. The more accurate name might have been searchremotescopes, which might better have conveyed its intent. Even if false, SOME scopes ARE searched "implicitly" (only ones local to a request, like variables, arguments, query, etc). But I realize that name won't be changed.  It just adds to the challenge in explaining this new changing of its default.