Adobe ColdFusion Hardening Guide

Adobe ColdFusion servers are often old, internet-facing and forgotten, and attackers keep returning to them because deserialization and access control flaws turn an exposed Administrator into code execution. The CISA Known Exploited Vulnerabilities catalogue lists 16 ColdFusion entries, from 2010 directory traversal in the administrator console to 2023 deserialization flaws marked as used in ransomware campaigns. This guide sets out how authentication and administration work in ColdFusion, the settings from Adobe's own lockdown guide that close the common entry points, and what to log and hunt for so that compromise is found and contained. It is for application server administrators, incident responders and security engineers who inherit ColdFusion estates. If you are already responding to a suspected web shell, start with the Web Shell Response Playbook and return here to harden the rebuilt server.

Key takeaways

• Patch ColdFusion and the JDK together. Adobe's bulletins state that applying the ColdFusion update without the matching JDK or JRE update will not secure the server.
• The Administrator and AdminAPI must not be reachable from the internet. Block /CFIDE at the web server and restrict "Allowed IP Addresses for ColdFusion Internal Components"; KEV describes CVE-2024-20767 as exploitable through an internet-exposed admin panel.
• Run the Secure Profile and the lockdown tool. Adobe's auto-lockdown installer applies a dedicated service account, file permissions, connector rules and recommended Administrator settings, and rolls back if it fails.
• The password seed protects stored credentials. Data source and service passwords are encrypted with the seed in seed.properties, so a server compromise means rotating every database and service credential it held.
• Assume compromise on unpatched exposed servers. With exploitation going back years, an internet-facing server that missed updates needs a hunt for web shells before it is trusted again.

How identity and access work in Adobe ColdFusion

ColdFusion has two separate access planes, and hardening must cover both. The application plane is whatever the developers built: CFML pages and components, their own sign-in logic and sessions. The server plane is the ColdFusion Administrator, the AdminAPI, Remote Development Services (RDS), the Performance Monitoring Toolset (PMT) and internal servlets, which control the whole server.

For the application plane, the lockdown guide sets ColdFusion session defaults that apply to every application unless it overrides them: "Use UUID for CFToken", a session variable default timeout of 20 minutes or less and a maximum under two days, cookies marked HTTPOnly and Secure (where all sites use HTTPS), and a SameSite default of lax or strict (section 4.5). Application sign-in logic is the developers' responsibility; review it against the Application Security Guide.

Admin roles and privileged access

A fresh install can be administered with a single shared password. Adobe's lockdown guide moves away from that model.

• Named administrator accounts: choose "Separate user name and password authentication" (4.25) and add a user account for each person who signs in to the Administrator (4.28). Separate accounts let you limit which parts of the Administrator each user can use and attribute changes to a person.
• No concurrent sessions: uncheck "Allow concurrent login sessions for Administrator Console" (4.25).
• Network restriction first: the IP allow list for internal components is the control that stops internet attackers reaching the Administrator at all. Pair it with web server rules blocking /CFIDE, /WEB-INF, /Application.cfc and /jakarta, plus /cf_scripts where not needed (5.8, 2.6.14).
• Least privilege service account: run ColdFusion under a dedicated low-privilege account (the guide creates cfuser on Linux), never as root, SYSTEM or a domain account. Code execution through a deserialization flaw runs "in the context of the current user", so this account decides how bad a compromise is.
• Sandbox security: where several applications share a server, use sandboxes to restrict file system, tag and function, data source and network access per application (4.27).
• Operating system administrators: whoever can log on to the host can read password.properties and seed.properties. Treat host admin rights as ColdFusion admin rights and manage them through your privileged access process. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

A ColdFusion server is usually a hub of stored credentials: database logins in data sources, mail server accounts, scheduled tasks that call other systems, and keys embedded in application code. After exploitation, these are what attackers harvest (T1552.001 Credentials In Files).

Each of these is a non-human identity with no person attached, which is why they survive staff changes and rebuilds. Record an owner for each, store new secrets outside the server where possible, and plan a full rotation for the day a server is found compromised. See the Secrets Management Guide.

Logging and detection

The lockdown guide's logging settings (4.21) are the starting point: a non-default log directory, at least 10 archived files, "Use operating system logging facilities" so logs reach syslog or the Windows event log, and "Enable logging for scheduled tasks". Forward those logs and the front-end web server logs off the host, because an attacker running as the service account can alter local files.

Responding to a suspected compromise

1. Contain: remove the server from internet exposure, but keep it running if you need memory evidence.
2. Preserve: copy web server logs, ColdFusion logs, the webroot and configuration directories, and a list of running processes and network connections.
3. Scope: compare the webroot against a known-good build, check scheduled tasks and data sources for additions, and review outbound connections from the server.
4. Rotate: change every data source, mail and integration credential, the Administrator accounts and the password seed, and any key held in application code.
5. Rebuild: install a current ColdFusion release and JDK on a clean host, apply the lockdown, then redeploy code from source control rather than copying from the compromised server.

