It's very important that people read the technote before "just applying this update". There is a very important (and fundamental) change in how CFML processes variables, with regard to searching for scopes when no scope is indicated on a variable name. It's NOT that you "must scope all your variables", as some are asserting. But it's still almost certainly a BREAKING change in many CF apps, if they use unscoped variables under certain conditions (that I discuss below). The change is for the sake of security, but it's just one aspect of the security fixes in this update.

Anyway, there are 3 things you can consider doing to rectify/work-around this breaking change, as I discuss below (or see the update technote, for this and more). And you may reasonably wonder what the implications would be of using the workarounds. You may also wonder if this scope matter relates to the CVE listed in the APSB (linked to below). That's currently unclear. It does not. As well, note that the Adobe security bulletin (link below) shows the security fix to be only a P3 (priority 3, the lowest severity), not a P1 (priority 1, the highest), though it IS regarded as "critical".¹

But then there are still other aspects of the update beyond this scope matter, and you should be aware of those also.

For more, read on.

• Finding (and finding more about) the update
  • As with all CF updates, possible need to upgrade web server connector
  • As with all CF updates, possible error you may experience applying update in CF Admin
• Particulars about this latest update
  • Other changes besides the scope search issue
  • Important change to CF behavior of searching through certain scopes implicitly
  • What code with "unscoped variables" might break? Not ALL, but some (perhaps much)
  • What are the affected scopes ("local to" and "outside of" the request)?¹
  • You don't NEED to wait for the update, to start testing for this impact
  • Feature added by Adobe a month later, to help identify code that would fail
  • Three ways to address the change in implicit scope searching
  • Implications of using searchimplicitscopes=true¹
  • If I set searchimplicitscopes=true, am I opening myself to the 'Arbitrary file system read' CVE?¹
  • Possible ongoing impact of this scope search default change for years to come
• What about folks using Lucee?

Before getting to the issue above, let's talk about the updates in general (as I try to do for each update).

Finding (and finding more about) the update

