Announcing ColdFusion updates released May 13 2025: p1 security update (and more)
An update for ColdFusion has been released today, May 13, 2025, for both cf2025 (update 2), cf2023 (update 14) and cf2021 (update 20). In brief, it addresses a P1 (Priority 1, "Critical") security vulnerability, as indicated in the associated ASPB (security bulletin) for the update.
The update also incorporates potentially breaking changes (with Adobe trading compatibility for security), while it also includes configurable options to undo those changes (if you prefer to trade away security for compatibility). Finally, the update corrects some issues introduced in the previous updates, released in April.
In this post, I share the details about the update (from Adobe and from others). I can report I have installed both updates on multiple machines and operating systems without incident. As for challenges or lessons learned, I may do a follow-up post as I/we all learn more.
For more details, read on.
If you have a remote function that you call with cfajaxproxy and you have a cfparam tag with a URL variable in Application.cfm it will try and pass the variable as an argument to the function and error out.
Application.cfm
**************************
<cfparam name="URL.WindowType" default="Screen">
test.cfm
**************************
<cfajaxproxy cfc="proxy" jsclassname="testproxy">
<!--- the following should be a "script" tag, but the blog's XSS protection converts it to "invalidtag"--->
<InvalidTag>
var ColdFusionProxy = new testproxy();
var TestDate = ColdFusionProxy.getDate();
document.write(TestDate);
</script>
proxy.cfc
**************************
<cfcomponent displayname="proxy" output="false">
<cffunction name="getDate" access="remote" returntype="date" output="false"
hint="Returns the current date and time">
<cfreturn Now()>
</cffunction>
</cfcomponent>
The error I get is:
"Function getDate does not support WINDOWTYPE as an argument in in C:\inetpub\wwwroot\proxy.cfc"
Removing the cfparam tag works around the issue.
1) So first, this is being caused by the change above (first bullet under "what's changed") regarding how remote methods now cannot (by default) be called with *arguments which are not defined in the method*. I realize you could reasonably assert: that url var is "not an argument you're passing in". What's happening is that this is somehow how cfajaxproxy works under the covers.
In fact, it's not simply about that URL var being defined in the application.cfm. It would happen as well if ANY url vars were defined in the request. It turns out that the call made to CF (via cfajaxproxy) does pass in ANY such url vars (defined in the request) as args. That's not "new" with this update.
And you can prove this is what's happening, by changing your method to have it return the keys in the arguments scope (and remove the returntype="date"):
<cffunction name="getDate" access="remote">
<cfargument name="WINDOWTYPE">
<cfreturn structkeylist(arguments)>
</cffunction>
Now when you call your test page, the output would (before this update, or with workarounds I'll show) now show whatever is passed into that method: and your URL var will be there (and you'll see a couple others that Adobe prefixes with _, which it seems to allow/handle specially.)
2) So as for workarounds, there are a couple of others beside yours:
a) You could simply define that url var as an expected arg to the function, adding this:
<cfargument name="windowtype">
That seems most reasonable, since you ARE in fact wanting to define/use that windowtype var in your app.cfm. Again, I get that you did not EXPECT that CF would do that, but now we know it does. (I suspect they would not, as a "fix", just "allow ANY URL vars" to be passed in instead, as that would defeat the purpose of the protection this update is adding (for more generic reasons, well beyond just calls from cfajaxproxy).
b) The other workaround is to do what the blog post above (and the update technote) indicates: you can have CF revert this change in behavior entirely using the JVM arg -Dcoldfusion.runtime.remotemethod.matchArguments=false , which would remove the new protection for ALL remote method calls. If you put that in your CF jvm args and restart CF and test your app, you'll see it works as-is, no change required.
Let me know what you think. And thanks for sharing the observation. I'm sure others could indeed be caught out by it.
But I should also add that you could always email [email protected], which is free support for install issue, and we could assert that update problems are essentially install issues. Some also use [email protected].
I will add both those to the blog post, and I will also add a mention of this cfajaxproxy matter in that first bullet point under "what's changed".
As the saying goes, "I do it for the kids". :-)