Updates released for ColdFusion 2023/2021, Mar 12 2024: possible breaking change, solutions

Yes, it WILL negate the specific aspect of the update regarding implicit scope searching. So also will changing it in application.cfc/cfm. It's a workaround, to be used responsibly. I have tweaked the post soon to make that point more clear. Thanks.

I can't say, nor can anyone other than Adobe or the folks named in the apsb. There's no detail there, nor any as we search now for that cve. All places I find it mentioned indicate that there is no detail released currently.

But to be clear, in my pointing to these workarounds, I'm not saying anything the technote doesn't also.

Those with the concern you raise should ask Adobe. They don't necessarily (and don't see to) read my blog, so we should not necessarily expect them to see this and offer an answer here.

If anyone finds an answer or more detail elsewhere, please do share.

Ben, thanks for the kind regards. And first some good news: it's really not been "every other month". :-) The last one was in November, so 4 months ago. But sure, there was a major update in Oct, then before that 3 updates over the summer. That is what felt like a bombardment. But as you allude to, security trumps convenience these days.

As always, I'm just a messenger, one person trying help others, as indeed you so ably (and frequently) do. And we appreciate it!

As for Commandbox I can only say that they're always on the ball and a new one may already be in the oven. I don't see an update yet on Docker hub for them or Adobe (Adobe's forum thread said new images were in process).

Until then, yes, folks can just update their images like other folks using cf would (even if it feels icky on a container). Or yep, as I'd noted above, anyone can get a head start BEFORE doing the update by setting searchimplicitscopes=false in their application.cfc/cfm, to force the change in behavior that will become the default with the update. That will help them see if/when unscoped vars would be a problem (again, not ALWAYS).

While they could start updating their apps to use searchimplicitscopes=true as a "workaround", that should be carefully considered. First, the new jvm arg could be used instead (after the update). But EITHER workaround should be weighed against unlocking the very door Adobe was locking for the sake of security.

Here again, convenience (compatibility) vs security needs to be weighed carefully. This is the new reality (secure by default) being imposed on us from many directions: in CF, in IT generally, on our devices, and even in our daily lives.

Yarrr, I think I accidentally unsubscribed via link in email. Just leaving a comment to be re-subscribed.

Thanks as always for the write-up Charlie. I updated this morning locally and the first app I loaded had a variable error. I used the jvm switch to get around it but we have a pretty large codebase so I am not looking forward to the updates we will likely have to make.

I wasn't sure from the technote which "workaround" would go away so if I read your assessment correctly I will probably try setting "searchimplicitscopes=true" in our main Application.cfc since it seems that that will be support even when the JVM switch is no longer supported.

Thanks again! Always grateful that you have such a great place for CF information since it sometimes feels like a lonely CF world.

SteveC, thanks for the kind regards. To your question, I addressed that when I said "you will NOT be able to rely on that 3rd option beyond CF2023". The 3rd option was the jvm arg. The 2nd option was the application-level setting. I will add yet another sentence, if that may help some readers. But your question and this answer should also help those who may more likely see this for some reason. (I know it's all a lot to take in.)

Finally, as for your feeling like you're in a "lonely cf world", PLEASE see that last link I offered at the end to several available community help resources: you will find issues like this and many more discussed every day, whether you prefer email lists, web forums, slack channels, facebook discussions, linkedin discussions, and more.

You are definitely NOT alone. You are rarely the only experiencing some problem. And you need NOT rely solely on google searches or AI engines to find answers. And of course, some simply prefer talking to real people (flawed though they may be, in their knowledge and sometimes even in their online personalities!)

The JVM Argument approach works for me, but for some reason the application.cfc method does not seem to work for me. Thoughts?

Currently, as of 9:13 GMT the URL 'cfmodules.adobe.com/bundlesdependency.json' is missing the update 13 packages. The update of my live system to 13 this morning via CFAdmin applied the core update but none of the packages, it removed the existing packages which have been flagged for update by Adobe. After re-installing the Administrator package via CFPM I noticed it installed version 11 and not 13, this is when I checked the packagesurl and noticed its missing any reference to update 13. This worked fine in my Dev environment on Wednesday (13th). For whatever reason it looks like the online version of bundlesdependency.json is incorrect.

I also noticed when viewing the Update 13 URL from any other region than US (uk for example), the links to the hotfix installer and zip repository go to hotfix version 12.

UK page - https://helpx.adobe....

When viewed from the US, the links go to version 13 as they should.

US page - https://helpx.adobe....

Readers here may want to note that I just found Max had raised his issue both here and on that Adobe forum thread about the update (that I linked to in the opening here). He raised it there about the same time as here, a few hours ago (which is OK by me).

Anyway, Adobe has responded there (looking into things). Here's the direct link to his comment there, and the threaded replies from Adobe follow it:
https://tinyurl.com/...

BTW, some may notice he's listed there as Adam36099131ak4s, but the message is the same, so I'll assume he just had that existing Adobe account name but uses a different pseudonym in other places, like this.

Max/Adam, thanks for the update, and the kind regards. :-)

Andrew, thanks for the details. I can confirm seeing the same problem of that UK version of the technote showing info for 13 but links for 12, for doing the manual update.

But about the first problem, help us out: did you apply the update via the cf admin, on both servers? Or this manual update?

And in the update install log (within hf-updates), does it show having applied update 12 or 13? With 0 "fatalerrors" reported in that log?

And then in the coldfusion-out.log and coldfusion-error.log, what errors are shown during the first startup of cf after having applied the update? That's when updates to the packages actually happen.

Vicki, glad to have helped. I'd not gotten that new post out yet. I hope to at least tweak this post to add the clarification, to save folks having to read to here. :-)

Andrew, you're not the only one to report this, but you can solve things.

Frist, let me note that I have NOT seen it on all the servers I've applied updates to--except one, yesterday. And for them, we did not take time to dig into WHY it happened (they just needed the update applied and their site working ASAP).

Like you, we dropped to the command line (as admin) and went to the cfusion/bin folder and ran cfpm install administrator. With that, despite an message suggesting we'd need to restart, we were able to get into the CF Admin.

Then we went in, and we saw that in the "Package Manager" page (second to last on the bottom left), in its "available packages", there was several which were not installed--including document and pdf, like you. To be clear, all packages should have been installed, since this was a typical full install which includes all of them.

We clicked "install all" and that solved it for them. Their app now worked. (Knowing this now, you could also just do a "cfpm install all" from the command line, instead of just "cfpm install administrator".)

Let us know how it goes. If you struggle and don't want to await back and forth here, I can certainly meet with you via a remote screenshare consulting session (as I mention in the post: more at carehart.org/consulting), and we should be able to get the update in place and working quickly.

Then if you want, we could do more digging into what it is about your setup (and those of some others) that makes things not "just work" as they should. There must be some explanation--especially of how it happens to some but not all of us.

Andrew, thanks for the update and of course glad to hear you're working again. As for the musing you offer (which may be confirmed at some point), can you confirm where your server is (country/region)?

Ssykes, I assume you mean, "are those reporting update install problems only having them when run from the admin?" It's possible, yes.

I'll note that I've recommended the manual install as an option in both the post and other comments (like to Andrew, most recently), so again yep, I'm with you. :-)

Just wanted to mention to those who have been waiting for it... Fixinator has been updated to scan for unscoped variables that need to be fixed released to this update. The details / demo here: https://www.petefrei...

Charlie, not sure if you'd consider updating your blog post to mention this, but it might be useful for those that don't make it all the way down here to the depths of the comments :-)

Was looking to see if you had any guidance on what defines "the next major release of ColdFusion"? Does that mean the next non-security HF update, one of their installer refreshes, or ColdFusion 202X?

Also, we've seen some confusion on if setting searchimplicitscopes key to TRUE in Application.cfc or Application.cfm will continue to be supported once the JVM flag -Dcoldfusion.searchimplicitscopes is removed?

We're trying to understand the timing implications to budget development time to work on this and knowing some deadlines would be good for making that happen.

We've discovered that capital Ds in date formats like "MM/DD/YYYY" are now interpreted as day-of-year where previously they were treated as day-of-month.

Steve, thanks for stepping in and sharing that. And Keith, I suspect you've just moved to CF2023 or 2021 after having been running on CF2018 or earlier until recently. If so, welcome.

1) So as Steve notes, I blogged on this problem (which started with CF2021 and remains) when I found it back in Nov 2020 when CF2021 first came out. That first post Steve offered does discuss it in detail. And as that post indicates, I did another when when Adobe offered a solution a couple of weeks later. In that post (https://www.carehart...), I explain how they created a JVM arg that we must add to make CF treat a capital D like in a dateformat mast the way it always did. Again, those using CF2023 and beyond also will need to use that, to get that backward compatibility.

Or see how I mention (in both posts) that some kind souls offered regex searches that one could use to find and correct such uses of D, in many possible variants of dateformat and related functions.

2) Of course, you're bringing this up here on this post about yet ANOTHER breaking change, both of which are surely frustrating. And as in that case, Adobe opted to go with the breaking change and a jvm arg to REVERSE it, rather than the other way around.

And though these happened 40 months apart, you're not alone in only experiencing the first one only now...which is like how I concluded THIS post with how THIS new problem will ALSO plague us as future folks move to CF2021 or 2023 and apply this update, or move to CF2024 and beyond, which will include this change to the default for searchimplicitscopes as a built-in change. A difference is that while Adobe is choosing (for security reasons) to NOT allow the jvm arg reverting that to work in CF2024 and beyond, again this JVM arg for the dateformat issue IS still supported in CF2023 and beyond.

3) Finally, back to the issue in THIS post and since I suspect my comment here may lead someone to ask: no, I can't see any possible regex that could reliably "find all unscoped variables". There are just WAY too many ways that code could name/use variables: with or without pound signs, with or without spaces around it, with or without parens around it, within quotes (as in isdefined), and on and on. More than that, not ALL unscoped vars MUST be changed, as I elaborate on in the post.

But as I noted in a previous comment and an update to the post, Pete Freitag has done the community a solid in having added to his Fixinator tool such scanning (as effectively as possible) for potentially risky unscoped variables.

And maybe someone will offer here or elsewhere a regex they work on which they think helps do the job. If it works well, I will certainly highlight it! :-)

1) Thank you as always for the helpful posts. Of course using your application tip I had manually checked my sites before Adobe came out with that log option.

2) I am DELIGHTED that one of the sites I inherited in 2007 was very much affected by this breaking change! Budgets are tight so I finally received approval to take it down. Who-hooo!

3)FYI: I found that I can always update via the Admin IF I manually control the server restart. Get the admin page up, get service panel up, stop any extra CF services, kick off the update, stop CF Application service, Start CF Application service, start other CF services, success.