While you should see the update appear in your CF Admin when you login (and if you don't, give it time as there may be a caching issue), Adobe has announced it via their CF Community Forums:

NOW LIVE! Adobe ColdFusion 2023 and 2021 March 2024 security updates

You will see I have already started engaging in discussions there, sharing some of what I share here.

And that points to the (very important) technote for each version's update, as well to the Adobe Product Security Bulletin (APSB) related to it, with (just a little) more about security issues identified and addressed:

• ColdFusion (2023 release) Update 7
• ColdFusion (2021 release) Update 13
• Security updates available for Adobe ColdFusion | APSB24-14

Given that the update includes security fixes, it would seem in your interest to get them applied ASAP. (I have no further info about the vulns to share than what is in these two pages, and since they were just posted I don't have news yet of any challenges anyone may have had. I can report I installed both updates without incident--though with a caveat below.)

As with all CF updates, possible need to upgrade web server connector

While the technote offers a table at the bottom reporting which updates did require such connector updating, not it refers to "recreating" the connector (which implies removing and re-adding it). But since cf2016 we've been able to "upgrade" the connector using the wsconfig UI (or command line). I have a blog post with more on that here.

As with all CF updates, possible error you may experience applying update in CF Admin

If you apply the update in the CF Admin and find that CF starts but the admin and your code fail (such as with a 500 error, or perhaps in more detail starting with "java.lang.NullPointerException" or other errant behaviors), this may be due to a problem that can be solved. Read on.

I had written back in October about a problem folks could hit (which I first found in July) when applying CF updates via the CF Admin. The issue happened if you had updated the java underlying CF to a version released in July 2023 or later (that's update 11.0.20 or later for CF2021, or 17.0.8 or later for CF2023). I explained in that Oct post how you would need to run the CF update from the command line, adding a needed new JVM argument (offered by Oracle).

I shared then also how Adobe planned to resolve the problem for us, with the "next update"--and that would be this update. I can report that it seems that problem is solved--at least if you are on the most recent CF updates (CF2021 u11 and CF2023 u5) before applying THIS update. The update will work fine from within the CF Admin. If you are still on update CF2021 update 10 or earlier (not 11) or CF2023 update 4 or earlier (not 5), then you may still got the failure (where CF started but the admin would not load and requests failed, as discussed more in that Oct post). It seems that (even though the CF updates are cumulative), there's something about skipping the last update that seems to still allow the problem to happen. I've not seen any clarification from Adobe.

Again, if this hits you, the simple solution is to just run the CF update from the command line, with a special JVM arg (no need to "uninstall" the current update, as it failed). See the post from October for details.

Particulars about this latest update

Now, on to the specifics of this update. Before I get to that one really important issue, this update addresses still otehr matters, which may be important to understand.

Other changes besides the scope search issue

If you view the technotes for the update to either CF2023 or CF2021, you will see that it's got its own table of contents, covering a few other issues. I'll leave you to read about them, but they include:

• Changes to prevent unauthorized file access using cfdocument
• A change about what file uploads are blocked by default
• Upgrades to certain libraries (especially an update to Tomcat 9.0.85, but there are still others)
• And the deletion of certain old, no longer used folders

Again, see the update technote for whichever CF version you're on, for more details (the details are essentially the same, but it's why I can't link to any one document here.)

Important change to CF behavior of searching through certain scopes implicitly

Now finally let's move on to the very important (and fundamental) change in how CFML processes variables, with regard to searching for scopes when no scope is indicated on a variable name (at least in many cases)

This update changes CF's default behavior for an application setting called searchimplicitscopes. While that setting was introduced in CF2016, it has defaulted ever since to true (it was introduced then as way to get a performance benefit by setting it to false, to save time looking up certain implicit scopes--which required that you identify such scopes (more on "what scopes" below).

This update changes the default of that to false--now requiring that we identify such scopes, where needed (see below). This is almost certainly a BREAKING change in many CF apps--and it's a change Adobe has implemented for the sake of security, it seems. For more on that, see the technote. For more on what apps might break, see more below.

Again, there's much more to the update beyond this one issue, so again READ the update technote. But I call this issue out here as it's likely to be of most concern to folks.

What code with "unscoped variables" might break? Not ALL, but some (perhaps much)¹

It may help some readers to offer a more concrete example and summary of things.

Let's say that you ran a request with only these representative (but admittedly contrived) lines of code:

First, assuming you have searchimplicitscopes is true (either by default or via configuration), this code will "work" and produce "bob" as the output. Even though there's no prefix for fname, CF looks in first scopes local to the request and then "implicitly" searches those other scopes, like form, url, cgi, etc. (More on that in the next section.)

But if searchimplicitscopes were false (either by default or via configuration), this code would generate an error, saying:

(See more below and a July follow-up post linked there, where I discuss a "patch" Adobe offered, where you can setup to get a new log that tracking when such code does "work"--because searchimplicitscopes is true--and the code finds variables implicitly in those "other" scopes.)

To be clear, it's NOT as simple as some may read it: that "any code using non-scoped variables" will break. (In fact, the technotes for the update, linked to above, even make this mistake, which I've pointed out to Adobe.)

For example, this simple example WOULD continue to work:

Why? Let me elaborate of what scopes ARE and are NOT affected by this change.

What are the affected scopes ("local to" and "outside of" the request)?

So if you have code that uses unscoped variables, which will continue to work (because it finds the scopes "local to the request"), and which will fail (because it tries to find the scope "outside of the request"?

From my testing so far, these are the scopes "local to the request" where an unscoped variable will still work, even with this change:

• variables
• local
• query
• arguments

On the other hand, here are the scopes "outside of the request" which an unscoped variable will NO LONGER search (if searchimplicitscopes is false, by default or by configuration):

• cgi
• url
• form
• cookie
• file
• client

I have found this list both from the CF docs on implicit searching and through my own testing.

Pete Freitag also has a helpful discussion and examples (along with a discussion of why this implicit scope search can be a problem) in his security guide on this topic which he called, "scope injection".

Pete has also come out with a blog post on this recent update, and in it he offers still another example of the scope injection problem addressed by this change. Finally, he's also now updated his Fixinator tool to optionally search for unscoped variables.¹

Three ways to address the change in implicit scope searching

If you DO have apps that WOULD break, there are three available solutions to the problem. The first is the more "secure", while the other two help with "compatibility"--at the cost of security". You can either:

• change your code (to scope variables as needed--again, see above how not ALL unscoped variables need to change)
• consider changing your application.cfc or cfm to enable searchimplicitscopes=TRUE (which opens you to the security concern this change is trying to protect against)
• change ALL CF processing by adding instead a JVM argument to CF's startup
  -Dcoldfusion.searchimplicitscopes=true
  (which also opens you to the security concern this change is trying to protect against)

These are discussed further in the technote. And note that the new JVM arg will NOT be supported in the next and future releases, so you will NOT be able to rely on that 3rd option beyond CF2023. You will instead need to consider either of the first two options.

As for that second option, so far it does NOT seem that Adobe plans to change whether that works beyond CF2023--but again there are reasons you should be careful about enabling it, as I discuss further below.¹

(I'm just a messenger here. I have nothing to do with the change or how it was implemented. I just help people solve problems, and this is going to be one for many as they deal with it, and for a long time to come as they move to CF2023 and later releases in the future.)

As for implementing that 3rd option, I want to stress as always that you be VERY careful when adding such a JVM arg to CF's startup (whether in the CF admin or in the jvm.config file which it modifies). It should be added to what is the single line of jvm args, not as a new line. And don't forget the opening dash, nor fail to leave a space between this new arg and any before or after it. Indeed, I would recommend you save a copy of your jvm.config file (found in your CF instance's cfusion/bin folder, or instancename/bin for those running multiple instances.) If you make a mistake and CF won't start, you won't be able to correct the mistake in the CF Admin.

You don't NEED to wait for the update, to start testing for this impact

Here's more good news: you need not wait for applying this update to determine such things as what may break, and whether the second fix above may suffice.

Again, the searchimplicitscopes was added as an app-level configurable setting in CF2016. So you could create a test app in which you set as a property in the this scope of your application.cfc:

Or if using application.cfm, you can set this on your cfapplication tag, as in:

After making the change, then test such sample code (or of course, you could just change this setting in your existing apps to test its impact on those apps). this way, you'll know what WOULD happen if you moved to this update (which changes the default for that), or you could leave the change in place (as the application-level setting is honored, even after the update).

When I create my post with samples, I'll more clearly demonstrate doing that. But I hope that what I've shared so far may be enough to help most folks.

Feature added by Adobe a month later, to help identify code that would fail¹

In the weeks after this update was released, Adobe came out with a helpful "patch" providing an optional means to cause logging of code that would fail if the implicitscopesearch change (that's made the default in this update) was implemented. Some good news is that you can use that after applying this or subsequent updates (where you might use the above options to revert the behavior), but even better you can apply it BEFORE even attempting this or subsequent updates.

Adobe's technote about the "patch" is a bit spartan, so I have created a blog post discussing it in more detail.

Implications of using searchimplicitscopes=true¹

As I noted above, changing searchimplicitscopes to TRUE will revert CF to the default it was using before this update--but in doing that workaround, you are opening yourself to the very issue that this change is trying to protect you against.

It's a lot to keep track of, I appreciate. And perhaps there will be more info offered by Adobe or others (or myself), but for now let me say at least that with CF allowing search of implicit scopes, your cf code referring to variables without a scope causes CF to need to "find" whatever scope that variable is in. Again, prior to this update, CF searched through ALL the scopes shown above in both lists. And after this change CF BY DEFAULT no longer searches through the scopes in the second list.

What's the problem with CF searching through those other scopes? If you have unscoped variables, and they're not resolved by (found in) a search of those first scopes (variables, local, query, arguments--all local to your request), then if CF is allowed to proceed to seeking to resolve the variable in those other scopes, those could be manipulated from the outside (cgi, url, form, cookie, file, client).

So if you change this searchimplicitscopes to true, then with regard to wherever you have unscoped variables, you're telling CF to again let it search through that second set of scopes. The safer choice is to change your code to NAME the scope you want to use, then there's no longer ANY implicit searching.

If you leave it as false (this new default), then CF won't search through that second list. That's the security aspect of this change.

If I set searchimplicitscopes=true, am I opening myself to the 'Arbitrary file system read' CVE?¹

Finally, some may reasonably wonder, "would setting this to true open me to the 'Arbitrary file system read' CVE that is indicated in the APSB/security bulletin?" Naturally, if it would, that would be ANOTHER concern.

For now I can at least report (newly since I created this post) that Adobe has clarified (in a comment in their forum thread) that this change regarding implicit scope searching is NOT related to that security issue. Here's the key point:

The vulnerability "Arbitrary file system read" that you see in the bulletin is different from the one in Implicit searching of unscoped variables.

But you should read the full comment for context.

All that said, don't just think you're therefore "safe to set searchimplicitscopes=true". See the previous section here for more on the implications of making that choice.

Possible ongoing impact of this scope search default change for years to come

Before wrapping up, I do want to reiterate that point above about the 3rd of those three possible solutions: the jvm arg. Note again that Adobe WILL NOT be supporting that in future releases after CF2023.

That means that people who move to that release and beyond (or even now to CF2023 or CF2021, with these updates applied) will experience this breaking change--and their migration efforts may be seriously hampered, even though this is indeed a change for the better, from a security perspective.

We in the CF support community will have to point out this information literally for years to come. That's another reason I'm spelling things out in detail here and the other post with examples that I plan to do.

What about folks using Lucee?¹

Those using Lucee may wonder how this matter is addressed there. Actually, by default they're in the same situation as CF had always been--and there's provision to change things similar to in CF.

First, note that Lucee refers to the concept (indeed, Railo referred to it originally) as "scope cascading", and there's a setting to control it on the Lucee Admin, under the "Scopes" link within "Settings", where it shows as a setting called simply "Cascading", with values of "strict", "small", and "standard" (explained there). The default is "standard", so that again it runs the same way CF always did--and you can change it there if you like.

And while CF has had the app-level searchimplicitscopes setting (since CF2016), there's no setting in the CF Admin to control it. As such, the Lucee Server admin-level change would be similar to (and easier to use than) the JVM-arg approach CF added with this update.

Finally, Lucee also offers their own app-level setting for this, called scopeCascading, as might be set in an application.cfc as: this.scopeCascading = "standard". Again, this is a reflection of that capability being introduced in Lucee's predecessor, Railo--as can be seen in any docs online for Railo, such as here.

Anyway, the current Lucee docs clarify how they do support the "newer" searchimplicitscopes app-level setting (again, "new" since CF2016) and Lucee regard that to be an 'alias to the attribute "scopecascading", in that they describe searchimplicitscopes being an "alias [which] takes a boolean value where true is equal to "standard" and false is equal to "strict" scope cascading mode.'

So someone setting searchimplicitscopes at the app level in CFML will get the same resulting behavior in CF or Lucee. But only CF has (for now) changed the default to be more strict. So this whole discussion raising the concern about unexpected scope search vulnerabilities is indeed a topic worth considering for Lucee folks, though it's not a"new" one.

On getting help with the update(s)

Finally, if you may want help with considering, installing, or troubleshooting anything related to these updates (or indeed anything related to CF), I'm available for online remote consulting. More at carehart.org/consulting. Or you can certainly reach out to the CF community (I list several of the online CF communities here.)

¹ (Where I use this footnote "1" above on some paragraphs or sections, it's to indicate that's new content I've added or updated since the original posting. I'm doing this to help those who may have read the post originally and have come back to view it again. BTW, if you clicked the link for the footnote indicator to bring you here, note that you should be able to just hit the back button in your browser (or click here) to return to where you clicked that link. :-)

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed