Announcing ColdFusion updates of Sep 23 2026 - for CF2023 only
And unlike other recent updates, this one has no Adobe Security Bulletin associated with it, so not technically a "security" update, although among its changes are underlying Java library upgrades that are security-related. Mostly the update is about those library upgrades and many bug fixes. To quote the technote, the update "includes extensive OEM library upgrades, enhancements to Query-of-Queries, query metadata handling, and the spread operator, along with fixes across ColdFusion Administrator, SFTP, Solr, MongoDB, SendGrid, scheduled tasks, GraphQL, Redis configuration, and other core and package functionality."
Most important (and not clear from the technote), many of those changes are in fact the same ones that had been rolled into CF2025's update 8 back in June--which was itself an update to ONLY that version of CF. (While that update also added AI and many other changes to CF2025, this update does NOT add all those things to CF2023.)
So first, are you sure you didn't yourselves update the JVM that CF is using? Look at your CF admin for its "java home" value (or if you can't get to the admin, look at the java.home in jvm.config). What is the value for that? And do you know that's remained unchanged from before the update?
And if it may be a generic location (like jre-17 or jdk-17, since you are on CF2023 which runs Java 17), is it possible that something changed the specific java version in there BETWEEN the times that CF last was restarted and today, when you applied the update (which restarts cf)?
Even if that's NOT the issue, I may have another thought.
You mention FR. There's an issue that I HAVE seen hit other folks--if they use a javaagent (like FR) that causes CF and the JVM to load the "instrument" library. And a conflict happens when CF/the jvm loads a version of that library from a JVM (on the system path) which is OTHER than that which CF is set to use.
No, that SHOULDN'T happen. But it can happen if someone either installs a new jvm or installs some software that itself installs a jvm/jre that itself modifies the system path to put such a different JVM on the path. Then CF/the jvm running CF finds that instrument library in the wrong place.
I've been meaning to do a blog post on the solutions here. But rather than keep you waiting, let me share this with you and others (though again, I don't think it's about "this update to CF2023".)
First, of course if you remove that javaagent (FR, in this case), that "solves the problem" but I'm not proposing that's the right long-term solution. But it helps prove the point that this is what it's about.
Second, assuming you leave FR (or the offending javaagent) in place, go to the command line and start CF there, such as /coldfusion2023/cfusion/bin/cfstart (or coldfusion start), you'll see more clearly the error about the instrument library. Better still, if you are on Windows and run "path=;", that will clear out the system path (for the life of that command prompt only). And then if you run the cfstart (or coldfusion start) it should run.
But now CF is running as YOU rather than as a service. As soon as you close that command window or logoff, CF will go down. And if you are running CF as a service, then it's also running as YOU rather than as the account of that service.
So how do you solve the problem for a service? Here's the trick that has worked for me, on Windows.
Go into Regedit, find HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ColdFusion 2023 Application Server (or if on 2025, the service entry for that, and so on). In there create a new, multi-string value (reg_multi_sz) with a value of path= and a new line. That's it. Now save that, and stop that command line CF (use ctrl-c, or open Windows Explorer to that same cfusion.bin folder and run the cfstop.bat, which will open a window to stop cf and then the window will disappear. Don't use that approach for the cfstart, if you want to see the output above).
Then try starting the service. Does it now start? And does FR still work? If so, declare victory, and let us know here how it went. Heck, I've written half the blog post here. :-) Your feedback (and that of anyone else) will help me affirm what I should write.
Or maybe I'll learn something new in what you or they may report.
I am sharing this comment here to cause you to get notified about it. I hope you may see it before you may be writing a reply to the first/incomplete version. :-) FWIW, only you (as the only other commenter) would have been sent an email with the incomplete reply.
Conversely there's no mention at all of XML-related changes or bug fixes in this update. (The one reference to jetty-xml is about the CF add-on service, which would not affect the functions or CFML processing that you mention.)
If you're not aware of how to "know" what update you were on before u25, the easiest thing is to look at the cfusion/hf-updates folder. There you will find a folder for any update that was previously attempted (and there's a log within it for when it's installed or another if it's ever uninstalled.) Of course, you can skip updates (they are cumulative), so you may well find a folder for update 23 or 22, etc. Please let us know what you find.
And if you DO confirm there is no u24 folder, then be sure to see the update technotes (or my previous posts) about each update you skipped. There are JVM args that were introduced that may offer the resolution you seek (of course, they come at the cost of removing a protection Adobe was trying to introduce by the change).
Finally, even if you show you WERE on update 24 before this (and it WAS installed and NOT uninstalled), then since you say you opened a support ticket with Adobe, please do come back with any news they may share. In the meantime, we'll see if anyone else experiences what you have--if they applied update 25 while being on u24 before that.
FYI - xmlValidate() has been broken for a while, we were on update 18 and went straight to update 25 today. xmlValidate() was rejecting a valid document against any schema that has a namespace so we have been using Java's standard XML validator through createObject.
Thank you for putting a comment in here that even after update 25 xmlValidate() is still broken. Would appreciate an update after what Adobe tells you about this.
"Error","ajp-nio-127.0.0.1-8022-exec-2","09/25/26","11:35:00","","http://apache.org/xml/features/disallow-doctype-decl"
org.xml.sax.SAXNotRecognizedException: http://apache.org/xml/features/disallow-doctype-decl
at org.cyberneko.html.parsers.DOMFragmentParser.setFeature(DOMFragmentParser.java:249)
and so on...
Fairly certain this has only started to happen after update 25, the system was previously running update 24.
And if it WAS caused by your having previously been on some prior update, then you (and Tim) would want to consider the various jvm args offered with those updates skipped to see if any help. If so, you would now KNOW it's that update which changed the behavior. Then you could study (or work with Adobe) about why what you want to do should still work without.
Speaking of that, are you saying you get this error on running ANY scheduled task? If so, I'll say I've not heard of anyone getting this, in this or any other recent updates.
And if it's really only on the one, you could of course run it directly in the browser to see how it goes. Or look in the cf logs to see that the error refers to code IN the cfm page that's run as the scheduled task.
Finally, have you confirmed there were 0 errors reported in the update log, found in the cfusion/hf-updates subfolder created for this update? That's just a good sanity check.
In this case, it looks like their cleanup of Java libraries (a big part of the update) missed that one needed by sandbox security. One could assert that it's a little-used feature that Adobe failed to test for. But while it's currently deprecated, they should still test for it.
I'll remind folks (as I've noted elsewhere many times): the security sandbox feature relies on the Java security manager, and that was marked for removal (by the Java community process) some years ago. A coming release of Java WILL finally remove it.
And when that happens, the next CF version which is configured to rely on that then-latest Java version will itself HAVE to remove the cf security sandbox feature.
I've been a fan of the feature myself since first writing about it over 25 years ago (carehart.org/articles). It's sad that it will have to go (and sad also that more people never leveraged its powerful abilities).
One consolation is that containers can provide for much of the isolation that sb was built for--and it's certainly the more modern approach. But the cf licensing for containers isn't at all friendly, so moving to that for this reason (or others) will be more expensive.
And if you do it, please share the link here. But I know it's a chore, so if you do offer some simple repro here, that will still help some (especially perhaps Himanshu and Max here, to see if that's what their failing code is doing).
And either way (a ticket url or a simple repro here), I'd then offer a new "update" in the post above as a heads-up for folks, like I just did based on the confirmed issue that Ray had just shared.
I'm like an octopus when these updates happen, responding here and elsewhere, helping clients, updating the post when necessary. But bring it on, folks!
All this brings to mind various sayings I've occasionally shared in the face of helping folks with challenges: "what doesn't kill us makes us stronger", and "forewarned is forearmed", and "it's better to light one candle than to curse the darkness". Or my favorite, "as always, I just want to help"! :-)
I hope to spend more time on it today and then I'd offer here what I find seems to work best. Perhaps we'll also hear from others (and/or Adobe or the FR folks, though I would not expect it).
I'll add also that it seems to be an issue that affects more than FR but also other javagent's that may try to load that instrument library.
And yet it's not generic to "any java doing that loading" but instead it seems to be about CF specifically. And that would explain how something CF did (in this latest u25) would be the cause--even if one had NOT changed their JVM.
Very interesting challenge. Short-term, yep, just remove the javaagent. I hope to offer a better long-term workaround...which may then help Adobe implement a better permanent solution (if we can discern what changed and why, and whether they may relent).
It's worthy of its own post, and I hope to do that (perhaps even today). But the bottom line is that I can affirm that what's happened with this update 25 is that it introduced changes in xml processing which were NOT in update 24 or before...but they HAD been introduced in CF2025 in its update 8 (this past June)! So despite what the CF2025 u25 technotes and the Adobe resources above say, there was indeed MORE to this update. (None of them mention xml or doctype, as of today at least.)
To be clear, that update had a LOT that was new and changed in CF (so much that there is an entire what's new page for it). It's NOT quite clear WHAT aspects of that update WERE rolled into CF2023 u25. I can say that of course the vast AI feature set (new in that update) was NOT rolled into THIS update.
Back to this xml validation issue, the "good" news is that the docs for both those functions indicate what can be done. There has been an available "parseroptions" argument (itself introduced in 2024, in CF2018 u14 and cf2021 u4), which expects a struct. It allows control over certain aspects of parsing xml in functions like xmlvalidate and xmlparse (and others).
Well, it was CF2025 update 8 (this June) which added some new xml parsing protection--specifically no longer allowing ues of DTD's that had a doctype in them...unless you used a new key (added also in that update), called allowDoctypeDeclaration.
It's THAT which is also now restricted by default and also now supported via this parseroptions key, as of cf2023 update 25. I confirmed 100% that his failing code (which worked in u24 but failed in u25) now WORKED in u25--if this slight change was made.
For now, I will leave you (who are interested) to read the docs:
https://guides.adobe.com/coldfusion/en/docs/cfml-reference/xmlvalidate.html
https://guides.adobe.com/coldfusion/en/docs/cfml-reference/xmlparse.html
Beware: if you are instead led (via searching or other links) to these url's for the same function doc pages, they are NOT updated even with this change from CF2025 update 8:
https://guides.adobe.com/coldfusion/en/docs/introduction-to-coldfusion/__references__/xmlvalidate.html
https://guides.adobe.com/coldfusion/en/docs/introduction-to-coldfusion/__references__/xmlparse.html
I have reported that issue to Adobe.
So again, the big takeaway is that it seems this update was a lot more than what was revealed (if this one scenario has others like it). Perhaps in time Adobe will better clarify what else changed in this update. I asked them about that. No promises anything will come of it.
As for those two "updated" doc pages I just shared, folks may well notice also that (as of today at least) these two doc pages still make reference to that allowDoctypeDeclaration being new only as of 2025.0.8. I reported that to them also, that they at least need to change this to add 2023.0.25.
Again I hope there may be more coming from Adobe on what other things "changed" in this update. Until then, hope this helps. For now, I'll add another "update" to the post above pointing to this, and later I'd link there to any new blog post I may create (with more on this xml issue), if I create one.
thankfully I do the Dev server first.
-javaagent:D:/FusionReactor/instance/cfusion.cf2023/fusionreactor.jar=name=cfusion.cf2023,address=8088
-agentpath:D:/FusionReactor/instance/cfusion.cf2023/frjvmti_x64.dll
so -- no more Fusion Reactor until a fix from adobe?
Michael
java and agent paths remain the same in .config.
We are also pausing the deploy of this update to PROD until the dust settles in a couple of different non-related areas, as well as finding out more why these changes occurred.
For those reading, this is a brief not fully detailed overview of what we did:
--CF2023 Update 25 applied via CF Admin on Windows server
--CF would not start, logs showed successes with update, no warnings/failures
--manually set path for logged in user, CF would start
--set JRE paths via environmental variables in sysdm.cpl
--CF would now start for all authorized users, including CF user account
--FR would not start, give the CF user account 'full control' of the path, and it came back
As for the "other issues", I don't expect any change from Adobe on the xmlvalidate: that seems an intentional change. And the sec sandbox one has their fix already. What other issue are you thinking of?
Or do you mean "the unknown"? If so, I'll just note that unless people implement the update, the issues could remain unknown. Granted, this update was not classed as a security update (no apsb associated with it), so perhaps some will feel safer "holding off" on it...
But as soon as an update 26 comes out, and assuming it's a typical p1 security update, that will NOT be one that folks will want to "hold off" applying. But of course that WILL incorporate update 25's changes, so you'll have to "pay the freight" of implementing it then.
Just cautioning against complacency in applying this update. The info shared here should help many at least make informed decisions. As always, I'm just trying to help--and I certainly appreciate the additional info provided by you and others here in previous comments.
I'd rather not have to give Full Control to the CF user account (seems like that would make the environment less secure) but that may be what we have to do for FR.
I'm simply saying that I think it's better for most people to treat this like something they MUST deal with, and the sooner the better, such as doing extensive testing in a non-prod environment. I do realize that many have nothing but prod, or can't really test completely in their non-prod. It is what it is.
Finally, as for the observation you share about accommodating the impact on FR, let's be clear that you're referring to what BRIAN proposed in his last comment. I would not suggest that the only solution will be to "to give Full Control to the CF user account".
Again, I will have more to share in time on what I hope will be a simpler yet safe solution. I'll add also that I've asked the FR folks if they yet have any insight into the issue. If I learn anything, I'll share that of course.
I can confirm now that it may be limited to Windows only. I can at least confirm that when I tried to recreate the problem with Adobe's CF container images (an easy way to create isolated, repeatable tests), I had no problem starting such a CF2023 u25 container with FR implemented in it.
And so I tested the same in a pure linux install (Ubuntu, FWIW), and I confirmed that it also had no problem (running CF2023 u25 with FR). So unless someone on a Mac indicates that it happens with them, it seems safe to conclude this is a Windows-specific problem.
That may help alleviate the concern of folks seeing/hearing about this discussion of issues with FR/instrument library loading. My money is on it being an internal change (within CF) about paths it adds to the path (as loaded from Windows).
And I have a possible simple solution: I just am working to create an independently verifiable/repeatable/isolated test. It's off to a Windows VM for me next.
And I can also offer a simple and seemingly safe workaround while we await Adobe's resolution. Rather than elaborate here or even as an update in my post above, I've just created a blog post with the background, root cause, and workaround (whether running CF at the command line or as a service). See:
https://www.carehart.org/blog/2026/9/29/solving_new_cf2023_update_25_startup_problem
And please share feedback on that there, rather than here. With that, it's bed time...and it's been a VERY long day dealing with this. Hope this helps other folks, and Adobe as well.