ColdFusion has one of the cleanest exploitation records of any enterprise application server, and that is exactly why the batch Adobe shipped on June 30 should worry the teams still running it. The vendor patched six flaws rated CVSS 10.0, the top of the scale, that let an unauthenticated attacker run code on the server. Adobe says none are being exploited yet. On most products that line is reassuring. On ColdFusion it reads as a countdown, because the gap between a public ColdFusion patch and mass exploitation has historically been measured in weeks, not quarters.
The updates land as bulletin APSB26-68 and carry Adobe's highest urgency, Priority 1, the tier reserved for flaws the vendor expects to be attacked. Every one is rated easy to exploit and needs no victim interaction. If you run ColdFusion where anything on the internet can reach it, treat this as work for today.
Six unauthenticated code-execution flaws in one release
The core of the release is ColdFusion. Adobe fixed eleven flaws there, six of them at the maximum 10.0 score, each letting an attacker run code with no login. A seventh 10.0 flaw sits in Adobe Campaign Classic, the on-premises marketing-campaign product, where an authorization flaw (CVE-2026-48286) lets an attacker execute code in the current user's context. Adobe-hosted Campaign instances were already fixed and need no action; only self-managed installs do.
The affected and fixed builds are narrow, so check yours against this before anything else.
| Product | Affected | Fixed in |
|---|---|---|
| ColdFusion 2025 | 2025.9 (Update 9) and earlier | Update 10 |
| ColdFusion 2023 | Update 20 and earlier | Update 21 |
| Campaign Classic v7 (on-prem) | 7.4.3 build 9396 and earlier | 7.4.3 build 9397 |
ColdFusion 2025 is fixed in Update 10 and ColdFusion 2023 in Update 21. The Campaign Classic fix is build 9397. There is no partial mitigation baked into these numbers: you are either on the fixed build or you are exposed.
Why "no exploit yet" is the wrong thing to relax about
Adobe reports no known public exploit for any of these bugs at release. That holds today, and it is not the reassurance it sounds like. ColdFusion is a repeat resident of CISA's Known Exploited Vulnerabilities catalog, the government's list of bugs confirmed under active attack. In 2023, a single ColdFusion access-control flaw (CVE-2023-26360) was used to breach public-facing servers at a US federal civilian agency, an incident CISA documented in detail. The product is internet-facing by design, it runs on a Java stack that turns a file write into code execution cleanly, and it is deployed inside organizations that make attractive targets. That combination is why "not yet" tends to become "now" fast.
The practitioner read is simple: a CVSS 10.0 unauthenticated flaw with no public exploit is not a lower priority than one with an exploit. It is the same priority, on a shorter fuse, because you still have a window to patch before the proof-of-concept lands. Treating the absence of an exploit as breathing room is how the patch backlog becomes the breach. We saw the same delay dynamic with Oracle E-Business Suite, where the fix was out for weeks before attackers pushed in.
The two flaws most likely to become webshells first
Not all six of the maximum-severity flaws are equally easy to weaponize, and the bug classes tell you which to worry about first. Two of them (CVE-2026-48276 and CVE-2026-48283) are unrestricted file uploads. That class is the shortest path from a bug to a persistent foothold: an attacker uploads a ColdFusion Markup Language file into the web root and then requests it, and the server executes it as a webshell. It is the same mechanic behind the unauthenticated webshell drops we covered on Joomla hosts. The remaining four maximum-severity flaws are harder to turn into a foothold: three come from mishandled input and one from a path-traversal bug, and while each ends in code execution, none hands over a running webshell as directly as a file upload does. If you cannot patch every server in one maintenance window, the upload flaws are where a real attacker starts, so patch and hunt those first.
AI is now setting the discovery pace, and defenders have not matched it
There is a signal buried in the logistics of this release. Adobe also said it will start shipping fixes twice a month from mid-July, up from its monthly rhythm, and pinned the change on how many flaws AI-assisted research is now turning up. Read that plainly: a major vendor is doubling its release cadence because machines are finding bugs faster than a once-a-month schedule can close them.
That changes the math for defenders, and not in their favor. The same tooling that helps Adobe find eleven ColdFusion flaws at once helps an attacker turn a terse patch note into a working exploit faster, which is the compression we flagged when Washington moved to export-control an AI built for finding bugs. The patch-to-exploitation window is not a fixed number anymore; it is shrinking on both ends. A team that patches ColdFusion on a monthly change cycle is now operating on a cadence the discovery side has already outgrown.
Patch ColdFusion today, then take it off the public internet
The first move is mechanical: update ColdFusion 2025 to Update 10, ColdFusion 2023 to Update 21, and Campaign Classic to build 9397. If a maintenance window is days away, start with the internet-reachable servers and the file-upload flaws, since those are the fastest to exploit.
The second move is architectural and overdue: a ColdFusion administration or application server should not be directly reachable from the public internet. Put it behind a VPN or an authenticated reverse proxy, and restrict the admin interface to known addresses. Reachability is the only precondition these flaws need, so removing reachability is the strongest control you have while you patch.
The third move is detection, because patching closes the door but does not tell you whether someone already walked through. The highest-value behavioral signal here is the ColdFusion Java process spawning a command shell, cmd.exe, powershell.exe, or /bin/sh, which a healthy application server almost never does. Pair that with file-integrity monitoring on the web root: a new .cfm or .jsp file appearing where your own deploys did not put one is the classic webshell tell, and it fires whether or not the initial upload was logged. A managed detection setup with alerts mapped to MITRE ATT&CK is built to catch that post-exploitation behavior even when the flaw that let it in was patched hours earlier. If a server was internet-exposed and unpatched, do not assume the patch was in time; hunt as if it was not.