Announcing ColdFusion updates released May 13 2025: p1 security update (and more)
An update for ColdFusion has been released today, May 13, 2025, for both cf2025 (update 2), cf2023 (update 14) and cf2021 (update 20). In brief, it addresses a P1 (Priority 1, "Critical") security vulnerability, as indicated in the associated ASPB (security bulletin) for the update.
The update also incorporates potentially breaking changes (with Adobe trading compatibility for security), while it also includes configurable options to undo those changes (if you prefer to trade away security for compatibility). Finally, the update corrects some issues introduced in the previous updates, released in April.
In this post, I share the details about the update (from Adobe and from others). I can report I have installed both updates on multiple machines and operating systems without incident. As for challenges or lessons learned, I may do a follow-up post as I/we all learn more.
For more details, read on.
If you have a remote function that you call with cfajaxproxy and you have a cfparam tag with a URL variable in Application.cfm it will try and pass the variable as an argument to the function and error out.
Application.cfm
**************************
<cfparam name="URL.WindowType" default="Screen">
test.cfm
**************************
<cfajaxproxy cfc="proxy" jsclassname="testproxy">
<!--- the following should be a "script" tag, but the blog's XSS protection converts it to "invalidtag"--->
<InvalidTag>
var ColdFusionProxy = new testproxy();
var TestDate = ColdFusionProxy.getDate();
document.write(TestDate);
</script>
proxy.cfc
**************************
<cfcomponent displayname="proxy" output="false">
<cffunction name="getDate" access="remote" returntype="date" output="false"
hint="Returns the current date and time">
<cfreturn Now()>
</cffunction>
</cfcomponent>
The error I get is:
"Function getDate does not support WINDOWTYPE as an argument in in C:\inetpub\wwwroot\proxy.cfc"
Removing the cfparam tag works around the issue.
1) So first, this is being caused by the change above (first bullet under "what's changed") regarding how remote methods now cannot (by default) be called with *arguments which are not defined in the method*. I realize you could reasonably assert: that url var is "not an argument you're passing in". What's happening is that this is somehow how cfajaxproxy works under the covers.
In fact, it's not simply about that URL var being defined in the application.cfm. It would happen as well if ANY url vars were defined in the request. It turns out that the call made to CF (via cfajaxproxy) does pass in ANY such url vars (defined in the request) as args. That's not "new" with this update.
And you can prove this is what's happening, by changing your method to have it return the keys in the arguments scope (and remove the returntype="date"):
<cffunction name="getDate" access="remote">
<cfargument name="WINDOWTYPE">
<cfreturn structkeylist(arguments)>
</cffunction>
Now when you call your test page, the output would (before this update, or with workarounds I'll show) now show whatever is passed into that method: and your URL var will be there (and you'll see a couple others that Adobe prefixes with _, which it seems to allow/handle specially.)
2) So as for workarounds, there are a couple of others beside yours:
a) You could simply define that url var as an expected arg to the function, adding this:
<cfargument name="windowtype">
That seems most reasonable, since you ARE in fact wanting to define/use that windowtype var in your app.cfm. Again, I get that you did not EXPECT that CF would do that, but now we know it does. (I suspect they would not, as a "fix", just "allow ANY URL vars" to be passed in instead, as that would defeat the purpose of the protection this update is adding (for more generic reasons, well beyond just calls from cfajaxproxy).
b) The other workaround is to do what the blog post above (and the update technote) indicates: you can have CF revert this change in behavior entirely using the JVM arg:
-Dcoldfusion.runtime.remotemethod.matchArguments=false
which would remove the new protection for ALL remote method calls. If you put that in your CF jvm args and restart CF and test your app, you'll see it works as-is, no change required.
Let me know what you think. And thanks for sharing the observation. I'm sure others could indeed be caught out by it.
But I should also add that you could always email [email protected], which is free support for install issue, and we could assert that update problems are essentially install issues. Some also use [email protected].
I will add both those to the blog post, and I will also add a mention of this cfajaxproxy matter in that first bullet point under "what's changed".
As the saying goes, "I do it for the kids". :-)
I started installing on our test servers this morning and once they came back up I immediately had issues with logging into the ColdFusion admin. I was getting a 500 browser alert popup every time I submitted the password. I was able to overcome that by adding the JVM arg -Dcoldfusion.runtime.remotemethod.matchArguments=false. I would not expect that to be the case but hey it worked.
The next error I came across was: "The sqlserver package is not installed. You can install the package through the CLI package manager (C:/ColdFusion2023/cfusion/bin/cfpm.bat) by running the command : install sqlserver." I have always performed updates manually as we don't always have firewall access outside for updates. I have a C:\packagerepo and I run the updates with java via the command line. I never use the CLI and have never needed the package manager. But since I am trying to get test backup ASAP I decided to give it a try even though in the CF Admin I can see that the sqlserver package is listed as installed. I ran cfpm and did an install sqlserver just to get the following:
cfpm>install sqlserver
The packages repository C:\packagerepo is not accessible. You can only load the packages that are available locally in the C:\ColdFusion2023\bundles directory.
The following packages will be installed : sqlserver:2023.0.0.330468
sqlserver(2023.0.0.330468) package is already installed.
I have packarepo with the latest files and even redundantly copied all files to a bundles folder inside the repo.
No headway has been made just yet and supports latest message was to get my timezone in order to try and connect tomorrow (which is a little less than helpful today). So I sort of came here to vent slash see if any other ideas could be had. Oh also I did try an uninstall of HF 14 which didn't resolve any of the issues I was seeing. Same errors existed. See what happens when I don't just get a snapshot...
But they too found that sql server calls failed, and they too used cfpm only to be told it was already installed. And a key was that they too were using the manual offline install, with the downloading of the zip (which you don't mention doing, but you refer to the C:\packagerepo folder).
So first, did you download the zip from the update 14 technote? And did you extract it to that folder? Did you make sure it was empty first?
Then note that your error says that folder is inaccessible, and so it's looking in the C:\ColdFusion2023\bundles folder instead (the default). BTW, since it WAS looking in the C:\packagerepo to start, that suggests you had changed the packagesurl value in your CF Admin package manager page's "settings" tab. Can you confirm?
So next, when you went to the command line to run the cfpm tool, did you think to run the command line "as admin" (since we can see you're on Windows)? Maybe that's why THAT failed to work as expected. But again did you extract the zip to that folder? You don't say. And was it emptied first? I've suspected that could be a problem if not.
Anyway, their conclusion (yet to be confirmed) is that there was something wrong in the zip. That HAS happened, of course. And sometimes Adobe then offers a new zip (often it's not clear if/when they do). Since you're working with them, if that's the issue they will tell you and I hop you'll tell us.
In the meantime, let us know if the other thoughts above may help.
BTW, the person who emailed my last night said they just punted and recovered using a step which may be too late for you. They didn't do a snapshot (I gather you're on a VM). Instead, they had first made a copy of the CF "bundles" directory (having been burned before), and after getting the same problems above, they copied all the files from the that into the CF bundles dir (and when Windows prompted them, they told it to skip replacing existing files).
That worked for them. It may work for others.
But again hope you may get confirmation of any known issue from Adobe. And in the meantime, thanks for sharing this here and hope it may help someone.
Apologies there are a lot of little (very important) steps to a manual HF update so I tend to leave some out. I am often very hit and miss with details unless I am documenting a new process, so for troubleshooting I do understand how details can make all the difference. I am also more of a talker than a writer. Great questions though: I can see how this is what you do.
I download both the HF file and the package zip for all updates from the tech note for that patch. I have permanently changed my CF admin package location to C:\packagerepo. Once I have the new Adobe patch files on my server I delete all files from my current C:\packagerepo leaving myself with an empty folder. I then expand the package zip and copy the files from there into my C:\packagerepo. I copy the HF jar into the cfusion\hf-updates folder so I can easily reference it with the command line java -jar command for initializing the hotfix. Normally this is a super straight forward (once you have done it on 5 servers dozens of times) process that rarely has any issues especially this many issues.
I am a compulsive launch cmd as administrator admin so that was indeed the case here. That is also how I run the java command for updating.
I copied the bundles files from another unpatched server tier and selected skip replacing and the server comes up without the SQL error but now our normal kerberos login mechanism seems broken. I will hang in there with support and hope to get a better more clear cut duplicatable solution as I still need to patch 3 more systems after fixing my 2 test systems. When I get such a solution I will most definitely share it here.
Thanks again for the great feedback I am always thankful for your presence in this space as there are not as many CF resources, as our “new stack” folks like to tout.
So if you or anyone else in this boat doesn't want to wait, you could also install CF on your own machine (that does have internet access), and get the needed files from there.
That's free: and if you don't have the CF installer still, you can get it from cfmlrepo.com (a site managed by trusted members of the community, including myself). And as you may know, you can install CF either as the free 30-day trial or just the free Developer edition (one installer covers those or a licensed installation).
Once you install it, you could then update it (using the CF admin, and via the web). Then finally you could compare or just copy the files to your server. I plan to try to do the same thing, and I'll report here if I get it done before anyone else reports (or you may learn something from Adobe.)
I have yet to hear back from adobe support after sending logs and other details to them yesterday afternoon.
I ended up going through some other steps on my own that seem to have possibly been beneficial. My solution makes me wonder if something changed in the install script from how previous hotfixes have worked.
After going down the path of copying files from another server to mimic having a backup of the bundles directory. I tried to update my local system from the CF Admin (something I have never had any luck with). I noticed my local having the default settings in place for the Packages site and when I visit that URL (https://www.adobe.co...) in a browser it renders the bundlesdependency.json file, so that made me curious. So I decided to look at how I had configured my server for manual updates. I have always (for all of the CF 2023 hotfixes since it was released) have had my Packages Site set to C:\packagerepo (which is where I unzip the downloaded packages file to on my systems) and all of the previous updates have run fine without any/many issues. After noticing that the default path takes you to the json file I decided to change my Packages Site to explicitly point to the json file C:\packagerepo\bundlesdependency.json , which to be fair more closely resembles how it is described in the offline mode install steps on the Adobe site. After this update on the servers I had already "patched" unsuccessfully the packages page showed that they could be updated, using the Update All button, which I have never seen before.
After getting a snapshot I decided to make all of the settings updates to my second QA server and run the hotfix there as I normally would. This time on that server the update worked as expected.
TLDR; Making sure my Packages Site was set explicitly to the bundlesdependency.json object in the location that I unzip the Adobe packages.zip file to: C:\packagerepo\bundlesdependency.json seems to have helped the hotfix run as expected.
First, assuming you do NOT use THAT as the means for some client to call into some CFC that exposes REMOTE methods, we can say for sure that YES those would be affected by this change (you would need to be sure to define the incoming args in the method signature or via cfargument). Or you could add the JVM arg to "trade security for compatibility".
-Dcoldfusion.runtime.remotemethod.matchArguments=false
If you DO use the CF REST API, I suppose it MAY be POSSIBLE that some aspect of the calls into the CFCs would get handled differently by CF...but I have not confirmed it--and I really don't think it would. Again, if it IS handled the same then you have the same solutions above.
If you or anyone else can confirm either way, let us know.
Because yes, as you found that "packagesurl" is supposed to point to a bundlesdependency.json file and NOT just a folder. That sort of mistake could certainly underlie a lot of problems that folks have.
I guess you're wondering if something about that "mistake" is somehow MORE detrimental with this update. I would not think so. And actually what you found was it changed how the UI worked. It would have been interesting if you had gone back and done everything as you had done before. Maybe somehow that still would have failed.
So if it would have, then yes you have this UI approach to updating packages. BTW, this should also make your cfpm approach work (which you don't indicate trying). That, too, uses that packagesurl. And finally the full jar installer ALSO uses that url and I suspect if you'd done that it should now have worked better.
It would be odd that it "worked before" with the url pointing to a folder and not the json file. Time will tell, either as you try the next update or if others reading this are in the same situation.
And this does suggest that Adobe ought to add verification to that UI to check if you are naming just a folder. One of the challenges is that (as the default value shows) it CAN be just a URL that ends with no file name...which REDIRECTS to a json file. So Adobe would REALLY need to "check" if that value entered did RESOLVE to a json file (if it was a URL), and then they could also confirm it ENDS with a json file if it's a file path.
Finally, some have asserted that "because it's a url, that should be a file:// protocol you use there in that field", but that's not true (as you found). It has always accepted EITHER a URL OR a local path. The bummer is that it doesn't detect if it's a PATH but NOT the json file. Grr. Until Adobe may address that, we can consider it a "lesson learned".
We're installing the update to a test server next week. I can report back afterwards.