Exploit for Path Traversal in Adobe Coldfusion CVE-2026-48282

Name: Exploit for Path Traversal in Adobe Coldfusion CVE-2026-48282
Rating: 5 (4 reviews)
2026-07-07 | CVSS 10.0
## https://sploitus.com/exploit?id=2688E281-0EDF-5062-9EE3-37F69ACB1DA3
# CVE-2026-48282 — Adobe ColdFusion RDS Validation and Detection

Laboratory validation of **CVE-2026-48282** in Adobe ColdFusion Remote Development Services (RDS), focused on technical evidence, event reconstruction, and defensive detection opportunities.

The repository documents a controlled test in which the vulnerable RDS FILEIO functionality was used to write a CFM file to a ColdFusion application directory. Invoking the file over HTTP caused ColdFusion to start a system shell and establish an outbound connection. The resulting process and network activity was captured using Linux `auditd`, `tcpdump`, Docker telemetry, ColdFusion logs, and Windows Event ID 4688.

> [!IMPORTANT]
> This repository contains reports and screenshots only. The custom file-upload/payload implementation is intentionally **not included**, because publishing directly reusable exploitation code would add unnecessary offensive capability. The material is intended for vulnerability validation, SOC engineering, detection development, and authorized research.

## Reports

- [English validation report](reports/CVE-2026-48282_ColdFusion_RDS_detection_EN.pdf)
- [Polish validation report](reports/CVE-2026-48282_ColdFusion_RDS_detection_PL.pdf)

Both reports contain the full test methodology, evidence excerpts, timeline, process chain, network indicators, mitigation guidance, audit recommendations, and example SIEM logic.

## Repository structure

```text
.
├── README.md
├── SHA256SUMS.txt
├── reports/
│   ├── CVE-2026-48282_ColdFusion_RDS_detection_EN.pdf
│   └── CVE-2026-48282_ColdFusion_RDS_detection_PL.pdf
└── screenshots/
    ├── 01_rds_authentication_no_authentication.png
    ├── 02_vulnerability_check.png
    ├── 03_rds_file_write_validation.png
    ├── 04_reverse_shell_session.png
    └── 05_connect_cfm_on_ubuntu_host.png
```

No exploit source, payload source, CFM payload, raw PCAP, or raw host evidence package is included.

## Test environment

| Role | System |
|---|---|
| Victim host | Ubuntu 24.04.4 LTS, kernel 6.17.0-35-generic, Docker Engine 29.5.3 |
| Target application | Adobe ColdFusion 2025 Update 9, image `adobecoldfusion/coldfusion2025:2025.0.9` |
| Container | `coldfusion-2025-u9` |
| Attacker workstation | Microsoft Windows 11 Home 10.0.26200 |
| ColdFusion service | `http://172.20.10.3:8500` |
| Windows test address | `172.20.10.2` |
| Container address | `172.19.0.2` |
| Test date | 7 July 2026 |

The ColdFusion application directory `/app` was mapped from the Ubuntu host path `/home/user/coldfusion-u9/app` as a Docker bind mount.

## What was validated

The test was performed in an isolated and authorized laboratory environment. The validation covered the following sequence:

