Inspiring

Question

CF Enterprise 2021 bytecode execution error in Administrator

Forum|Forum|4 months ago
October 10, 2025
2 replies
285 views

I understand that bytecode execution limitations were introduced with the Hotfixes earlier this year (2025), but I am suddenly running into new problems with this. I have recently been trying to implement CF Enterprise 2021 Hotfix 22 over a successful install of Hotfix 21, and I have got it working on a local instance of Tomcat for Windows. However, when I move the WAR file to Tomcat on Azure, I run into this error opening the Administrator:

"ColdFusion, by default, disables the execution of bytecode in .cfm and .cfc files. To enable it, open the JVM.config file, and set -Dcoldfusion.compiler.block.bytecode=false or add path: (here it lists the path to my CF Admin)/CFIDE/adminapi/security.cfc to bytecodeexecutionpaths key of root/lib/pathfilter.json"

I don't get this error locally. I've tried adding the path to pathfilter.json, and even to pathfinder.txt when that didn't work, and restarting the service. The error has persisted, and I can't get into the Administrator.

Obviously since this is CF Enterprise, there is no jvm.config file to edit, so I've added the flag to the Tomcat environment variable CATALINA_OPTS -- this works, but I didn't really want to remove the block completely. I just wanted to get ColdFusion to trust its own bytecode...!!!

Can anyone help me figure out what I'm doing wrong? When I add the path in the JSON file, I'm verifying & copying it directly from the error message, enclosing it in double-quotes, terminating with a semicolon, and using forward slashes. I have tried using the wildcard notation to allow all the files in the adminapi directory. I have restarted after each change. I have even tried taking the JSON file's Comments field literally and enclosing the path in {}s. It doesn't help. Oh -- and I guess I should mention everything is working fine on Hotfix 21 without any edits at all.

Thanks for reading! Any help would be greatly appreciated.

Charlie Arehart

Community Expert

@wtlaughlin, any update on things?

/Charlie (troubleshooter, carehart. org)

W

wtlaughlinAuthor

Inspiring

I've had to simply rely on the environment variable for now while I look into other, more serious problems with our deployments... however, from Brian__'s answer, I get the impression that this will probably be enough. Once I have confirmed that with some of the admins and security folks, I will let you know. Thanks!

Charlie Arehart

Community Expert

WT, while I can't explain why it acts differently by default on Azure, the solution should either be that jvm arg or that pathfilter.json. And either should work, of course.

1) Taking the second first, is the Azure platform running Windows or Linux? If Windows, note that like Java it does indeed require use of either forward slashes or two backslashes. (It can't be what Windows normally uses, one backlash.) It also requires the case of the folder and filename to be exact, including the drive letter. Can you confirm all that's so, per the folder structure (rather than relying solely on the error message)?

2) Also, are you editing that pathfilter.json file as you found it-- existing already--in the same folder as the various neo-*. xml files? That's critical. If instead you created it and PUT it somewhere you thought would be right, that may be why it's being ignored.

3) Finally, as for the jvm arg, while you're concerned to want to avoid its use if possible, note that CF has allowed such precompiled code for over 20 years. While there's SOME risk of unexpected code getting on your server, that's not really unique to precompiled code. If someone could put even normal cfml source code on the server, that would be just as worrisome.

So relying on the arg wouldn't be something one should be TERRIBLY concerned about, just mildly so--in my opinion, at least, which I share if you find neither points 1 or 2 help, or if no one else offers a better explanation.

Let us know if you give those a shot.

/Charlie (troubleshooter, carehart. org)

W

wtlaughlinAuthor

Inspiring

Thanks, Charlie. To answer your questions:

1. It's Windows. I've tried every permutation of path string, since the instructions weren't terribly clear on the syntax to use. I've just gone in and tried forward or double-backslashes again, just to be certain, and without the JVM arg it does not allow me access. I didn't know the system required case sensitivity down to the drive-letter, but the case seems to be correct for the whole path.

2. Yes, I am only editing the file found in the cfusion/lib directory, where the various xml config files are located. Previously the path value was empty.

3. I think I am going to have to rely on the JVM arg; it's just that in my environment I have to account for even low-risk vulnerabilities, and if possible I'd like to choose the most restrictive option.

The weirdest thing for me is the fact that even though this restriction has been in place for several Hotfixes past, it's only showing up now, and only on the Azure system. Then again, Azure's Tomcat instance has also suddenly stopped extracting WAR files, so it may be that there are some new security settings that have been added to Azure that are forcing this behavior. I just don't know. Anyway, thanks for the suggestions!

Brian__

Participating Frequently

Hi @wtlaughlin -- sharing a few questions and thouights, In case you're still investigating this.

1) Are you trying to access the main CFAdmin login page (something like http://server:8500/CFIDE/administrator/) or something else, like a direct Admin API URL? Does the error message always indicate {...}/CFIDE/adminapi/security.cfc or did the specific .cfm or .cfc file shown ever change as you tweaked your pathfilter.json? I can reproduce where I get another file indicated, but not security.cfc.

2) I'm wondering about your commnets "Obviously since this is CF Enterprise, there is no jvm.config file to edit" and "Then again, Azure's Tomcat instance has also suddenly stopped extracting WAR files". I'm not really familiar with Tomcat and WAR deployments, so this may be a silly question. But if the WAR isn't being extracted, are you able to edit the correct pathfilter.json file? Maybe even doing a quick test like dropping a CFML (not compiled) .cfm file in your /CFIDE/ directory and making sure that it's the correct/expected path being used.

3) If your CFAdmin (CFIDE) is in an unexpected path, you will get the "bytecode execution disabled" warning. I've seen that happen on some version of Commandbox, but it seems to be worked out now. But if you do need to allow CFAdmin, you'll want to use the "**" wildcard in the path in pathfilter.json, to allow subdirectories too, e.g., something like:

[... stuff above ...]
   "bytecodeexecutionpaths": "Z:\some\path\here\CFIDE\**",
[... stuff below ...]

You will need to restart ColdFusion each time you edit this file.

4) In terms of the risk of using the JVM arg to disable the setting globally, this vulnerability/control is really only significant if you're relying on Sandbox Seucutiy and/or are in a multi-tenant environment.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded