Adobe ColdFusion CVE-2026-48282: Unauthenticated RDS Path Traversal to Remote Code Execution

The federal deadline to fix this one is today. CISA gave agencies until July 10 to close CVE-2026-48282, a path traversal in Adobe ColdFusion that a remote attacker uses to write a file anywhere on the server - a webshell in your web root, for example - without a single valid credential. Adobe scores it CVSS 10.0. It is already being used in real attacks, and one intelligence tracker clocked the first exploitation attempts within hours of public disclosure.

The bug lives in ColdFusion's Remote Development Services (RDS), a developer convenience that has no business being reachable on a production server and yet routinely is. It shipped as one of eleven flaws Adobe fixed on June 30 in bulletin APSB26-68 - five of them rated 10.0. CISA added CVE-2026-48282 to the Known Exploited Vulnerabilities catalog on July 7 under Binding Operational Directive 26-04, which is what put a hard clock on it.

Whether this one is actually yours

The honest read matters more than the CVSS number. If you run ColdFusion 2023 (Update 20 or earlier) or ColdFusion 2025 (Update 9 or earlier) with the RDS service reachable, this is a drop-everything patch and you are likely already late. If your ColdFusion instance is not internet-facing and RDS is disabled, your exposure to this specific bug falls sharply - but the same bulletin also fixes unauthenticated file-upload paths to code execution (CVE-2026-48276 and CVE-2026-48283, both 10.0) that do not depend on RDS, so you are patching to Update 10 or Update 21 regardless.

If you do not run ColdFusion anywhere, you can close this tab. The catch is the reason ColdFusion keeps surprising teams: it tends to be the box nobody remembers owning - one legacy application behind a load balancer, a vendor appliance that embeds the runtime, an acquisition's server that got racked and forgotten. Before you decide this is not yours, make sure you actually know.

What CVE-2026-48282 actually does

RDS is an HTTP-based RPC interface ColdFusion exposes so that IDE tooling can perform remote file operations. Its FILEIO subcomponent handles remote read, write, rename, and delete. Per Resecurity's technical writeup, the handler took user-controlled file paths and passed them to the filesystem without canonicalizing them, enforcing a directory boundary, or rejecting absolute paths. Feed it a path full of ../ sequences and it writes wherever you point it.

The request goes to POST /CFIDE/main/ide.cfm?ACTION=FILEIO on the ColdFusion listener - default port 8500, though plenty of deployments front it on 443 - and it needs no authentication. The exploitation chain is short: confirm write access through the FILEIO WRITE operator, drop a .cfm file into the web root, then request that file over HTTP. ColdFusion parses and runs it with the privileges of the ColdFusion service account. That is a full webshell on a public-facing server, which is the foothold an operator uses to harvest credentials, reach the database the app talks to, and pivot inward. Adobe's own bulletin now acknowledges the flaw has been exploited in the wild in limited attacks.

Do not fixate on RDS to the exclusion of the rest of APSB26-68. The same update closes CVE-2026-48276 and CVE-2026-48283, a pair of unrestricted-file-upload flaws that reach code execution without RDS in the path, plus three improper-input-validation bugs (CVE-2026-48277, CVE-2026-48281, and CVE-2026-48314) also scored 10.0. An attacker who finds your ColdFusion instance is not limited to one technique. That is why the answer is the patch to a fixed build, not a point mitigation for a single request path - the mitigation buys you time on July 10, the update is what actually clears the cluster.

Find out if you are exposed in five minutes

Two questions decide your morning: is a ColdFusion listener reachable, and is RDS answering on it. You can check both from a host that can reach the server without touching the vulnerable operators. Probing the endpoint below only fingerprints the service; it does not write anything.

Check for a reachable ColdFusion / RDS listener

# Is a ColdFusion listener up on the usual ports?
for port in 8500 8501 443; do
  code=$(curl -s -o /dev/null -m 5 -w "%{http_code}" "https://TARGET:${port}/CFIDE/administrator/enter.cfm")
  echo "port ${port}: HTTP ${code}"   # 200/302 means the admin app is reachable
done

# Does the RDS IDE endpoint answer? (fingerprint only, no FILEIO operator sent)
curl -s -o /dev/null -m 5 -w "RDS ide.cfm: %{http_code}\n" \
  "https://TARGET:8500/CFIDE/main/ide.cfm"

# On the server itself, confirm the installed update level.
# ColdFusion 2025 is fixed at Update 10; ColdFusion 2023 at Update 21.
grep -ri "update level" /opt/coldfusion*/cfusion/lib/version.properties 2>/dev/null

