Sigh - Adobe - when you change something ... let us know. I spend almost a day trying to figure out WTF I broke in my environment and turns out it was you. Why would you make a change like this and then fail to mention it anywhere in the release notes? head desk https://www.hoyahaxa.com/2023/10/coldfusion-connectors-and-cfadmin.html

This sort of thing is why we stopped using the connectors well over a decade ago and switched to the built-in web server and Apache (or Nginx) in front with simple HTTP proxy: much more control and far fewer surprises. The built-in web server has been fine for production use for a long time -- especially since the switch to Tomcat which is definitely battle-tested -- and the HTTP proxy is plenty fast enough for production use.

@Mark Takata (Adobe) is there a work around planned for this? We've been handing this CFAdmin access issue ourselves just fine - why 'fix' this now? @seancorfield Thanks for that insight! I think most people continue to use the connector because like most things CF related 'it's always been done like that' but as you point out it might be a good time to reconsider options.

Jim, can you be more specific about what "work-around" you would want? At least some of the updates are specifically related to security issues being fixed, and any "work-around" to those would expose your server to known exploits. What exactly broke?

This wsconfig connector change to eliminate access to CFAdmin (see link above). I mean I ran into this issue in a local dev environment where I have no security concerns about myself accessing CFAdmin LOL. We also often have internal staging servers, etc that are behind firewalls and again - there is no threat to someone accessing CFAdmin. This is also covered in detail in the lockdown guide which we've all been using for years. Why suddenly was this change made and more importantly why wasn't this documented somewhere? Handle it like CommandBox does maybe - check an env variable and if it's 'dev' then things are open, if it's 'prod' then lockdown. I think the Adobe docker images use something like 'enableSecureProfile'. I understand you want to provide as secure an environment as possible - but it's like seat belts and birth control - you can provide the means but at the end of the day that responsibility lies on the user.

(probably because too many CFers weren't taking on that responsibility -- and Adobe as the vendor supplying the product got the blowback from that?)

Short answer, Sean is correct. When a breach occurs the headline isn't "Careless User Didn't Set Up Their Security" it is "Adobe ColdFusion Breached Due to Security Snafu!!!11". However, I agree that documentation should have been more clear here and am working on getting that sorted.

I'd still like to see some sort of flag or switch here. It can default to 'secure' but could be switched off for dev environments, etc.

(and... I hate to sound like a broken record... but a lot of this is because "most" CFers don't understand their stack so they have to rely on Adobe to "fix" stuff for them in this regard... which is also why "most" CFers just use the supplied connector and don't even think about how it works)

Thanks for sharing the article, @Jim Priest. Since the connector library and configs are backed up as of these hotfixes, rolling back to a previous version should be an option for an upgraded system (albeit potentially less secure, and maybe not recommended by Adobe). Although new installs/future installs may not easily have that option. For anyone running an older connector (any CF version), I'd strongly recommend all of the "Recommended Actions"

That image from the article is from the C64 version of Defender of the Crown. Kids, you don't know how good of a game that was. Those graphics. The music that SID chip could produce. The siege gameplay featured in that image was epic but there were also tournaments with jousting and raiding enemy castles and sword fighting...Such an amazing game. Also, very much appreciate the heads up on the changes.

First off, my apologies, but count me in the "most CFers" group lacking 110% understanding of the CF stack. That said, I do try for due diligence, meaning a clear understanding of the steps I need to take to perform each upgrade reliably, and I'm confused. I've updated a dev server to 2021.0.11.330247 without problems. I removed and re-added the connector after the update, and didn't lose access to CF Admin. It's accessible on the LAN, only, and I can still get to it from another machine inside the firewall, without custom tweaks or any other steps beyond running the upgrade and rebuilding the connector. I thought that was going to be blocked, but it's not. So: • Why wasn't it blocked? • Does the fact that it's not mean we're more vulnerable that we should be? • Is there anything further I should do to ensure smooth sailing in this regard when I update production this evening?

@Dave Merrill Are you accessing CFAdmin through the connector, or directly via the built-in Tomcat server (port 8500/TCP, by default)? You should only be blocked if you're explicitly trying to access CFAdmin through the connector (e.g., the IP address and port of your external webserver, not Tomcat*)*

@Brian Reilly Thanks for jumping in. I can access it at the address of my dev instance or at the actual internal server name, but only on the designated admin port, not normal https 443. I verified that it's still accessible both those ways if I delete the connector and don't recreate it, so that must mean it's not going through the connector. is there any reason I shouldn't leave it like that, with no connector? Fewer attack surfaces?

@Dave Merrill that sounds like it isn't going through the connector. Is that "designated admin port" a used by a ColdFusion/Tomcat server, or is it an admin port for an external webserver (e.g., like a dedicated admin Virtual Host in Apache/IIS?). I assume it's the former ... but I don't want to assume 😂 What's required really depends how your CF application environment is set up ... direct access, a connector, or a proxy setup are all possibilities.

@Dave Merrill Re: security -- unless your dev server is publicly exposed on the Internet, I wouldn't worry about the internal server vs connector issue. At work, none of our dev/test/CI stuff is publicly accessible, but our QA cluster is, although only via ports 80 and 443 so none of the internal servers are accessible (we have Nginx on those ports and it specifically maps the various admin-related paths to 404s).

I went through all IIS sites and verified that none of them are bound to that admin port, so cf admin is definitely tomcat like I thought, IIS only runs the sites. @seancorfield Most of dev isn't accessible outside the firewall, but there's a site we use for customer previews that's got dev code but is accessible through the firewall. It's IIS, not tomcat, no cf admin access. Am I understanding right that we're ok at this level? There's only an issue if a site running through the connector needs to access admin URLs?

My understanding is that the security change was essentially at the connector level to prevent access to admin URLs via the IIS/Apache web server in front of CF -- but if you can access the underlying Tomcat port(s), you can access the admin just fine. Most firewall/DMZ setups are only going to expose ports 443 and maybe 80 which means traffic can get to IIS/Apache but not Tomcat on a different port.

Understood. Thanks for your feedback folks.