Adobe ColdFusion's RDS Never Checked the Path: CVE-2026-48282 Ships an Unauth Webshell Through ide.cfm

We spent Wednesday morning at BlueTeamAutomation trying to convince ourselves this was a bug from 2013 that had somehow gotten a fresh date stamped on it. It is not. CVE-2026-48282 was patched by Adobe on June 30, sat quietly for maybe forty-eight hours, and by July 2 watchTowr Labs had published a working technique that honeypot sensors began catching within hours. The mechanism is a path traversal in ColdFusion's Remote Development Services FILEIO handler, and if your server is on a network with RDS enabled and its own password blank, one HTTP POST writes a CFML webshell wherever the service account can reach.

CISA agrees this one is worth an alarm. On July 7 the CVE went onto the Known Exploited Vulnerabilities catalog with a Federal Civilian Executive Branch deadline of today, July 10. That is the tightest KEV timeline we have seen in weeks, which is why this post landed on your feed instead of the second story on our list.

Why RDS was still listening on July 2

Remote Development Services is the ColdFusion feature that lets an IDE talk to a running server over HTTP. Historically that meant Dreamweaver, ColdFusion Builder, or the Eclipse plugin, and today it means the VS Code extension that Adobe still ships for CFML developers. Once RDS is enabled, a client can browse the filesystem, run database queries, and pull debugging data from the server without ever logging into the ColdFusion Administrator.

The trouble is that RDS is a separate switch from Administrator authentication. Adobe's own guidance, in the RDS knowledge-base article, has told operators for years to turn it off in production. A lot of installs never do, because a lead developer wants to poke at prod one weekend and nobody flips the flag back. Others enable RDS but leave the RDS-only password blank, which is functionally equivalent to leaving the front door unlocked because you set a house alarm. When both conditions hold, /CFIDE/main/ide.cfm answers requests from anyone who can reach the port.

Inside ide.cfm: how FILEIO writes wherever you point it

Every RDS command is an HTTP POST to /CFIDE/main/ide.cfm with an ACTION query parameter that names the operation. Behind the scenes, RdsFrontEndServlet reads the ACTION value, looks it up in a command map, and dispatches the request to a handler servlet. When ACTION equals FILEIO, the dispatcher hands the request off to FileServlet, which is the Java class responsible for remote filesystem management on behalf of an IDE.

FileServlet accepts a target path in the request body along with a sub-function (read, write, delete, rename, mkdir, list) and, for writes, the content to place at that path. According to watchTowr's analysis and Help Net Security's write-up, the servlet forwarded that path straight to the underlying java.io.File API without canonicalization and without a check that the target lived beneath any RDS working root. A traversal string such as ../../../opt/coldfusion2023/cfusion/wwwroot/, or a bare absolute Windows path like C:\ColdFusion2023\cfusion\wwwroot\, was accepted verbatim. If you could send bytes to that endpoint, you could write anywhere the ColdFusion service user had write access, which on a stock Windows install is typically NT AUTHORITY\SYSTEM, and on Linux is the cfusion account that owns the webroot.

watchTowr also pointed out that the same patch quietly closed sibling primitives on the same servlet chain: an arbitrary file read, an arbitrary file move, an arbitrary delete, mkdir, and a directory listing. This bug was not a single careful oversight; it was a whole IDE control plane sitting on the public internet with the doorknob glued open.

Turning arbitrary file write into a webshell

Arbitrary file write is bad on its own. The ColdFusion runtime makes it worse, because any .cfm file placed inside the webroot gets parsed and executed by the CFML engine when it is requested over HTTP. Drop a two-line file containing <cfexecute name="cmd.exe" arguments="#url.cmd#" timeout="10"></cfexecute> into /CFIDE/x.cfm, then GET /CFIDE/x.cfm?cmd=whoami, and the response body carries stdout back. The whole exploit chain fits into two HTTP requests.

Multiple write-ups confirm the pattern. Orca Security called this the "maximum-severity" case because the payload runs as the ColdFusion service account, and Bleeping Computer observed that attackers began dropping persistent CFML webshells on exposed servers within hours of the technique going public. There are also laboratory reproductions already on GitHub with PCAP evidence, auditd logs, and event timelines, which means the exploit is now commodity kit rather than a researcher-only curiosity.

The blind spot in ColdFusion traffic

A normal blue team will look at the incident and ask why nothing fired. The reasons stack up quickly. /CFIDE/main/ide.cfm has been part of ColdFusion since the earliest 2000s releases, so it will not trigger a WAF rule that flags newly discovered endpoints. A POST to that URL looks like any other Administrator or IDE traffic, so basic anomaly detection will wave it through. The .cfm file that gets written is small, valid CFML, and lives inside a directory the CI/CD pipeline already touches, so file-integrity monitoring alerts get de-duped against the last deploy. On the host, EDR sees the ColdFusion service spawn a child process, which is exactly what happens during any real business activity for an application server. Without a rule specifically wired to this endpoint and this behavior, the chain leaves almost no fingerprint.

The hunt: request, file, process

The good news is that once you know where to look, the observable footprint is loud. Start with the web tier: log any POST to /CFIDE/main/ide.cfm with ACTION=FILEIO whose source IP is not a known developer workstation, and alert on any request body containing .., an absolute path, or the string cfexecute. Correlate with new .cfm files appearing in the webroot outside your deployment window, and pull file hashes so you can spot the same shell reused across hosts.

On the endpoint, watch for the ColdFusion service account (cfusion, coldfusion, or the java.exe running JRun or Tomcat) as the parent of cmd.exe, powershell.exe, /bin/sh, curl, wget, certutil, or bitsadmin. That parent-child pairing is the loudest post-exploitation signal available. The detection lab also flags a config smell you can pull out of asset inventory: the ColdFusion admin log line enabled RDS security RDS authentication type No authentication needed. If that string appears anywhere in your fleet, you have an exposure map before you have an incident.

The MITRE ATT&CK mapping is straightforward. T1190 Exploit Public-Facing Application for the initial access, T1505.003 Server Software Component: Web Shell for the persistence, T1059 Command and Scripting Interpreter for the cfexecute stub calling cmd or bash, and T1078 Valid Accounts because the service account has legitimate credentials the attacker will now reuse laterally.

What to do before the deadline

Patch first, and patch specifically. Adobe security bulletin APSB26-68 lists ColdFusion 2025 Update 10 and ColdFusion 2023 Update 21 as the fixed builds, and applies to ColdFusion 2025 Update 9 and earlier and ColdFusion 2023 Update 20 and earlier. If you cannot patch today, block /CFIDE/main/ide.cfm at the reverse proxy or WAF for any source outside your developer VLAN, and disable RDS through the ColdFusion Administrator on any host where it is not actively used.

Then hunt as if the fix arrived late, because on the internet-exposed instances it probably did. Enumerate every .cfm file in the webroot, hash them, and require each one to trace back to a deploy commit. Rotate ColdFusion datasource credentials, encryption keys, and the Administrator password on any server that had RDS reachable within the last thirty days, since a webshell that ran as the service account had full read on those secrets. Finally, run a controlled reproduction of the FILEIO technique against a lab clone once you believe you are patched, so the fix stops being an assumption and starts being evidence.

The BASzy loop

This is exactly the loop BlueTeamAutomation automates end to end, from BASzy replaying the RDS FILEIO technique against your production estate, through EDR and SIEM correlation on the webshell chain, all the way to SOAR-driven isolation and secret rotation with compliance evidence emitted in the same run. That way the detection and the proof it works are continuous rather than a scramble the morning a KEV deadline lands.