Announcing ColdFusion updates of Aug 11 2026 - p1 security update - thoughts and resources

Well, Jeff, there's always an explanation. It just needs to be found.

1) So first, to be clear, in this "instance that is part of a cluster" (and the instances "not part of a cluster" necessarily on the same machine? Or different ones? That may be helpful to know.

2) Next you say you can't bring up the admin of the instance. Are you able to confirm if the instance itself is running (whether it's a service or something you may start otherwise)? That could be important.

3) If the instance is running but you can't get to its CF Admin, that happens usually because the process of applying the package updates failed (in some way). You say you confirmed that "install log" had no errors (by which we'll assume you mean the one in the hf-updates folder for the update).

3a) Did you go to the BOTTOM of that install log, to confirm (about 10 lines from the bottom) that it tracked successfully DOWNLOADING the package updates?

3b) And what about the startup log entries in the coldfusion-out.log? Any errors during the startup that happened after the update?

Those two are things I discuss in the "best practices" I point to in the post above.

4) For the update's install log, if there are errors (again about 10 lines from the bottom of the log) when it tried to "download" the package updates, that will be the start of your problems. Let us know if you see any or that for each it says "The package and its dependencies have been downloaded successfully".

5) Even if that goes well, then it's during the next startup that we'd want to see it "uninstalling" all the updated packages, and then we want to see it log the "start" of all installed packages (we don't see any log for "installing" let along "updating" them).

So go to the bottom of that coldfuison-out.log, find when CF was last started (right after the update): look for the words "coldfusion started". Then watch the lines right above that, which is the END of CF coming up. Note that if you have restarted CF since the update, you may not see any errors or any "uninstalling". I'm proposing you search for that "coldfusion started" until you find the update that happened right after you applied the CF update. (That install log in the update's hf-updates folder will have the time of the update right in its name, as well as within the file.)

Let us know what you find. Again, there can be various reasons these things fail, and then how to recover. There's no simple solution (though some people and AI may suggest some "one thing to try".)

6) Is this machine (and are these instances) ones that had been on the immediately preceding update of CF? Or might this be the first time you have updated CF on this machine? That could be useful to know?

7) And you haven't said if this is CF2025 or 2023, which again may be useful to know.

8) Sorry for this wall of text. If things were easy, then most folks could solve these challenges without help, or via the community, or via AI.

I'll offer finally (as I do in the post) that I can help you directly via remote screenshare consulting, perhaps solving this in less than 15 minutes (my minimum time interval). More at carehart.org/consulting. Certainly if you don't want to await back and forth here, just find and grab a slot at my online calender, carehart.org/calendar.

But if you can't or choose not to do that for whatever reason, I hope the above may well help you to solve things on your own. And if not, please offer replies to each the questions above and we'll take it from there.

OK, thanks for all that. And I can report that I have since recreated the problem...well, what I presume is your problem. I had a client report a similar problem today, and I just replicated it on my own.

Like you, they found that after the update, any CF instances in a CF cluster (and which had session replication enabled) would not run correctly.

(And for folks following along, creating instances of CF is something one can do in the Enterprise, Trial, or Developer edition but not Standard, using the CF Admin Enterprise Manager screen, for instance. That also offers a means to cluster instances.)

If you're hitting the same problem, while I don't have a solution I have spent hours trying to identify one--so far, to no avail.

1) So first, you can confirm if the problem is the same for you by looking in a different log--not the coldfusion-out.log, which is where I proposed you make sure the package updates were showing up. Instead look in the coldfusion-error.log. There you may see it reporting that there was a problem processing the server.xml file, which is where the cluster configuration XML is placed (such as in CF's instancename/runtime/conf folder).

Among the error lines may be:

Cannot find method [setChannel] in object [StandardEngine[Catalina]] of class [class org.apache.catalina.core.StandardEngine]

That's the error my client got, and that I confirmed I get. BTW, he was getting it in CF2023, while I (and you) get it in CF2025.

2) I'll note that some of the other error lines refer to XML parsing, so I wondered if maybe this was something about the one new XML-related change in this update, but I put in the JVM arg to reverse it and restarted but got the same error. So close, I thought! Then I put in ALL the JVM args related to XML (as documented in the CF docs page on CF2025 jvm args). Again, none made the problem go away.

3) I then resorted to getting Tomcat itself (Tomcat 10, the same version and update level as underlines CF2025 update 12). I wondered if maybe creating a cluster with replication was broken there. It was not. (They're good about testing things, in my experience.)

4) I did compare the files in that native Tomcat folder to the ones in CF's runtime folder, and there are differences. This is making me wonder if somehow the Tomcat implemented by Adobe wasn't quite completely updated.

5) I tried a few different tweaks, but even when I got it to further I then ran into new errors about te processing of the context.xml (as a sibling of server.xml)

I think we have to just declare it's a bug...whether about the Tomcat version implementation or perhaps about some change in XML processing (for CF) that could somehow affect tomcat loading of its xml files. The latter seems a stretch.

Really, it's for Adobe to resolve at this point, since 3 of us experience it (assuming you confirm getting this error as well.)

And in fact, as I was writing this up this response (after those hours of work) I found that in fact someone (not my client) has created a ticket at tracker.adobe.com--so it's more than just the 3 of us. Here's hoping Adobe gets to the bottom of things.

The ticket is here:
https://tracker.adobe.com/#/view/CF-4233544

Understandable on the recovery, and good that you upvoted the ticket.

Consider also sending an email to cfsup@adobe.com. It may help to offer them the link to the ticket and perhaps even these comments (the pound sign under each comment next to the name is a link to that comment.) Do at least let them know that I got it on 2025 in addition to your experience on 2023.

Finally, though, you mention using redis. Do you mean you have the CF Admin "memory variables" page configured to use redis for CF session variable storage? If you do, then you don't NEED the session replication in the cluster (as long as all the instances share the same Redis memory storage). That's another seeming solution to things, but a fairly big change for most folks.

If anyone's interested in considering it more, I have a couple of talks on the topic (using redis for cf sessions), including PDFs and/or recordings, on my crehart.org/presentations page.

But did you then turn off session replication for the cluster? It would not be needed. Indeed, that would not even WORK because that relies on CF's use of "j2ee sessions" (on that "memory variables" admin page). Use of Redis sessions requires that be turned off.

Ah, sorry. I missed that you said you had those "unchecked". Was working from a phone at the time, so juggling replies there is sometimes sketchy. My apologies.

And I thought that my client's and my testing showed that the problem did only happen if the cluster had those checked. (I'd even said it above and in the tracker ticket comment I'd added.)

You're now saying that's NOT needed for the failure, which is very interesting. I'm unable ATM to test/confirm that.

If nothing else, this comment may help others digging into the problem, while we await Adobe's resolution to it.

I have just sent the email to cfsup@adobe.com. Fingers crossed for swift resolution.

I have one question—would the same issue occur even if all instances in the cluster are updated?