Skip to main content
B
brcesars
Participant
June 5, 2025
Question

JVM FLAG -Dcoldfusion.runtime.remotemethod.matchArguments

  • June 5, 2025
  • 1 reply
  • 511 views

In ColdFusion 2021 update 20 (as well as cf2023 update 14 and cf2025 update 2), there was a change in access to remote CFC methods, requiring explicit cfarguments tags or defining them directly in the function signature.

 

The -Dcoldfusion.runtime.remotemethod.matchArguments flag set to false allows methods with remote access to continue working without restriction on argument matching.

 

Making all methods compatible with remote access in our programs will be quite complex and will require a long development and testing time on the systems. Since we seek the integrity of our methods by other means, set the flag to false solves our problem.

 

So I would like to know if this JVM flag will be deprecated in the future? If it is something permanent, we will set it to false and dispense with any rework with the compatibility of remote CFC methods.

    1 reply

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    June 5, 2025

    There's been no indication that it will "go away". Those added last year that were to "go away" (in cf2025) did indicate that. But I realize you'll want to hear from Adobe. They may or may not reply to you here.

     

    As for that meaning you can "dispense with any rework", you do that at your own risk...at least in that Adobe didn't add this change cavalierly, just to piss people off and make their lives difficult (despite what antagonists may assert). They did it to protect us against a known vulnerability...though we have no more info than what they say in the apsb for the update. It's not clear if this is a vuln that affects just our own code (where we may see no vuln) or something Adobe implements (where we may not readily realize the risk to us). 

     

    That said, the apsb does (for now) say that there are no known exploits in the wild. So can we just do that jvm arg and call it a day? Well, it comes with a risk (as yet undefined), so it's not something that WE should do cavalierly...though we can do it judiciously and with due caution. 🙂 And perhaps in time we'll learn more about what is the real risk to beware. 

    /Charlie (troubleshooter, carehart. org)
      B
      brcesarsAuthor
      Participant
      June 5, 2025

      Thanks, Charlie!!

        Charlie Arehart
        Community Expert
        Charlie ArehartCommunity Expert
        Community Expert
        June 6, 2025

        Glad to help, and hope we may indeed learn more in time.

         

        I'll add that the real pain about this change (for many) is that they're encountering the error regarding vars they're not even passing in directly (to such remote methods). Instead, it's turned out that Cf has always passed into such remote methods ANY url or form fields that may be defined in the flow of the request. Once can dump the arguments scope to see that happen even in earlier cf releases (assuming you're calling a remote method and have some url or form fields defined, including via cfset, cfparam, and more).

         

        The challenge with these is that it's not easy to know WHAT such vars may exist, to add them as defined arguments. And worse, your method may not even USE them, so defining them as args can seem all the more awkward and even counter-productive.

         

        But after this May CF update, such will lead to errors, which forces many to consider using that jvm arg to "stop the madness"....which then leads to your reasonable question.

         

        This is discussed some in my blog post about the update from that day, including someone sharing that they'd opened a tracker bugs report on the matter. 

         

        Something I've been wondering is whether Adobe might do for this what they did last year, when they came out in April with a patch to help with a similar challenge regarding the March update. That's the one that stopped CF from searching implicitly into several scopes if none was defined for a variable.

         

        The "patch" (a jar), if added to your cf, would cause it to now LOG whenever such implicit scope searching was done--assuming you'd added the jvm arg to allow that again--which helped you FIND when it was happening. The log entry named the template and bar name in question (though sadly not the line number in your template).

         

        Anyway, I'm saying that such a patch would help for this problem as well. I'll go add this now as a suggestion on that tracker ticket, if no one else yet has. Sadly, this update (like that one last year) will be tripping people up for weeks, months, and even years to come as they move from earlier updates (or earlier cf versions) to this update (or later cf versions). 

        /Charlie (troubleshooter, carehart. org)
          Terms & ConditionsAccessibility statement
          Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices