Apologies for not posting this earlier. Please read all update notes concerning this update, as it includes a breaking change in handling unscoped variables. There is also a workaround if your code is breaking with this fix and you do not have time to refactor. Please note this workaround is temporary and will be removed. ColdFusion 2023 (Update 7) and ColdFusion 2021 (Update 13) Security Updates are live now ! The following are live as part of this release : • ColdFusion 2023 Update 7 • ColdFusion 2021 Update 13 Security Vulnerabilities addressed in this release are mentioned here – Adobe Security Bulletin OEMs upgraded with this update: • Tomcat – 9.0.85 • Jose4j – 0.9.4 • Ib6coreutil – 1.3 • Log4j in cfinstall.jar for zip installers – 2.20.0 Out of 22 issues reported by an internal security team audit, 19 issues have been fixed in this update. The others are low priority and will be handled in the next update or with CF2024. As a part of this update, • We have also addressed 2 EETs CF-4219940 & CF-4220252 • Docker Images for ColdFusion 2021 and 2023 will be pushed to AWS ECR & Docker Hub soon. • CF Fiddle will be updated with the ColdFusion 2023 Update 7 & ColdFusion 2021 Update 13 soon. HELPX KB Articles/Other links : CF 2023 Server Update 7 Tech Note https://helpx.adobe.com/coldfusion/kb/coldfusion-2023-update-7.html CF 2021 Server Update 13 Tech Note https://helpx.adobe.com/coldfusion/kb/coldfusion-2021-update-13.html Community Blogpost https://coldfusion.adobe.com/2024/03/released-coldfusion-2023-and-2021-march-12th-2024-security-updates/ CF2023 packages https://cfdownload.adobe.com/pub/adobe/coldfusion/2023/packages/hotfix-packages-cf2023-007-330663.zip CF 2021 packages https://cfdownload.adobe.com/pub/adobe/coldfusion/2021/packages/hotfix-packages-cf2021-013-330286.zip CF2023 Server Updates History https://helpx.adobe.com/in/coldfusion/kb/coldfusion-2023-updates.html CF2021 Server Updates History https://helpx.adobe.com/in/coldfusion/kb/coldfusion-2021-updates.html

Please note this workaround is temporary and will be removed.

Is there any sort of idea on how "temporary" the workaround is? I manage several large legacy CF codebases where refactoring for this will be a significant effort.

I believe currently the only 100% known "it ain't gonna be there" that's been confirmed is that in CFNext, that flag is gone. So when the new version drops, if you want to go to it, your code needs to be running. Note that just because a code base is legacy, does NOT mean this breaks it. I was taught from day 1 to scope my variables (thank you Nancy Capitanio!) I've seen lots of very, very old code that works just fine.

By CFNext you don't mean future updates to CF 2021 or 2023, right? You mean whatever major release follows CF 2023?

I thought the JVM flag was temporary (until CFNext). But is the

this.searchimplicitscopes

also temporary? That application setting has been around for a few versions already.

@Mark Takata (Adobe) I too always scope my variables, and I always recommend that to my teams. I do it simply because I dislike ambiguity in my code, but alas, not everyone is a wonderfully OCD as you and me and I manage several applications that have been in development for 20+ years with tens of thousands of files and have had teams of developers and turnover, etc. We will have to turn it off on dev, and see what breaks.

@Scott Bennett I'm in very much the same position you are RE older legacy codebases, not all of which I can take the blame for. I've taken that approach of disabling searchImplicitScopes on our dev environment and started running tests (automated where we have coverage, manually where not) to find and fix breakage.

@rstewart yes, I plan to do exactly that… full QA with that flag disabled

CFNext = next FULL version of ColdFusion, not updates. I'll wait for Saty to say how soon things might go south for you.

@Mark Takata (Adobe) Hope you are recovering fast ? @Scott Bennett Unscoped variables may not pose an immediate threat, but they create opportunities for vulnerabilities, especially in the presence of existing loopholes within the application or server code. We have diligently worked on rectifying numerous such vulnerabilities in our server code. However, it's imperative to adopt best practices like scoping to mitigate risks across the board. To avoid catching everyone off guard with a sudden change, we've introduced a JVM argument, allowing developers to override the default behavior by setting