1. Adobe ColdFusion 2025 Update 9 was deployed in Docker.
2. RDS was enabled for the laboratory test, with the authentication mode set to **No authentication needed**.
3. The public project listed in [References](#references) was used to confirm that the RDS endpoint was reachable and that the tested instance appeared vulnerable.
4. A laboratory-only uploader was used to submit a CFM file through the RDS FILEIO operation to `/app/connect.cfm`.
5. The file was invoked through `GET /connect.cfm`.
6. ColdFusion launched `/bin/bash` through the Java process execution path.
7. The shell established an outbound TCP connection to the Windows workstation.
8. Non-destructive discovery commands were executed to confirm the effective user, operating system, and working directory.
9. Evidence from the attacker and victim systems was correlated into a single UTC timeline.

The reports intentionally document the evidence and detection logic without distributing the custom uploader or payload implementation.

## Confirmed result

The laboratory test confirmed:

- arbitrary CFM file write through the RDS FILEIO endpoint in the tested configuration;
- execution of the written CFM file by ColdFusion after an HTTP request;
- creation of the process chain:

```text
ColdFusion Java
└── jspawnhelper
    └── /bin/bash -c ...
        └── bash -i
            ├── whoami
            ├── uname
            └── id
```

- an outbound shell connection from the ColdFusion container to the Windows host;
- execution in the context of the ColdFusion service user, not as root.

Inside the container, the effective identity was:

```text
uid=999(cfuser) gid=999(cfuser) groups=999(cfuser)
```

On the Ubuntu host, UID 999 was resolved using the host account database as `dnsmasq`, which explains the different username shown in host-level `auditd` records and file ownership output.

## Key evidence

### RDS configuration

The administrative configuration used for the test is shown below. The **No authentication needed** option was enabled only for the controlled laboratory validation.

![RDS authentication configuration](screenshots/01_rds_authentication_no_authentication.png)

### Initial vulnerability check

The initial check confirmed that the RDS endpoint was reachable and reported arbitrary file read/write behavior through path traversal.

![Vulnerability check](screenshots/02_vulnerability_check.png)

### CFM file write

The laboratory uploader submitted the local CFM test artifact to `/app/connect.cfm`. The server returned the RDS response `1:2:XX`, and the written resource was subsequently reachable over HTTP.

![RDS file write validation](screenshots/03_rds_file_write_validation.png)

### Code execution and service-account context

The resulting shell session confirmed execution as the ColdFusion service account. The commands shown in the screenshot were limited to environment identification.

![Reverse shell session](screenshots/04_reverse_shell_session.png)

### File on the Ubuntu bind mount

The file appeared in `/home/user/coldfusion-u9/app`, the host path mounted into the container as `/app`.

![connect.cfm on the Ubuntu host](screenshots/05_connect_cfm_on_ubuntu_host.png)

## Reconstructed timeline

The complete timeline is available in both PDF reports. The most important events were:

| UTC | Event |
|---|---|
| 20:55:17 | Administrator login to CFADMIN |
| 20:55:32 | RDS security enabled and authentication set to `No authentication needed` |
| 21:13:22 | Linux auditing, packet capture, and Docker collectors started |
| 21:14:25 | Vulnerability-check script executed from Windows |
| 21:14:40.940 | `POST /CFIDE/main/ide.cfm?ACTION=FILEIO` with a `WRITE` operation to `/app/connect.cfm` |
| 21:14:40.944 | RDS returned `1:2:XX` |
| 21:14:40.950 | Browser requested `/connect.cfm` |
| 21:14:41.321 | ColdFusion Java launched `jspawnhelper` |
| 21:14:41.324 | ColdFusion launched `/bin/bash` |
| 21:14:56 | `ncat.exe -lv 4444` started on Windows |
| 21:15:00.726 | Outbound connection to `172.20.10.2:4444` succeeded |
| 21:15:07–21:15:15 | `whoami`, `uname`, `id`, and `pwd` confirmed the execution context |
| 21:15:20 | Session closed |

## Evidence collection methodology

### Linux and Docker

The victim host collected:

- `auditd` events for `execve`, `execveat`, and `connect` where the effective UID was 999;
- watches on the ColdFusion webroot and log directory;
- `tcpdump` traffic for the HTTP and callback ports;
- periodic process and socket snapshots;
- Docker container metadata, logs, events, process listings, and filesystem differences;
- ColdFusion application and administrative logs;
- SHA-256 hashes and metadata baselines.

The final `auditd` status reported `lost=0`, indicating that the kernel audit subsystem did not report dropped events during the captured test window.

### Windows

The attacker workstation collection was intentionally limited to report-relevant artifacts:

- operating-system and network details;
- Event ID 4688 process creation records;
- processes associated with Python and Ncat;
- relevant TCP connection data;
- hashes of laboratory files;
- Microsoft Defender status and detections;
- tool versions.

## Most important detection opportunities

### 1. RDS FILEIO request

Monitor HTTP, reverse-proxy, WAF, or network telemetry for the following combination:

```text
POST /CFIDE/main/ide.cfm?ACTION=FILEIO
User-Agent: Dreamweaver-RDS-SCM1.00
request body contains: WRITE
request body references: .cfm, .cfc, or .jsp
```

The combination is significantly stronger than any single indicator by itself.

### 2. File write followed by execution

Correlate:

1. a FILEIO `WRITE` request to a server-executable extension;
2. a subsequent `GET` request to the newly written resource;
3. a new child process of ColdFusion Java or `jspawnhelper` within a short time window.

### 3. Suspicious ColdFusion child process

High-value process indicators include:

```text
parent process: java or jspawnhelper
child process: bash, sh, dash, cmd.exe, powershell.exe, or pwsh
```

Additional command-line indicators include `/dev/tcp`, interactive shell flags, redirection operators, encoded commands, and unexpected use of `cfexecute`.

### 4. Outbound connection from the application service account

Alert when a shell or interpreter launched by ColdFusion initiates an outbound connection to a workstation or an unusual destination port. The laboratory event used TCP port 4444, but production detection should not depend on a single port.

### 5. RDS configuration changes

Monitor ColdFusion administrative logs for messages containing:

```text
enabled RDS security
RDS authentication type
No authentication needed
```

Any RDS configuration change in production should be reviewed, particularly when authentication is weakened or the service becomes reachable from additional networks.

### 6. Application-directory file monitoring

The test identified an important container-monitoring limitation: `/app` was a bind mount. `docker diff` showed `/app` but did not provide complete visibility into individual files created inside the host-mounted directory.

File-integrity monitoring, `auditd`, eBPF, or EDR coverage should therefore monitor the **real host path** backing the mount, for example:

```text
/home/user/coldfusion-u9/app
```

Monitoring only the container overlay or `/opt/coldfusion/cfusion/wwwroot` would not have captured the complete file-creation evidence for this test.

## SOC triage guidance

When the HTTP indicator is detected, the SOC should immediately correlate it with:

- the source IP and user agent;
- RDS authentication and exposure configuration;
- the target path contained in the FILEIO body;
- new or modified `.cfm`, `.cfc`, `.jsp`, or archive files;
- HTTP access to the same file shortly after creation;
- ColdFusion Java child processes;
- outbound connections from the service account;
- subsequent discovery commands such as `whoami`, `id`, `uname`, `hostname`, `pwd`, `ip`, `ifconfig`, `netstat`, or `ss`;
- persistence attempts, credential access, or lateral movement after the initial process execution.

A single `GET` request to a CFM file is not sufficient on its own. The strongest alert combines file-write, file-access, process-creation, and network-connection telemetry within the same short time window.

## Recommended mitigations

1. Apply the Adobe ColdFusion security update referenced in APSB26-68.
2. Disable RDS when it is not operationally required.
3. If RDS must remain enabled, enforce authentication and restrict access to explicitly authorized administrative systems.
4. Prevent RDS and CFIDE administrative endpoints from being exposed to untrusted networks.
5. Monitor and restrict writes to directories from which ColdFusion can execute server-side content.
6. Limit the ability of the ColdFusion service account to launch operating-system processes where business functionality does not require it.
7. Monitor the host paths behind Docker bind mounts, not only the container overlay filesystem.
8. Review the environment for unexpected CFM/CFC/JSP files and ColdFusion-launched shells.

## Scope and limitations

- The validation was performed against one ColdFusion 2025 Update 9 Docker instance.
- RDS was deliberately configured as **No authentication needed** for the controlled test.
- The observed impact was code execution as the ColdFusion service account; no privilege escalation to root was observed.
- The result confirms the tested path and configuration. It does not prove that every deployment, authentication mode, reverse proxy, or operating system behaves identically.
- Raw exploit code, the custom uploader, and the CFM payload are not distributed in this repository.
- The reports contain selected evidence excerpts rather than full raw logs, to keep the material readable and focused on detection.

## References

- [Adobe Security Bulletin APSB26-68](https://helpx.adobe.com/security/products/coldfusion/apsb26-68.html)
- [NVD — CVE-2026-48282](https://nvd.nist.gov/vuln/detail/CVE-2026-48282)
- [CVE.org — CVE-2026-48282](https://vulners.com/cve/CVE-2026-48282)
- [Public project used as the initial validation reference](https://github.com/imbas007/CVE-2026-48282-POC)

## Responsible-use notice

This material is provided for defensive security research, vulnerability management, detection engineering, incident-response preparation, and authorized testing. Do not use it against systems without explicit permission.