Announcing ColdFusion updates released Sep 9 2025 - p1 security update
As usual, there are a number of things you should consider before (or after) doing the update, with some discussed in Adobe's resources on the update (there are more than one), and some info that I share below based on my experience helping people apply this and past updates.
In this post, I share the details about the update (from Adobe and from others). I can report I have installed the update for each release on multiple machines and operating systems without any major incidents. As for challenges (common to recent releases) and lessons learned (about this update), read on.





Is anyone else in that scenario (or, I guess, any scenario) seeing the infamous "Cannot find implementation class coldfusion.tagext.mail.MailTag for the mail tag" error after applying the hotfix?
I've uninstalled/re-installed the 'mail' package; I've cleared the felix-cache 3 different times. But, I can't get rid of the error.
Any other suggestions? Thank you.
In my case, several more files were reported "missing" in that log during the startup. And I found them listed as several "removed" by the update in the hotfixfilelist.log, located next to the update log.
And like you I copied the ones listed as missing back into place. The update had saved them into its backup/bundles folder. I copied those listed as missing back into cf's bundles/repo folder, and I restarted CF. The errors were gone and tests worked.
I want to repeat: this was NOT needed in other updates of that same version, each configured the same way and updated the same way (in my case using the admin, not the offline manual update you mention).
So no, I wasn't doing it as you were, but my point is that one had the problem I saw but the rest did not. So it just supports again that it's not clear that even even everyone who updates the way you did will have the problem you did.
Still, thanks for sharing your observation. If you have your logs and could check what I did, it might be interesting to hear what you'd see.
I think the most interesting thing will be to find what CAUSES these errors, when they may or may not happen on what seem at least to be identically configured cf instances. Clearly SOMETHING is different.
But at least you and I have offered two scenarios, with solutions that may help others. I know some people don't care to understand WHY problems might happen: they just want the solution. As always, I hope to offer both. :-)
I'll be trying the approach you followed, to see if and when I may get that problem you did. Hope all this may help someone. Thanks again for adding to the conversation--and the research.
And also, any idea why I can't get to the actual article frustratingly alluded to by Google here:
https://community.adobe.com/t5/coldfusion-discussions/solution-for-quot-axis-package-is-not-installed-quot-error/m-p/15629936
Experiencing a very weird issue with axis package CF2023 Up.18 - any pointers, ideas, as always gratefully received. We've tried a bunch of recommended procedures for offline updates (cfpm, deleting felix cache etc). Proving to be a real blocker. Note no issue whatsoever on our local CommandBox Dev machines which install Upd 18 just fine with axis package at v15. Many thanks.
1) To be clear, no. No one should need to do any such copying of jars manually. In every case I've seen, the cause was the person not following the exact steps from the update technote about doing a manual offline update: specifically their not extracting the new zip to a new location and pointing CF at that.
Instead in each case they have tried to shortcut things by extracting the zip to be in PLACE of the existing bundles folder (often they have renamed the old bundles folder and extracted the zip into its place). That is NOT what the technote says to do.
Indeed, you'll see that the last comment from Roberto on Dec 11 (in that post you pointed to) he clarified he did that and that solved his problem. (Matt then followed up with his messy steps. I didn't have the energy then to clarify that he was leading people down the same path that has gotten others in trouble.)
So tell us what you did. And have you tried following the documented steps, even if they seem tedious (they're certainly less so than all that Matt listed).
2) As for the fact that google (or other resources) point to forum threads at Adobe that seem "gone", that's not unique to that link you offer. Adobe made a major change in the past couple of weeks on ALL their community forums (it's NOT unique to CF).
And in that transition to the new forums, the powers that be (NOT the CF team) curiously put the new system in place WITHOUT the previous two months of forum threads. They said before and after the move that "they would be recovered soon", but I'm hearing it could be March. That's ridiculous, of course. But again it's NOT on the CF team...and there's no use complaining about it. The entire community of users of other Adobe products have done it plenty, but nothing will change the fact that we must merely wait for them to solve things.
It does indeed mean that a LOT of recent and VALUABLE threads of discussion (again, across ALL Adobe products) just turn up empty link that one.
3) Finally, you mention a problem with the Ajax package--but you offer nothing about the details (other than "what you've tried" and that you're "open to ideas".
So if I'm to play alone, my first guess is that you have modified your CF Admin setting for the "Default ScriptSrc Directory" (in the first page of the CF admin) to be some non-default value. I've seen that cause a problem with the updating of the ajax package (because it seems the update process has NOT been designed to be sensitive to someone making that change--recommended of course by the Lockdown Guide and tool).
So for now, if you want the Ajax package updated consider changing the default script src back to its original default: /cf_scripts/scripts/
Then try updating the ajax package (or remove and add it back if you can't seem to "update it"). Let us know if that works.
I'll add as well that anyone facing problems like this can instead just hire me for as little as 15 minutes to help understand and resolve such problems. Again, often I'm left to guess at what people are doing, and I share my observations from having helped many. But there's no substitute for getting on with you directly, in a remote screenshare session. As always, you won't pay for time you don't find valuable.
Still, I know some people can't or won't consider that. So sure, we can labor on here. Apologies to those who have commented previously on this post, in that you then get CC'ed on ALL subsequent comments on the post. Hey, what doesn't kill us makes us stronger, right?
Bill, if you try any of the ideas I offered and they work, please do let us know to help future readers.
However, although swapping the felixclassloader to later version definitely fixed a local issue I had with CommandBox and the mail package, it was not the cause of the issue we had with the axis package on our AWS servers...
With the axis package (not ajax) the issue we had was with the JVM arguments. I'll post shortly what we added to solve it (Webservices page in the CF Admin was telling us axis package not installed even though it was). I believe all this is probably related to the shift from axis 1 to axis 2 - but that in itself is a separate topic (we are probably going to have to make some changes to old code reliant on axis 1 features).
If one of our guys hadn't found this JVM fix I was going to ask for a 15 minute session with yourself, it being so odd. Iwish I could say I found the fix but I can't - we use AWS servers which basically completely install CF from scratch and automate all the hotfix update stuff (so should in theory 'just work' as the infrastructure code has been just fine up to now, applying CF updates along with all package updates (hey, who really wants to do these manually!)
"--add-exports=java.base/sun.security.x509=ALL-UNNAMED",
"--add-opens=java.desktop/sun.awt=ALL-UNNAMED",
"--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED",
"--add-opens=java.base/java.util=ALL-UNNAMED",
"--add-opens=java.management/sun.management=ALL-UNNAMED",
"--add-opens=java.base/java.io=ALL-UNNAMED",
"--add-opens=java.base/java.net=ALL-UNNAMED",
"--add-exports=java.base/sun.util=ALL-UNNAMED",
"--add-opens=java.base/sun.util=ALL-UNNAMED",
"--add-opens=java.base/sun.security.util=ALL-UNNAMED",
"--add-opens=java.base/java.nio=ALL-UNNAMED",
We did see in the update log that when it got to re-installing the axis package it just skipped over it, whereas with all other packages the log was listing all the dependencies correctly (those jars in the bundles/repo folder).
Quite confusing as a visual check was telling us that bundlesdependency.json was correct, all the axis jars were present and correct and cfpm was telling us that axis would be installed. Just the CF Administrator would not load the 'webservices' page.
It's hard for me to supply logs etc as evidence, as I don't have access to the servers - can't even RDP to them, so just reporting what I observed during a Teams session.
The second was on an AWS server with quite a different environment - CF2023 but with automated hotfix updates infrastructure code running updates - i.e. not using CommandBox, but automating the update process.