Announcing ColdFusion updates released May 13 2025: p1 security update (and more)
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.
Following are the topics discussed in this post:
- Finding (and finding more about) the update
- What are the security issues addressed in the update?
- What's changed in the update?
- Improvements labeled as "bugs fixed"
- "Known issues" that remain after the update, with workarounds
- A few other topics generic to recent CF updates, which you may want to consider
- On getting help with the update(s)
Updates to original post: Note that since I posted this originally the night of the update, we (the community and I) have learned more about the update and some of its ramifications, which go beyond what was documented in the update technotes discussed below. Here are some of the changes:
- As for the discussion of the change regarding remote method invocation, note that I've added new info about how it's become obvious that it is impacting MORE than just what information you EXPLICITLY pass into such a remote method: there are several kinds of IMPLICIT variables that it turns out are (and always have been) passed into them. (You would only knew if you dumped the "arguments" scope in such a remote method and made a call to it remotely.) These implicit variables include any URL or FORM scope variables, defined in the request (or application.cfc/cfm), which has been quite a surprise to discover (it's not mentioned in the update technotes). Similarly, if you use cfajaxproxy to call such a remote method, it turns out there is a special windowtype hidden url variable that's passed in by that. All these must be defined as arguments to the remote method after this update--unless you opt to put the jvm arg in place. For more, see below within "What's changed in the update" (but read the text before that, if you are seeing this post for the first time). I also share in that discussion of these an ideas I have for how Adobe may better help us deal with this problem.
- As for discussion of the probes feature (and how you must whitelist files or paths you would set such probes to publish to), we have learned since the original post that this affects in fact even regular scheduled tasks (if they are configured to publish their output). Worse, they not only fail but may also break ALL your scheduled tasks. Again, for more, see the discussion in the "what's changed" section.
Now, back to what I'd written originally...
First, I do want to apologize to my regular readers for my not getting any post out about the April update. When it came out, I quickly saw people experiencing trouble--and I was torn about posting an announcement right away. Also, in my posts I don't just share the news but I first attempt the updates--on multiple machines and OS's, as well as exploring the changes (often finding more than what is documented, as I'll share below).
In the case of the previous update, as I waited for more info to come out about the troubles people were having (whether from Adobe or the community), well, time passed...and soon I felt like doing a post long after the update might not be so helpful after all. Then up popped this update today, which attends to some of the very problems introduced with that April update. So I stuck it out to get this one out today (ok, at 3am on the 14th--but it's still May 13 somewhere!)
Finding (and finding more about) the update
While you should have seen the update appear in your CF Admin when you login (and if you don't, give it time as there may be a caching issue), as always Adobe has announced the update via their CF Community Forums, specifically:And that points to the (very important) technote for each version's update:
- ColdFusion (2025 release) Update 2
- ColdFusion (2023 release) Update 14
- ColdFusion (2021 release) Update 20
Finally note also that Adobe has posted a blog entry in the CF portal about the update (with essentially the same info): NOW LIVE! ColdFusion 2025, 2023, and 2021 May security updates. (There tends to be more discussion in the forum announcement than the blog post, though not always.)
What are the security issues addressed in the update?
If you read the APSB for this update, it indicates first again that it's a Priority 1 "Critical" update, and it identifies several different issues/vulnerabilities that are addressed with CVSS scores ranging from 6.8 to 9.1 out of 10--affecting equally all 3 CF versions that are being updated.
You can read the bulletin for the boilerplate identification of the issues, and their Mitre CWE definitions, as well as the acknowledgements of those who identified and reported the vulns. Sadly, as is nearly always the case, there is very little detail beyond that about the vulns, and certainly no information to help you "detect if you're vulnerable". The expectation is that "you are", and that therefore "you should apply the update" in order to get the protection it offers.
What's perhaps more unfortunate is that a) there are several different issues and b) there are changes put into effect related to some of them--as well as bugs fixed, etc., but you don't get to pick and choose "parts of these updates": you apply the update and get ALL the "fixes", including whatever changes are coming along for the ride, as discussed in the next section.
(BTW, as for the APSB's final section, "ColdFusion JDK Requirement" offering jvm args to be applied, please see my discussion below for how that does NOT apply to most folks: only to those wo deploy CF via WAR or WAR files on JEE app servers.)
What's changed in the update?
If you read the resources I point to above (the forum thread, the blog post, and especially the technote for the update to each CF version), they discuss what's changed, at least in brief. The update technotes, in particular, offer more detail than the others. I'd like to present here the key points (as addressed differently across those various resources), with perhaps a little more context and indeed in a different order than Adobe lists them:
- Note that if you have any CFCs which have remote methods (cf function definitions that indicate access="remote"), such "remote" CFC methods will no longer will accept calls made remotely (from outside of CF) which name either too many or incorrectly named arguments. Doing so will generate an error, like ,"Function [arg] does not support [incorrect argname] as an argument in [path to cfc]". If you want to allow such behavior, use this new JVM flag: -Dcoldfusion.runtime.remotemethod.matchArguments=falseOf course, that's undoing a security fix: trading security for compatibility.
I'll add as well that someone reported in a comment here how this had an unexpected impact on calls to a CFC made by way of cfajaxproxy, which pass in a hidden windowtype URL variable. See the comments section below for his observation and my response/suggestions
Beyond that, I'll add that a similar (but different) problem is being reported as another unexpected impact of this change: when checking "what's passed into such a remote method", after this update CF is now also detecting the existence of ANY URL or FORM SCOPE VARIABLES (defined in the application) as implicitly being available/passed into to such a method--such that the method call will fail also unless any/all such URL or FORM scope vars are defined ALSO as arguments to that remote method. This includes definition of such vars in the request or in the application.cfc/cfm and so on. The JVM arg above is again a workaround, if defining the URL or FORM vars as method arguments is burdensome. FWIW, the issue has been raised to Adobe for consideration as bug CF-4226618 (with respect to the URL vars). I learned of the impact on FORM vars since I commented there, and now I have updated this post here. - There's been a change regarding the recently added "serialfilter.txt" file, in that if you already have such a serialfilter.txt file defined before the update, it is replaced DURING the update. As the technote indicates, "if you already have custom entries added to the file, copy the custom entries from the backup file (cfusion/hf-updates/{version}/backup/lib)", which is referring to the backup folder created for the update you just applied
- Though this is not mentioned clearly in the update technote, note that if you use the CF admin feature to create a ColdFusion Archive (car) file, note that as of this update when you try to "build" such a car file, the admin no longer lets you choose WHERE to put the car file. Instead, it presumes only to write it to the CF instance's "packages" folder, as in C:\ColdFusion2025\cfusion\packages. Unlike prior to this update, the UI for naming the CAR file during the build step no longer shows the "browse" button to let you identify a folder location. (Curiously, we do still have to enter the .car extension as well, which seems a missed opportunity to ease that hassle.) FWIW, this change is only indicated in the list of "known issues" in the update technote, where it notes merely that if you DO try to build an archive and don't HAVE a "packages" folder within your CF instance, then it would fail--you must create that folder manually
- The update technote indicates that we should obtain the latest MySQL connector update. See the technote and a link it offers to another CF doc page on the process. Note that as of the initial release of the update technotes, it says, "For security reasons, we highly recommend using the latest MySQL Java connector (version 8.0.15 or later)." That wording seems confusing to me. To be clear, 8.0.15 is from 2019, while the "latest" (at this writing) is 9.3.0 (which is indeed indicated in that CF doc page that it links to). I've raised this concern about the technote verbiage to Adobe and for now their response is that what they mean is you should be at LEAST on that 8.0.15. I've asked if that might be tweaked to be more clear
- Note that the table at the bottom of each technote indicates that there were 9 CF "packages" that were updated as of this update.
- The update indicates that there are "refreshed" installers for the CF Add-on service, for those who may use those. Note they are needed only for those who choose to install the CF Add-on service separately from the CF install itself. To be clear, the CF installer defaults to offering to install the CF add-on service, which it implements within the CF folders: folks who implement CF and the add-on service this way don't need that separate/refreshed installer
- If you use the (deprecated) CF Admin "system probes" feature, note that there are important changes regarding a) whether they can be configured to run a program if the probe fails and b) WHERE you are allowed to configure them to publish their output to a file.
- For more on each, see the update technote discussion of the -Dcoldfusion.systemprobe.allowexecution jvm arg and the "Pathfilter changes" section, respectively. Again, this is undoing a security fix: trading security for compatibility
- For the sake of posterity and to help folks searching the web, if your task or probe writes to a disallowed location, the error shown (and logged) will indicate that, "To allow it, whitelist the path in cf-root/lib/pathfilter.json against key schedulerexecutionpaths."
- Note finally that if you do modify that whitelist, you must escape a Windows path if specified in that file, otherwise you will find an error in the CF startup logs indicating, "Error reading path filter JSON file: Unrecognized character escape", so for instance use c:/somefolder/somefile.txt instead of c:\somefolder\somefile.txt.
- Expanding on that last issue about probes publishing output, I have discovered since originally writing this post that this change impacts ALSO if you have configured scheduled tasks to publish their output.
- Again, as I noted above, you will need to whitelist the file or path to which you want to save such output--or use the jvm argument to disable the protection. For completeness, I will quote here from the update technote a text box about this issue with regard to its impact on scheduled tasks. Somehow I missed it originally (or perhaps it was added since I wrote that day):
Note: If scheduled tasks have the Publish > Save output to a file option enabled in ColdFusion Administrator with a specified file path, the task will no longer function unless that path is explicitly allowed in the schedulerexecutionpaths section of pathfilter.json file located in
/lib. After you've made the changes, restart ColdFusion. - Note as well that some commenters below reported that they found this problem did MORE than cause an error on running such a task: instead they found that it broke ALL scheduled tasks, because somehow when Adobe wrote something related to the problem in the neo-cron.xml file, it corrupted that. Chris G reported below that he was able to recover by restoring the neo-cron.bak backup file (deleting the bad one and renaming this backup to take its place). Just beware that may not work for everyone, as they may find that the bak file itself could also be corrupted. Ugh!
- Again, as I noted above, you will need to whitelist the file or path to which you want to save such output--or use the jvm argument to disable the protection. For completeness, I will quote here from the update technote a text box about this issue with regard to its impact on scheduled tasks. Somehow I missed it originally (or perhaps it was added since I wrote that day):
- On these last two points about validation of args passed into remote methods (whether passed in explicitly or implicitly), I fear that these may be challenging things for folks or even tools to find via static code analysis--since the presence of such implicitly passed URL or FORM vars may be generated at runtime only. My hope is that perhaps Adobe may add a hotfix (like they did last April for the March 2024 CF update about implicit scope searching), where the hotfix could at least aid people who DO add the argument (to disable the protection) to get a log of when their app DOES cause execution of a remote method, where the log entry could list any such incoming args that were not properly defined. That would be better than ONLY disabling the matching or enabling it and "hoping" to catch all errors.
For more on those two new JVM args discussed in the points above, see the available new documentation of all JVM flags (as added in each update), available for CF2025 and for CF2023/CF2021.
And see also the sections to follow on improvements implemented as bug fixes and on known issues that remain even after the update (which will result in "changes" per this update).
Of course, when we say that "these are the things changed per this update", it's important to note that this is referring specifically to THIS update--and it's presuming you are coming from the immediately preceding update (from April). But if you are skipping that one or any before it, note that you MUST take into consideration whatever is indicated as having changed in that/those prior updates you're skipping. Note that the technote and Adobe pages about the update offer a link to a page listing ALL updates for each CF version, to facilitate that effort.
Again, my apologies to any who may have looked or do now look for a blog post from me on that April update. Sadly, I did not do one, as I explained above.
Improvements labeled as "bugs fixed"
The following bullet points are offered in the update technotes as bugs that have been fixed, for all 3 engine versions:
- Executing the command docker run --rm -it -v ./mywebroot:/app -e acceptEULA=YES adobecoldfusion/coldfusion:latest cli t.cfm on a Docker image causes a Null pointer exception.
- When ColdFusion is installed and multiple instances are created, applying the hotfix by selecting all instances at once completes successfully. However, the hotfix does not deploy certain required files, specifically, the jetty-ipaccess.xml file, into the cfusion/jetty/etc directory as expected. This file was introduced in updates 19 (CF 2021), 13 (CF 2023), and 1 (CF 2025), but was missing in this case.
- An error occurs when registering or unregistering the PDF Service Manager after installing the previous updates. After applying the update and restarting both the ColdFusion and Add-on services, editing the PDFg service in the Administrator causes the PDF engine 1 to behave unexpectedly.
- After installing the previous update, the FTP and cfzip packages did not work, even though they were listed in cfpm.
Additional bugs fixed in CF2025:
- After applying the previous update and installing the add-ons, you are unable to publish a document to pdf.
- In ColdFusion AWS AMI deployments, error messages related to isAutoRestartInstances and undefined STATUS elements are observed in the NGLLICENSEINFO context. When accessing the Activation page, ColdFusion throws an error indicating that the isAutoRestartInstances method could not be found or resolved.
- After installing the previous update, the FTP and cfzip packages did not work, even though they were listed in cfpm.
Additional bugs fixed in CF2023:
- When adding or deleting a node after CCS is stopped, ColdFusion throws an exception.
- After installing the previous update, the FTP and cfzip packages did not work, even though they were listed in cfpm.
Additional bugs fixed in CF2021:
- When Update 14 is applied to a cluster configuration, the ext folder located at ColdFusion2021\cfusion\jetty\lib is removed and moved to the backup directory. As a result, search collections become inaccessible, and an error message appears.
- As part of the PDF-related fixes, specific files under
/webapps/WEB-INF/classes were supposed to be updated by the hotfix. However, these files were not replaced as expected, which leads to the PDF service being removed when edited via ColdFusion Administrator.
"Known issues" that remain after the update, with workarounds
Then similarly, the update technotes for each version list the following as known issues that remain even after the update (the first one relates to the point I'd made above about the change regarding creating a CAR archive):
- The CAR build fails if the packages folder is not present. As a workaround, create a folder called packages in
/cfusion/, if the folder is not already created. - On non-Windows systems, editing the local PDF service via Administrator > PDF Service results in the service being removed. The IP address 127.0.0.1 is not included in the allowed list within the jetty/etc/jetty-ipaccess.xml file. As a result, the system blocks the local PDF service connection, leading to its deletion when edited. As a workaround, manually whitelist 127.0.0.1 in the jetty-ipaccess.xml file. This will allow the PDF service to function correctly when edited from the ColdFusion Administrator.
Then for CF2021, uniquely, its update technote mentions one other known issue:
- Uninstalling ColdFusion 2021 Update 19 may remove the xalan.jar file from C:\ColdFusion2021\cfusion\lib, even though it was not added during the installation of Update 19. As a workaround, manually copy the xalan.jar file from a server running Update 18 to the affected server's C:\ColdFusion2021\cfusion\lib directory.
Finally, I will note that while it's not mentioned in any of these 3 update technotes, there has been in the technotes for previous recent CF updates an indication that one should stop CF after the update and delete the cfusion/bin/felix-cache folder, then restart CF (and repeat that for any instances other than cfusion that you may have). Certainly if you are moving to this latest update from other than the immediately preceding update, it would seem wise to perform this step (there's no reason NOT to).
A few other topics generic to recent CF updates, which you may want to consider
Before wrapping up, and separate from the details in the previous section, there are a few other matters that may interest you, which I have covered in my previous blog posts on the updates. What I said in them applies to this one as well--especially if you may have jumped to this update from ones previous to the last one, so I'll just point you to these last few topics in my post about the previous update in October:
- What to consider, with regard to the 4 previous CF updates (possible breaking changes)
- As with all CF updates, possible need to upgrade web server connector
- Something to consider, if you're coming from CF2021 update 10 or CF2023 update 4, or earlier
- You can probably ignore the discussion of the -Djdk.serialFilter "ColdFusion JDK Flag
My discussion of those points starts at this point in that post from Oct.
I may soon break these points out into their own post (so that I can more easily point out the issues in my posts about other CF updates just before and just after this one). If I do, I will update this section to point to that.
On getting help with the update(s)
Finally, if you may want help with considering, installing, or troubleshooting anything related to these updates (or indeed anything related to CF), I'm available for online remote consulting. I can often help solve such update problems VERY quickly, getting you back on your feet. More at carehart.org/consulting.
Or you can certainly reach out to the CF community, starting first perhaps with the Adobe forum thread announcing the update, which I pointed to above. Adobe folks might well respond to issues you raise there. Or you could reach out to their support email addresses: [email protected] or [email protected]. Finally, to reach out to the wider CF community, note that I offer links to several of the online CF communities here.
For more content like this from Charlie Arehart:Need more help with problems?
- 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
- 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
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.
"Cannot find implementation class coldfusion.tagext.mail.MailTag for the mail tag"
We contacted our hosting company and they said they reinstalled all packages and we're now up and running again.
Next, I tried running our internal API test page. We use the CF REST Framework for our APIs, but call the individual functions locally during testing and development. The API REST was returning 404 errors and when calling locally via a CFOBJECT call, we were getting this weird error:
org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [CfmServlet] in context with path [] threw exception [Servlet execution threw an exception] with root cause
java.lang.ExceptionInInitializerError: Exception coldfusion.server.ServiceFactory$ModuleNotAvailableException [in thread "main"]
Grasping at straws, we removed the REST attrbutes from the CFCOMPONENT tag and tried again, like so:
<cfcomponent rest="yes" restpath="/ourrestpath">
changed to:
<cfcomponent>
This time, the CFOBJECT call worked!
So, we replaced the REST attributes:
<cfcomponent rest="yes" restpath="/ourrestpath">
And tried the CFOBJECT call again...
Success this time!
Not sure what is going on with that, but will be keeping an eye when we get to updating production machines.
. Have your host look at the coldfusion-out.log, at the lines during that first startup after the update, looking for errors related to the packages.
I gave a talk on the topic last month, with more details, available as a pdf or link to the YouTube recording, available at carehart.org/presentations.
We did have a couple of arbitrary, overloaded, functions (unrelated to our API) that were throwing errors do to the 'matchArguments' update, so I know the update was successful and we easily mediated those issues.
Thank you for your thorough analysis, Charlie.
But my suggestion that they look at the startup log (immediately after the update) is both a) to see if those package failures ARE tracked there, then b) to see if any OTHERS failed (which you/others have not yet noticed), and c) to encourage them to undertake that check after EVERY update. That is indeed the admonition/case I make in my preso. It's easy for people to presume "the update had no error", but that's only step 1...again, if the update would incorporate package updates.
NEO-CRON.XML (1kb) and NEO-CRON.BAK (25kb). is there a way to import the BAK file to restore the tasks? renaming the BAK file to XML does not fix the problem.
error: An error occurred scheduling the task.
The specified path: D:/Websection_ANONYMOUS/ANONYMOUS/logs/411_Security_Photo_Update.txt is not allowed for scheduled tasks.To allow it, whitelist the path in cf-root/lib/pathfilter.json against key schedulerexecutionpaths.
Even so, I'm surprised to hear of it BREAKING all tasks (let alone corrupting the neon file). And while the renaming of the bak file, just beware sometimes even that gets corrupted.
(When I said it did not in an earlier comment above, I was simply mistaken in the way I was testing things. My apologies.)
So as with URL vars, if any form scope vars are defined in the request (including in application.cfc/cfm), then it turns out CF has always implicitly passed those into any CFC methods called remotely--and as such this update's change about this (requiring that all input args to such remote methods must be defined) is affecting still more people, unexpectedly.
And as with the discussion of URL vars, the solution (for now) is either to define them as arguments to the function (if it's called remotely) or use the jvm argument to disable that argument "matching".
I fear that it will be hard for any scanning tools to "detect" that this problem exists, in that the presence/existence of URL or FORM variables could vary based on runtime execution. As such, I share also in the refined discussion within the post how I'm hoping Adobe may come up with a hotfix to help log use of these variables, like they did in Apr 2024 for helping with the implicit scope searching change from March 2024.
Yep, this update is providing another one of those with "a lot more than meets the eye"...but it's "all for the sake of security", folks. Buckle your seatbelts.
This was ColdFusion 2023 update 13 -> update 14 on Windows.
It appears that if a task publishes to a non-allowed location (i.e. one not specified in pathfilter.json) ColdFusion removes the task from neo-cron.xml on the startup of the application service. Any tasks that do not publish their output (or publish to allowed locations) are unaffected.
I tried adding the pathfilter.json file prior to running the update, but unfortunately the update process replaced it with the default empty version so that did not mitigate the issue.
So as far I can tell the only solution is the one Chris G suggests - apply the update, then update pathfilter.json, then restore neo-cron.xml and finally restart CF.
I strongly recommend ensuring you have a good backup of neo-cron.xml before applying this hotfix rather than trusting that the automatically saved neo-cron.bak will save you.
I think it's very poor that Adobe haven't made this clear in the tech notes.
It seems that since then, Adobe has in fact addressed the issue you raise. Note that the technotes (all 3 of them, for 2025, 2023, and 2021) now have a new bullet in their "known issues" section, starting with:
"After installing the update, the scheduled tasks configured with the Save output to a file option enabled may be removed from the neo-cron.xml configuration file."
It goes on to talk about their suggested "solution" of recommending people save off their neo-cron.xml before doing the update, and then adding back the task if removed (after attending to either having it not do the publishing of output or adding its path to the pathfilter.json).
I think that's pretty onerous...but at least it is now documented (to your last lament).
As such, I've just added a comment to the tracker ticket someone had created (as mentioned in the post), where I propose that Adobe could create a means to LOG such vars when passed in (and undefined as argumemts), when we may enable the jvm arg that disables the new "matching" behavior. Interested folks can read my suggestion as an elaborated comment there: https://tracker.adob...