An answer on ide.cfm from anywhere outside your development network is the finding. RDS should never be enabled in production, and it should never be reachable from the internet. If both are true right now, treat the host as a live exposure.

Assume attackers are already running the internet-wide version of this check. ColdFusion advertises itself: the /CFIDE/ path, the administrator login page, and the default 8500 listener are all trivially fingerprinted at scale, and mass scanning for freshly disclosed ColdFusion bugs starts the day the CVE lands. If your instance is internet-facing, it has almost certainly been probed already. That reframes the question from "will someone find it" to "what did they do between June 30 and the moment you patched," which is why the hunt below is not optional.

Patch, then hunt - the update does not remove a webshell

Applying the fix stops the next attacker. It does nothing about one who already wrote a file last week. Because CISA's forensics-triage guidance under BOD 26-04 exists for exactly this reason, do both in order.

Close the exposure

• Update ColdFusion 2025 to Update 10, or ColdFusion 2023 to Update 21. Older, unsupported branches do not get a fix - migrate or isolate them.
• Disable RDS on every production instance. In the ColdFusion Administrator it is under Security, and it should read as off.
• Take the ColdFusion Administrator and any RDS listener off the public internet. Bind them to localhost or an admin VLAN, not 0.0.0.0.
• Run the ColdFusion service under a low-privilege account so that code execution through the app is not code execution as SYSTEM or root.

Hunt for a webshell that beat you to the patch

# Recently written or modified CFML/JSP in the web root and CFIDE tree.
# Attackers drop these to get an executable file they can call over HTTP.
find /opt/coldfusion*/cfusion/wwwroot /var/www \
  \( -name '*.cfm' -o -name '*.cfc' -o -name '*.cfml' -o -name '*.jsp' \) \
  -newermt '2026-06-25' -printf '%TY-%Tm-%Td %TH:%TM  %p\n' 2>/dev/null | sort

# Web/CF access logs: FILEIO calls, especially with traversal sequences.
grep -riE 'ide\.cfm\?action=fileio|%2e%2e%2f|\.\./' \
  /opt/coldfusion*/cfusion/logs /var/log/httpd /var/log/nginx 2>/dev/null

# Small or oddly named .cfm files in the web root are worth reading by hand.
find /opt/coldfusion*/cfusion/wwwroot -name '*.cfm' -size -3k 2>/dev/null

The indicators of compromise are concrete: unauthorized .cfm, .cfc, .cfml, or .jsp files in the web root or under /CFIDE/; FILEIO requests carrying traversal patterns in the logs; and administrative activity in the ColdFusion logs that maps to no change your team made. Find any of those and you are running an incident, not a patch cycle - preserve the logs and the dropped files before you delete anything.

The controls that outlast this CVE

ColdFusion has carried more than a dozen KEV entries over the years, and the shape never changes: a developer-oriented feature, reachable where it should not be, turned into unauthenticated code execution. The specific bug this quarter is RDS path traversal. Next quarter it is something else in the same attack surface. The durable fixes are the boring ones - RDS off in production, the Administrator and RDS bound away from the public internet, a WAF or reverse-proxy rule that refuses external requests to /CFIDE/, and the service running as a constrained account. For a small business, a public webshell on the server that hosts the customer-facing app means downtime, a breach-notification conversation with a lawyer, and a cleanup bill that dwarfs the cost of the patch window. The control that prevents all of it is knowing the ColdFusion box is there in the first place.

Put this specific host on a short list you check by hand every Patch Tuesday, and add ColdFusion's product string to whatever inventory you use to answer "do we run this" when the next KEV entry drops. A legacy application server that no one owns is the asset that turns a routine advisory into an incident, because the patch never gets applied to a box nobody is watching. If the honest answer is that you are not sure whether ColdFusion is running behind your perimeter, resolve that this week - the discovery is worth more than any single patch.

Turn off RDS and prove your web root is clean before you trust the patch

Do three things today, in this order: confirm whether any ColdFusion listener - and RDS in particular - is reachable from outside your network; update to 2025 Update 10 or 2023 Update 21 and disable RDS; then hunt the web root and the logs for files and requests you cannot account for. The patch is the easy part. The webshell someone may have dropped before July 7 is the part that decides whether this was a busy Friday or a bad month. If you are not certain what is still running ColdFusion behind your perimeter, that uncertainty is the vulnerability worth closing first.