It's a great question, Dordrecht--and one that has long needed better clarification. It's indeed easy to be confused about it, beyond just what you asked. Let me elaborate.
I'm afraid it's not a simple answer, but you may find my points 1 and 2 sufficient for your question. 🙂 I hope the rest may help you or others seeking info on the matter. As you say, it's been hard to come by.
1) First, yes this is about whether CF can execute java bytecode stored within cfml files. Traditionally that's been enabled (precompiled) using the cfcompile script in cfusion/bin. Many never use it or don't know it exists. This is a mechanism that CF had for many releases where developers could precompile their CFML pages such that they remained a .cfm (or .cfc) file, but the CFML was converted to the unreadable java byte code. (You would be expected to have saved the "real" source in another folder, and precompile it to place it into the folder where your CFML files would normally be executed from.)
This was a form of "security by obscurity", but more important it was determined that it could be abused. Indeed, it's even possible for one to compile java bytecode and then PLACE it in a cfm or cfc file, and CF would run it. And the issue there is that such java bytecode would not be run through the samelow-level java classes that Adobe has in place for processing CFML code--such that, for example, if one used the CF Sandbox feature (another long-existing but generally little-used feature) to limit what tags could be executed in that CF instance (or limitable to a specific code directory), such bytecode could circumvent that protection. Is it something of grave concern?
Well, if someone can put untrusted code on your server that's already an issue. The bigger concern here is for those who ARE using that sandbox feature to limit what CFML code can do (such as perhaps shared hosting providers, but indeed anyone using the CF security sandbox feature).
For more on this, see the Brian Reilly's June 2025 post (on his "hoyahaxa" blog), specifically this post. The title may not readily connect that it's discussing this matter, but it is. And it does a very thorough job of explaining the issue. (Indeed, Brian is the one who found the vulnerability and reported it to Adobe. He waited a couple of months before posting the blog entry, in the hopes people would have applied the needed updates by then.)
1a) So indeed it has NOTHING to do with CF's execution of the bytecode which CF creates dynamically (when running a CF page for the first time after it's been created or edited). And to be clear, yes THAT bytecode is saved as .class files in the cfclasses folder--by default, as configurable in the CF Admin "caching" page and the "save class files" setting. But even if that settings is DISABLED, CF does still compile CFML to bytecode, which is then loaded into memory (the "template cache", which cannot be disabled). But again, that is NOT what this change was about (which is only about cfm/cfc files with bytecode). Those .class files in cfclasses are not affected at all, so you can relax regarding what seemed your primary concern here.
2) So as for the jvm arg and this vulnerability, a change was introduced in the April 2025 updates to 2023 (update 13) and 2021 (update 19)--and was already built into CF2025 (released in Feb 2025). Now by default (as of these updates to CF2023 or 2021--or as of CF2025 from its release), such bytecode in cfml files (precompiled templates) would NO LONGER be able to execute, by default: they are "blocked".
2a) And this is why the jvm arg exists, to "unblock" that default protection (changing it from TRUE to FALSE), for all files CF may process. This should not be done without considering the concern in Brian's post.
2b) And note that there is in fact a way to instead identify WHAT folders ARE allowed to hold (and let CF execute) such precompiled templates. More on that in a moment. Again, some developers use this feature--but they may use it only in some folders.
3) As an aside, the April 2025 update technotes for 2023 and 2021 only LISTED this new arg but didn't explain it at all. See for instance the update technote for CF2023 update 13: https://helpx.adobe.com/coldfusion/kb/coldfusion-2023-update-13.html. (Again, the change and arg was already IN CF2025 update before its update 1 that month.)
3a) Indeed, then in the May 2025 update technotes (for all 3 versions), Adobe explained that those April updates (all 3 versions) had introduced a new pathfilter.txt file (in cfusion/lib or [instance]/lib), which was the initial way you could DEFINE the path of files where you WOULD want CF to be able to execute such precompiled templates (to creates a "whitelist").
3b) BTW, this older pathfilter.txt is not to be confused with the serialfilter.txt and cfserialfilter.txt, which were introduced in still-earlier CF updates. More on them at https://helpx.adobe.com/coldfusion/kb/coldfusion-serialfilter-file.html.
4) And that May 2025 update technote ALSO clarified that that update was changing it to be a new pathfilter.json file instead (in the same folder) that was to be used for such whitelisting. The reason for the change was that now this file was controlling not just that behavior above but other behavior where CF was limiting what folders could be used for certain features. See that May 2025 technote (for your CF version) for more on that pathfilter.json file.
And to be clear, the file itself has comments that try to help you set it up: but I will warn that you need to be very careful about the paths specified in that file, for things to work as you'd expect. For example, the path is case-sensitve (even on Windows), including the drive letter. Also, the path separators must be specified as / rather than \, again even on Windows. Sadly, it leads to a lot of confusion.
4a) While we're on the topic of this pathfilter.json file, note that subsequent updates (including the one from Dec 2025) have added still MORE things whose files/folders that json file can whitelist (whether you could run encoded/encrypted templates, whether scheduled tasks can publish output as defined in the task, whether cf admin proves can create output, etc.)
5) Still ANOTHER concern to beware of about this pathfilter.json file (if you opt to use it for such whitelisting) is that, on subsequent updates (even as of the Dec 2025 update), if you have edited the file and apply an update, the update REPLACES the file with a default one that has NO whitelisting: you will lose what you have entered.
The technotes do indeed warn of this for the updates from July 2025, forward, suggesting that you to either make a copy BEFORE the update or noting how you can recover the content from the hf-updates folder for that update found in your cfusion or [instancename] folder), where there will be a folder for the update you applied, and within that is a "backup" folder, which will have the old version fo the file in its lib folder.
just beware: since an older update may have offered fewer options of what can be whitelisted than a later update, you should MERGE your old content into the new pathfilter.json file, rather than REPLACE it. The technotes are NOT clear about that.
6) One more thing on this jvm arg in particular that you ask about, I will note that another source of confusion on this is in fact a problem on the jvm args page discussing this and other new jvm args. For instance, in the page for the 2025 version of the args, it mistakenly indicates in the "description" column (the column header itself) the words:
"If true, the flag prevents ColdFusion from dynamically compiling CFML code into Java bytecode at runtime."
But then for this arg, the description column instead says:
"If true, the flag prevents ColdFusion from executing pre-compiled CFML code (Java bytecode) at runtime."
That first mistaken sentence leads to the sort of confusion you shared (about CF itself compiling code at runtime). Note that the second one instead makes it more clear that it's about this *PRE-COMPILED CFML code", which was the subject of that change in April (or in CF2025 in Feb).
i will raise that concern to Adobe to see if they can correct it.
7) While it's not discussed in the technotes, I'll share that there has been at least one other situation where you may need to use either the jvm arg (to disable the blocking of precompiled templates) or use the pathfilter.json--to allow whitelisting of files you wouldn't have precompiled yourself.
First note that the CF Admin itself does use such precompiled templates, as a way that Adobe discourages folks looking into the CFML code for the Admin. And they have indeed internally already whitelisted the needed CF Admin folder locations (CFIDE/administrator, CFIDE/adminapi, etc.)
But there have been situations where people found that their admin could not load, with it reporting the error about not being able to execute such precompiled code. My observation has been that this is either in deployment of CFML as WAR files (on JEE servers and servlet engines) or sometimes when using multiple instances (this is a feature for those on CF Enterprise or the Developer edition, where the CF Admin "Enterprise Manager" page allows creation of multiple instances). But I have NOT seen the problem ALWAYS happen with such newly created instance.
Anwyay, in those cases where the error occurs, again you could either use the JVM arg to disable the blocking of precompiled code, or add the path to the administrator folders (which will be named in the error) to the whitelist in the pathfilter.json file.
8 ) Finally (yes, finally!), your last question asked, "How might I determine whether there is any of this Java bytecode present in my (large, inherited) application?" Of course, you may no longer need to know since you might have been thinking of something else. But someone else reading this answer may well wonder, "how can I find files in our environment that might be such precompiled cfm or cfc files?"in anticipation of a planned implementation of the April 2025 updates or beyond for CF2023 or 2021 , or a move to CF2025.
There may be better ways, but I'll say that if you use any good file search tool or editor feature, look for files (with the filename pattern of *.cf*, for instance) which contain the text "sourcefile". That is a string (one of the few reliable ones) that would exist in such precompiled templates. They will be binary also, so if you open the file (in the result of the search) and its clear text, then that's a false positive (a file containing that word but NOT precompiled). It's not perfect, but it's better than nothing.
As Brian Reilly's blog post notes, you can also look for the hex string CAFEBABE appearing as the first characters of the file, if your search feature might support searching via hex strings. 🙂
9) So in summary, I know that was a VERY long answer to your question, but I hope you can appreciate that it's the lack of anything from Adobe or much from anyone else explaining all of it that indeed deserves this kind of discussion. I welcome feedback from you or anyone coming across this thread in the future. (And then I would like to create a blog post out of it. I have long meant to. For now I opted to write this here since you raised the great question.)
AdChoices