More Scope Injection for Fun and Profit (or, why those security updates broke your functions)

Introduction 

Like "Big Two-Hearted River," my last post also has a Part II.  I had previously spent countless hours trying to create a UDFMethod object from user-controlled data via the Service Layer endpoints and eventually gave up decided it was just not possible.  But I had learned more about how lots of ColdFusion internals work -- including variable casting, object types, and functions.  And I kept at it.  While I wasn't able to achieve remote code execution, I ultimately did find a few new scope injection vulnerabilities later on.  These vulnerabilities highlight a broader and often overlooked risk: assumptions about scope isolation and variable safety can quietly break down at the framework level. When that happens, even well-intentioned application logic can become vulnerable in unexpected ways.

The corresponding patches for these vulnerabilities introduced breaking changes with the security fixes -- specifically, the requirement to explicitly declare all arguments for remote functions from APSB25-52 and the changes around scope precedence and variable name reserved words from APSB25-105. Read on as we explore the technical details of how they work and what the underlying risks are.

Districton 1 Slides - Control the Variables and You Control the Code: Language-Level Vulnerabilities in Adobe ColdFusion

It was an honor to speak at DistrictCon Year 1 (which is its second year.  Unlike ColdFusion, DistrictCon counts from 0. 😀)

I got some great questions and feedback after my talk, attended a bunch interesting sessions, and really enjoyed the weekend.  And yes, there was snow.  Lots and lots of snow.  But the conference team, hotel staff, and attendees all handled the weather incredibly well.  I'm already looking forward to next year, and thinking about potential Junkyard targets...

The slides from my talk -- Control the Variables and You Control the Code: Language-Level Vulnerabilities in Adobe ColdFusion -- are now available online below.  Be sure to check out my longer blog post talking about several of the vulnerabilities covered in my presentation too!

Dead Ends, Red Herrings, and Failures In Our Time

On the good days in security research, you get to channel equal parts Archimedes and Ric Ocasek in your successes. The pieces all come together as expected, the hunches turn into reality, everything just works.  And you should, of course, celebrate those moments of eureka and magic that went into your discovery, since your newest exploit is often your favorite exploit.  Though there's the rub -- your favorite exploit may forever be the one that you haven't found yet.  The perennial next one.

But this post isn't about successes in security research; it's about the failures.  If you're lucky, failure comes quickly.  A guess or a "what about..." falls apart and is disproven in minutes and not hours (or longer).  Plus every failure is an opportunity to use what you've learned about an application or a protocol or whatever in the future.  The work that goes into ten dead ends from poring over source code or RFCs can lead to a much better understanding of the overall system.  And those failures might lead you to something that you otherwise wouldn't have found or wouldn't have thought about.  Something real.  But not today.

Today we'll be looking at some ColdFusion vulnerability research that was interesting and promising at first look, but ultimately wasn't exploitable in the way I had hoped.  

RCE via ColdFusion ARchive (CAR) Deployment: One Example of an Authenticated Attack Path in CFAdmin (CVE-2025-61808)

Introduction

In this post we'll be looking at one way that an authenticated user with only ColdFusion Administration (CFAdmin) access can achieve remote code execution; this attack scenario could be used to model a rogue CFAdmin user without full server-level access, or an external attacker who is able to obtain unauthorized access to CFAdmin and then bootstrap further escalation and access.

The CFAdmin web interface introduces a large attack surface to ColdFusion environments.  That shouldn’t be a surprise since it adds a substantial default codebase intended to provide hooks into sensitive functionality.  When performing a threat model it could be perfectly reasonable to equate a CFAdmin compromise with a full system compromise.   In many organizations, the users with CFAdmin access may also be platform system administrators – with full, direct access to the underlying operating system.  If that's the case, a malicious CFAdmin user is equivalent to a malicious system administrator, and you’re cooked either way.  

But with that said, Adobe has extended considerable effort to protect and secure CFAdmin.  From monthly security patches, to webserver connectors and connector updates, to fixing other authenticated CFAdmin exploit paths – CFAdmin has become more secure over time.  And in some environments, CFAdmin access versus full platform access are distinct access roles, prompting organizations to care about all authenticated CFAdmin exploitation vectors.

Digging Through Six Old Sandbox Escapes in ColdFusion (ca. 2001 through 2012)

Time for some vulnerability archaeology!  I'm sure you're as excited as I am.  In a previous post I covered a technique to generate precompiled Java bytecode to bypass Sandbox Security restrictions in Adobe ColdFusion (CVE-2025-30288).  And Sandbox Security was first released with ColdFusion 4 in November 1998, so it's been around for quite some time.  Perhaps reading that post made you wonder about historical sandbox escapes in ColdFusion.  If it did, then consider this post an early Christmas present. 🎁  

Speaking at DistrictCon in January 2026 on Language-Level Vulnerabilities in Adobe ColdFusion

 

I'm thrilled to be speaking at DistrictCon in late January 2026.  My talk will cover some recent language-level vulnerabilities in ColdFusion that allow attackers to control variables that they should not be able to, allowing them to control application flow.  Often to scary results.  

Sandbox Security Escapes in ColdFusion and Lucee (CVE-2025-30288 and CVE-2024-55354)

Introduction

In this post I'm going to cover the technical details of a security sandbox escape technique that affects Adobe ColdFusion and Lucee Server.  These vulnerabilities are tracked as CVE-2025-30288 and CVE-2024-55354, and were announced in April 2025.  The resulting patches changed the default way that ColdFusion handled precompiled CFML (Java bytecode) in .cfm and .cfc files.

Before we get into the technical details, it's worth noting that an attacker needs to be able to write files to the server in order to exploit the vulnerability.  As a result, this vulnerability is primarily a risk to shared hosting environments where CFML sandbox controls are in use.  (If an attacker or malicious user can write files to your single-tenant environment, you probably have bigger, more immediate security concerns beyond sandbox escapes.)

Get ready for what I hope is an interesting trip through ColdFusion internals, some Java, and other technical depths.  This was a fun one to find, explore, and exploit. 

CFCamp 2025 Slides - Understanding CFML Vulnerabilities, Exploits, and Attack Paths

 In May I had the pleasure of attending my first CFCamp, where I spoke about CFML security.

The slides from my talk -- Understanding CFML Vulnerabilities, Exploits, and Attack Paths -- are now online below.  With an added bonus of Bavaria in Springtime!