searchimplicitscope=false

. This adjustment gives application developers a grace period to update their code accordingly. The specific timeline for this transition remains under discussion internally. We're actively engaged in deliberations to determine the exact timeline and outline our approach to deprecation and removal. It's essential for the community to be aware that this change in behavior will occur, prompting proactive adjustments to codebases. We're committed to ensuring a smooth transition and encourage individuals to begin modifying their code in anticipation of these forthcoming adjustments.

Thank you sir! I am recovering strongly, and may even be cleared to go outside today haha.

One thing that would be absolutely wonderful would be a way to log deprecation warnings whenever a line of code ends up pulling a value from a scope that will no longer work with this change. This would be immensely helpful on large code bases, as we could turn on the logging in production and then the normal course of users using the site would still work, but provide us developers with information about where things need to be updated/fixed. Any chance that can happen?

I think the issue there is determining whether a variable is unscoped, or just not instantiated properly (spelled wrong, logic error, etc). I believe @foundeo was considering some capabilities in one of his tools that could potentially provide insight into this.

The log would happen when ACF code returns a value from one of the scopes that it "shouldn't" be looking in.

That's the thing, it won't be looking. When you turn off implicit scope search, it doesn't go look. It just says "oh, variablename is not defined". At least that's my understanding.

Right, with the new default behavior that's how it works. We currently have a "temporary" workaround. Those of us that would need this deprecation warning are those that are utilizing the

searchImplicitScopes = true

configuration, so it would be looking in those scopes. The idea of deprecation warnings is to alert the developer of code that will break in a future update.

Seeking a clarification on all of this: The only code that will have issues in the future are unscoped variable references that would have been found in one of CGI, URL, Form, Cookie, CFFile, or Client. Is that correct? Or, stated another way, all scopes except for those listed will continue to be searched?

AH gotcha, makes sense.

@James Harris • CGI • URL • Form • Cookie • File • Client are the only impacted scopes as these scopes fetch values directly from application users & can be manipulated easily. Rest are fine for now but we advise to scope all variables.

Satyam, thank you. One more quick one - in the case of

var vs. local

, does this mean you would recommend using local going forward?

@James Harris I am not sure about it. We are not touching these scopes currently. But as per my knowledge local was brought to replace var in CF9.Also scopesearch for local is expected to be faster than var.I will look into codebase and if I am able to dig some better info, will respond here.

Again, thank you @Satyam Mishra. Sorry to keep throwing things at you, but I appreciate it immensely! In regard to your statement "... scopesearch for local is expected to be faster than var...", I recently posted about this recently in this CFFiddle. We are experiencing

local.

being our slowest implementation, granted the code in that Fiddle is strictly for demo purposes and does not represent use-case scenarios.

@James Harris No Problem James.Happy to help. I remember that discussion. Somehow our expectation and result is not matching currently. But that point is noted & will be taken care of in future.

In case of problems, we're backing up our servers before applying this update (and others going forward). ColdFusion is on its own drive, which clearly we would restore from backup if it's broken. Does this update modify anything on the system drive, so we should restore that too? I assume it doesn't modify any of our code, right?

To confirm with the latest HF/CF2023, is there a known issue with Debugging enabled in CF Admin? IE, we had an upgrade from CF2018 to CF2023, and all settings being equal, Classic/Docked debugging does not show when enabled in CF Admin. thoughts?

@Mark Takata (Adobe) @priyank_adobe Any thoughts on whether this and future updates may modify anything outside of the drive where CF and java are installed?

Hi Dave, it is not

Thanks, good to know. I've had the uninstall process leave ColdFusion inoperable after running it from the admin UI, and some others here have had that happen too, For that reason, I really want a simple way to revert that's under our control.

@Dave Merrill we don't modify any code or system or registry tweaks in this update.

FYI as Mark mentioned earlier in the thread I was working on a way to scan code for unscoped variables that need to be addressed, I’m happy to say I have this working in Fixinator, here’s some more info: https://www.petefreitag.com/blog/fixinator-unscoped-variable/