For the forensic steps in detail, see the Web Shell Response Playbook and the Incident Response Guide.

Metrics

• Number of ColdFusion servers in the inventory, and how many run a supported version with the current update and JDK.
• Days from an Adobe priority 1 ColdFusion bulletin to deployment on every server.
• Servers where /CFIDE answers from the internet (target zero, tested from outside).
• Percentage of servers with the Secure Profile and lockdown applied, and with file integrity monitoring on the webroot.
• Data source accounts with more than the required database rights.

Hardening baseline

Patching rules from Adobe's bulletins

Two rules apply to every bulletin. Update the JDK or JRE to the release in Adobe's support matrix alongside ColdFusion. And on JEE deployments (ColdFusion running inside Tomcat, WebLogic or WildFly rather than standalone), set the -Djdk.serialFilter JVM flag with the values in the bulletin, in JAVA_OPTS or JAVA_OPTIONS in the application server's start-up file. Adobe says to set it on JEE installations only. Unsupported releases receive no fixes at all (NIST SA-22): plan migration for any server on a ColdFusion version outside Adobe's support.

Configuration settings

• Install profile: Production Profile plus Secure Profile (2.3.3, 4.30).
• Debugging off: keep "Allow Remote Inspection", "Allow Line Debugging" and other debugging options unchecked (4.18 to 4.22).
• Internal Java components: check "Disable access to internal ColdFusion Java components" (4.1).
• Uploads and requests: set "Blocked file extensions for CFFile uploads" to * or a list of executable extensions, limit post size and parameter count, and set "Timeout Requests After" to 5 seconds or less (4.1).
• Non-default script source: change the "Default ScriptSrc Directory" (4.1).
• File system: make wwwroot read-only except WEB-INF/cfclasses, WEB-INF/rest-skeletons and WEB-INF/cfc-skeletons (5.4).
• Remove what you do not use: example data sources and the bookclub collection (4.10, 4.12), Event Gateway Services (4.23), and unused packages found with cfpm scan (3.4).

Rollout

1. Inventory: find every ColdFusion instance, including test and forgotten servers, with version, update level, JDK and internet exposure.
2. Triage exposure: block /CFIDE and the built-in server port at the perimeter immediately for any exposed server; this needs no application change.
3. Patch: apply the latest ColdFusion update and JDK in a test environment, run application regression tests, then production.
4. Lock down in test: run the auto-lockdown installer against a test instance with a backup taken; Adobe documents that it rolls back on failure and writes logs under <CF_HOME>/lockdown/<instance>/logs/.
5. Roll out: apply to production during a change window, then test the application and confirm /CFIDE is unreachable from outside.
6. Roll back: use the lockdown uninstall properties (service user, Administrator credentials) or restore the backup if the application breaks.

Framework mapping

Common misconfigurations

• Administrator reachable from the internet: many ColdFusion flaws need the Administrator or internal components to be reachable. A web server rule blocking /CFIDE and an IP allow list would have reduced several KEV entries, including the 2013 authentication bypasses and CVE-2024-20767, to internal-only risk.
• Patching ColdFusion but not the JDK: Adobe repeats in each bulletin that the update alone does not secure the server.
• Built-in web server left on port 8500: it bypasses the front-end web server rules, so the /CFIDE block does nothing there.
• Running as a privileged account: a ColdFusion service running as SYSTEM, root or a domain account turns application code execution into host or domain compromise.
• Database accounts with full rights: data sources using sa or root mean a compromised server can read or destroy every database it connects to.
• Patching without hunting: on a server that was exposed and unpatched while a flaw was being exploited, the update closes the door but leaves any web shell in place.

Practitioner checklist

• Inventory every ColdFusion server with version, update, JDK and exposure, and retire or isolate unsupported ones.
• Block /CFIDE, /WEB-INF, /jakarta and unused PMT paths at the web server, and restrict internal components by IP.
• Apply the latest ColdFusion update and matching JDK; set the serial filter on JEE installs.
• Run the auto-lockdown tool with the Secure Profile in test, then production.
• Switch to named Administrator accounts and disable concurrent admin sessions.
• Disable RDS, debugging, unused servlets, example data sources and Event Gateway Services.
• Run ColdFusion under a dedicated low-privilege account with a read-only webroot.
• Set a random password seed, least-privilege database accounts, and record an owner for every stored credential.
• Enable OS logging and scheduled task logging, forward logs, and monitor the webroot for new files.
• Hunt for web shells on any server that was exposed and behind on updates.

Standards and references

• Adobe: ColdFusion 2021 Lockdown Guide
• Adobe: ColdFusion Server Auto-Lockdown
• Adobe: Security Bulletin APSB23-40 for ColdFusion
• Adobe: Security Bulletin APSB24-14 for ColdFusion
• Adobe: Security Bulletin APSB23-25 for ColdFusion
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE ATT&CK: Web Shell
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Web Shell Response Playbook · Emergency Out-of-Band Patching Playbook · Secrets Management Guide · Web Application Firewall Guide