I've complained about this, before..

[WolfShade]

I forget what update broke CF Server.  The one where if any variable in any scope is passed to a CFC function, but it's not in the CFARGUMENTS at the very start of the function, then CF throws an exception.

I have a .cfc, let's call it "myFunction.cfc", where there is a function that adds a calendar event to a very rudimentary calendar for users to view.  In calling that function via AJaX, I have appended some URL parameters.

myFunction.cfc?method=addrecord&returnformat=plain&returntype=plain

Someone just tried to enter an event into the calendar.  CF Server sent us an email:

Diagnostics:  Function addrecord does not support returntype as an argument in X:\path\to\myFunction.cfc

The error occured on line -1

...

Template: /path/to/myFunction.cfc

Query String:  method=addrecord&returnformat=plain&returntype=plain

returntype is an instruction to the function, not a value being processed by the function.

Why did Adobe break this?

WolfShade

[Charlie Arehart]

Wolf, first it was the May 2025 updates that are leading to your error.

But the problem is actually more due to a mistaken assumption this change uncovers: using returntype as a querystring/url var was never doing what it seems that code expected. It was NOT "changing" the returntype (like you CAN do with that returnFormat querystring value). Instead, it was simply coming into your CFC method as an "available" argument. CF never used it, and you never used it (didn't define it as an arg), and THAT is why the update has led to this failure.

I'll elaborate, and I can also offer 2 workarounds.

1) First, this would affect those on at least cf2025 update 2, cf2023 update 14, or cf2021 update 20. Those are the updates from May 2025. And it was in those updates that Adobe changed the behavior (adding a protection for us) that required that any arg coming into a remote CFC function/method must be DEFINED as an expected incoming argument. 

2) Next, here's the "good news" of an available workaround. In the technotes of each of those is an explanation that if for this problem, showing that you can add a JVM argument for the CF startup which undoes this "protection":

-Dcoldfusion.runtime.remotemethod.matchArguments=false

FWIW, I discuss that and the whole issue (the changed behavior) in my blog post on the May updates, specifcally in this section on what changed.

3) And you can prove for yourself that what I propose above is what's happening (that the returntype you're passing in whas simply being converted into an incoming argument) by adding to the CFC method either a cfdump of the arguments scope or (if you have the method set to not produce output) you can use cflog/writelog to show the value of  structkeylist(arguments). You will see that the returntype is there--but the returnformat is not. Again, CF honors and uses that returnformat for itself (controlling what format to use to return via http whatever the method returns). 

And for good measure, I did that test not only on a later CF version (running with this jvm argument above), but I also did it on CF11 (which you mentioned elsewhere today that you were using in the past. Since CF2018 and earlier don't get updates, they did not get this changed behavior.) Again, it simply showed the returntype being a variable in the arguments scope. (Maybe there was a time in the past when returntype DID do something, but again it was not doing it in at least cf11.)

4) So it would appear that CF has simply been "ignoring" anyone specifying that returntype querystring (unless they did somehow define and use it in the method). And now the recent updates are "protecting" people against ANY such arguments that were previously "ignored" this way (they were simply passed into the method--which could cause them to somehow led to security issues, thus this change by Adobe and identified with a cvv in the APSB for the update. My guess is that this allowed callers to a method to potentially change values of variables--when the coder of the method never expected something "from the outside" could cause that.)

5) Finally, if you didn't want to use the JVM arg (and didn't want to remove the use of the returntype in the querystring--or were concerned about url's "out in the wild" that may come back to your server passing that in), the second workaround for you would be to simply add a definition of that returntype to whatever methods where you want to "allow" it to be passed in.

You could use cfargument for tags or add it in the parens for a script-based function, of course. And you ought to set a default--because you may have requests that call the method WITHOUT passing it in.

6) But really, as I said from the start, all this has simply uncovered a mistaken assumption that that returntype being passed in on the querystring was doing anything. It was not...and with the May updates that's being rejected (just like would happen to ANY argument passed in that was not "expected" by the function).

Security fixes often cause compatibilty issues with old code...which may do things that are surprisingly dangerous. Or in this case, just not doing what we thought. Time marches on, as does CF. You can do one of the workarounds. Just don't let this keep you from updating....because the updates march on as well, and you can't do later ones without getting the "benefit" of these previous ones.

Again, they offer the jvm arg as a way to "just stop the madness", for those who feel they must trade for increased compatibility over the potential security protections.

Hope that helps.