[Looking for Charlie's main web site?]

Updates released for ColdFusion 2023/2021, today June 11 2024, and another possible breaking change

This is another important heads-up for my readers: there was an important security update released today by Adobe for ColdFusion 2023 (its update 8) and ColdFusion 2021 (its update 14). Just like the recent updates in March, this one again has a potential breaking change (trading away compatibility for the sake of security), and it adds yet another JVM arg that allows you to "revert" to the previous default behavior--to let you benefit from OTHER security aspects of the update, while you give time to addressing what should be changed.

In this case, it's about if you use CF encryption-related functions, the default encryption algorithm is changing--and that means that those who encrypt/decrypt (or hash or randomize) data in their apps MUST take steps before applying this updates. For more, read on.

Please don't apply the update before reading the update technote

Please folks: it's imperative that you read the technote before applying the update: (this one if you're on CF2023 and this one if you're on CF2021).

These technotes explain important details related to the update, and especially about this security change.

Other thoughts

Besides the helpful detail in the technote, as far as trying to determine whether this change will impact your apps, consider that you could use a search tool (or multi-file search capability in your editor) to look for occurrences of the affected functions across your code base. These are encrypt, encryptbinary, decrypt, decryptbinary, hash, rand, randomize, and randrange. You can search for just these 4 strings:

  • encrypt (which will also find occurrences of encryptbinary)
  • decrypt (which will also find occurrences of decryptbinary)
  • hash
  • rand (which will also find occurrences of randomize and randrange)

Granted, sometimes you will find references to these strings that are NOT about the CFML functions with those names, or which may be commented out. You'll need to assess them, but it really may not take long given that these might be used rather infrequently, if at all.

Finally, the key thing to look for (if you DO find these as existing CFML functions in use) is whether the functions DO or DO NOT specify the argument for the encryption algorithm. See the technotes as well as their links to the CFML Reference for each function, to know what argument would specify the algorithm.

Again, the key to the update's change only affects code where you DO NOT specify the algorithm, in which case the default is changing per this update.

For many people, the "simple solution" may be to use the available JVM arg to revert the default (see the technote), which will no longer work starting with CF2025. The next simplest solution would be to change such code to specify "cfmx_compat" as the algorithm, wherever they don't specify any (again, trading compatibility for security, but more targeted). See the technote for more on these options.

And follow the useful Adobe community forum message announcing the update

Also, there's (as always) a useful Adobe community forum message announcing the update, but note that it does not (currently) offer the level of detail about the issue that the technote does.

You should also keep an eye on that forum thread as there will surely be more discussion of this update there.

Indeed, you'll see I've already added the first comment there, pointing out this matter that the technotes currently offer important detail that that forum message does not.

Then I also ask there for confirmation that this has nothing to do with passwords stored/encrypted and retrieved/decrypted by the ColdFusion Admin itself. See my comment for more. I look forward to folks offering clarification there.

Finally, I explain there why I am unable to test this new update (as I normally would, before writing this sort of post), because I am traveling and just have time to have gotten that note and this blog post out. I will update things as warranted. If I add anything substantial, I'll both mark it clearly as an update here and will point it out in a comment--for the sake of those who read this before I would offer such an update.

Update: beware a breaking typo in the technote

As an update since my original post, I want to share word of a breaking typo in the technote (at least as I write, 2 days after the release of the update). [Subsequent update: Adobe did soon fix the problem. I leave the next couple of paragraphs, for context]

Where they offer the JVM arg (for reverting the behavior), they mistakenly have a space before the "=", which if you implement it (with that space) in your JVM args for CF will keep it from starting! The arg (if used, such as to set to TRUE) should be:


The mistaken space before the "=" is also in the forum post from Adobe below. I have raised both concerns there, so perhaps in time this will be addressed by Adobe in both places. Until then, I wanted to get this word out.

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 ColdFusion, or Lucee), I'm available for online remote consulting (though with restricted hours this week while I'm in Germany, Jun 11-16). More at carehart.org/consulting.

Or you can certainly reach out to the CF community for help (I list several of the online CF communities here.)

For more content like this from Charlie Arehart: 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
An update since the original post: someone kindly informed me (directly, rather than as a comment here) that the technote has a mistake, where it has a space before the "=" in the assignment for the JVM arg. And if you don't remove that, CF won't start if you use it that way!

So I've added an update to my post above about this.

And if you are the person who sent me word, please send it again. It was early in my day here at cfcamp in Germany, and I can't recall how you had sent it. I looked through several places before writing this! :-)
I am doing an upgrade from 2016 and Migration wizard brought over datasources just fine. I upgraded to CF2023 update 8 added the Compat jvm arg, restarted the service, but the DSNs will not validate until I rekey the password. CF throws the below error. so it seems like the argument is not working unless I am missing something.

Error below:
errorError editing/creating this dsn (dsn-name)
An error occurred while trying to encrypt or decrypt your input string: Given final block not properly padded. Such issues can arise if a bad key is used during decryption..
# Posted By Mike Collins | 6/14/24 10:13 AM
In reading the security bulletin and other info related to this update, I understood the change to be that CFMX_COMPAT would simply no longer be the default encryption algorithm. I presumed if the optional algorithm parameter was supplied that the encrytion would still work without setting the JVM argument -Dcoldfusion.encryption.useCFMX_COMPATAsDefault=TRUE in the ColdFusion Administrator. For example. where local.algorithm is set to "CFMX_COMPAT" :

    local.result = encrypt(arguments.fromString, getKey(arguments.algorithm), local.algorithm, local.encoding );

However, that does not appear to be the case. The encryption actually works, but not without the "...error occurred while trying to encrypt or decrypt your input string: '' Can not decode string..." warning.

Has anyone else encountered this?
# Posted By Vicki | 7/9/24 10:17 AM
Vicki, things do indeed work the way the technote indicates. If you're finding otherwise, I would suggest you confirm that your "local.algorithm" variable does have the value you think it does. :-)

But more specifically, here is code that will demonstrate that things work if (as you propose) one DOES set the 3rd arg (for encrypt or decrypt) to "cfmx_compat", and this works whether you set the jvm arg true or false or if you leave it off. Notice how my code outputs whether that's so, as well as the CF version and update level.

msg="test msg"
writeoutput("Message to encrypt:" & msg & '<hr>')
encryptedMsg = encrypt(msg,key, algo)

decryptedMsg = decrypt(encryptedMsg,key, algo)
writeoutput("Decrypted message:" & decryptedMsg & "<hr>")

writeoutput("CF version: " & server.coldfusion.productversion & "<hr>")
writeOutput("JVM arg -Dcoldfusion.encryption.useCFMX_COMPATAsDefault")
if (not structKeyExists(server.system.properties,"coldfusion.encryption.useCFMX_COMPATAsDefault")) {
writeoutput(" <u>is not set</u>")
else {
writeoutput("=" & server.system.properties["coldfusion.encryption.useCFMX_COMPATAsDefault"])

Please let us know how things go.
Thanks, Charlie, as always. I have determined that what I originally assumed and what you stated is, of course, true. I also had already confirmed my "local.algorithm" variable had the value I expected. In the end, I believe the issue I experienced was a caching issue! In any event, all is good in my world now. Thank you most kindly for your assistance!
# Posted By Vicki | 7/12/24 10:00 AM
Good to hear, and as some would say, indeed "both things can be true". :-)
Right on!
# Posted By Vicki | 7/12/24 11:42 AM
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting