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

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

Speakers: Brian Reilly, Security Researcher, tech company in the entertainment space

Conference: DistrictCon

YouTube: https://www.youtube.com/watch?v=R8H0C56HDEA

Overview

In this DistrictCon presentation, security researcher Brian Reilly delivers a deep dive into several language-level vulnerabilities he discovered within Adobe ColdFusion, culminating in multiple credited CVEs. Titled "Control the Variables and You Control the Code," the talk exposes how attackers can subvert the intended flow of ColdFusion applications by manipulating how variables are resolved and assigned, even in contexts traditionally considered secure. Reilly, a seasoned security engineer and exploit developer, emphasizes the pervasive nature of Adobe products in enterprise environments, making understanding their inherent vulnerabilities crucial for both red teams and defenders.

The talk focuses on a narrow but impactful sliver of ColdFusion's vast attack surface: the often-overlooked mechanisms of variable scoping and function argument handling. Reilly demonstrates how attackers can leverage these quirks to achieve mass assignment of sensitive values, bypass security checks, and even trigger Server-Side Request Forgery (SSRF). His research highlights a critical lesson in application security: user input, even when seemingly indirect or deeply nested, must always be treated as untrusted, especially in complex, legacy platforms like ColdFusion that have evolved over decades with multiple architectural shifts.

Reilly's findings underscore the enduring challenges posed by legacy systems in modern security landscapes. Despite significant efforts by vendors like Adobe to patch vulnerabilities, the inherent complexity and historical design decisions of platforms like ColdFusion can lead to subtle yet powerful bypasses. The talk serves as a vital resource for security professionals, offering detailed technical insights into these vulnerabilities and practical guidance on identifying, mitigating, and defending against similar classes of attacks within ColdFusion and beyond.

Background

▶ Watch: Introduction to ColdFusion vulnerabilities and talk scope (0:00)

Adobe ColdFusion, a web development platform with a history spanning over 30 years, presents a unique security landscape due to its extensive legacy and architectural evolution. Originally developed in C and C++, ColdFusion underwent a significant rewrite in Java in 2002, and was subsequently acquired by Adobe in 2005. This long history and underlying Java architecture contribute to its considerable complexity and, as Reilly demonstrates, a fertile ground for nuanced vulnerabilities. While Adobe ColdFusion is the primary focus, other CFML engines like the open-source Lucee also exist, though they are not the subject of this specific research.

ColdFusion applications can be written in either a tag-based syntax, resembling HTML, or a script-based syntax, similar to other modern scripting languages. Regardless of the syntax, ColdFusion code is ultimately compiled into Java class files, which are then executed by the ColdFusion engine. The Java compilation process also means that these class files can often be easily decompiled back into a readable Java representation, aiding security researchers in understanding the underlying logic.

A core concept in ColdFusion is scopes, which define the context or "bucket" where variables reside. Critical to understanding the discussed vulnerabilities are the distinctions between user-controlled and trusted scopes:

• User-controlled scopes: These include the URL scope (parameters from the URL), Form scope (data from form submissions), and Cookie scope (cookie data). Values within these scopes are inherently untrusted and can be manipulated by an attacker.
• Trusted scopes: Examples include the Application scope (static, global application variables) and Server scope (server-level configuration). These are traditionally considered trusted sources of data, meaning a user should not be able to directly control their values without an underlying vulnerability.
• Argument scope: This special scope stores the arguments passed to a function. As Reilly's research reveals, its interaction with other scopes is a primary vector for the vulnerabilities discussed.

Historically, ColdFusion has grappled with the concept of unscoped variables. If a variable is referenced without an explicit scope (e.g., myVar instead of URL.myVar), the ColdFusion engine searches for it in a cascading order of scopes: local, then argument, variables, CGI, file, URL, form, cookie, and finally client scope. This search order, particularly the inclusion of user-controlled scopes like URL, form, and cookie late in the chain, historically led to a well-known vulnerability type called scope injection. An attacker could, for instance, set isadmin=true in the URL, and if the application implicitly checked for an unscoped isadmin variable, it would find the user-supplied value, potentially granting unauthorized access. Adobe addressed this by disabling implicit variable searching by default in a 2024 patch.

ColdFusion functions also play a crucial role. Functions have an access parameter that controls how they can be called:

• Private, Package, Public: These functions require server-side code to call them; a user cannot interact with them directly.
• Remote: These functions can be called directly via a URL, much like an API endpoint. A default ColdFusion installation often includes many remote CFCs (ColdFusion Components). Remote functions have been historically associated with various vulnerabilities, including XXE (XML External Entity) and Java deserialization issues, even if the function itself isn't inherently flawed.

Beyond individual arguments, ColdFusion also supports a special variable called argumentCollection. This allows all function arguments to be passed as a single structured object, either a JSON object or a WDDX packet (an XML-like data structure). The interaction of argumentCollection with variable resolution and scoping rules forms the bedrock of Reilly's findings.

The overarching theme of Reilly's research falls under the category of mass assignment vulnerabilities. This class of vulnerability, not unique to ColdFusion, occurs when a user can set values for application variables that they should not be able to control. If these variables are then used in a security-sensitive context (e.g., controlling authentication state, encryption keys, access permissions), the impact can be severe. Mass assignment has been observed in various languages and frameworks, including ASP.NET, PHP, and Node.js, highlighting it as a common design flaw when handling user input and object population.

Key Findings

▶ Watch: Understanding Mass Assignment vulnerabilities in ColdFusion (8:15)

Brian Reilly's research uncovered several critical language-level vulnerabilities in Adobe ColdFusion, primarily revolving around how the platform resolves variables and processes function arguments. These findings demonstrate how an attacker can subvert core application logic by injecting values into scopes intended to be trusted.

1. Mass Assignment via argumentCollection in Remote Functions:

• Vulnerability: Reilly discovered that when a remote function accepted an argumentCollection, variables passed within this collection could overwrite values that were intended to be sourced from trusted application scopes. For example, a function checking application.env could be tricked into using a user-supplied env value from the argumentCollection instead of the legitimate application scope variable.
• Impact: This allowed attackers to bypass environmental checks or manipulate application behavior based on a controlled "trusted" variable.
• Resolution: Adobe patched this vulnerability in November 2023. However, researchers subsequently found a bypass, which Adobe also addressed.

1. **Three-Level Variable Resolution Bypass (CVE-2025-XXXXX - Note: Speaker stated August 2025 patch, implying a future CVE or a typo in date)**:

• Vulnerability: Reilly observed a distinct and exploitable difference in how ColdFusion resolves variables based on their nesting depth. While two-level variables (e.g., application.productversion) were strictly resolved from their defined scope, variables with three or more levels (e.g., server.coldfusion.productversion) followed a different code path. This alternative path, utilizing a function named resolveSplitNames, prioritized the argument scope in its search order. Consequently, an attacker could supply a value like server.coldfusion.productversion in the argumentCollection of a remote function, and the application would use this user-controlled value instead of the legitimate server-side variable.
• Impact: While server.coldfusion.productversion itself might not be sensitive, this mechanism allowed control over any three-or-more-level variable, potentially impacting critical application logic related to user roles, session management, or other security-sensitive configurations.
• Resolution: This vulnerability was fixed in August 2025 (as stated by the speaker, implying a future patch or a date discrepancy in the transcript). The fix involved strictly typing function arguments, requiring explicit definitions, which was noted as a significant breaking change for applications relying on dynamic argument passing.

1. Blind SSRF via Three-Level Resolution:

• Vulnerability: As a concrete example of the three-level resolution bypass, Reilly highlighted a Blind Server-Side Request Forgery (SSRF) vulnerability within the ColdFusion administrator. The checkFileExists method, used for downloading patches, relied on application.updateSettings.downloadHomePath, a variable set in a server-side configuration file. Using the three-level resolution technique, an attacker could overwrite application.updateSettings.downloadHomePath with an arbitrary URL or file path.
• Impact: The ColdFusion server would then attempt to fetch content from the attacker-supplied location, leading to a blind SSRF. While not high-impact in this specific context, it demonstrated the real-world applicability of the variable resolution bypass.
• Resolution: This specific SSRF vulnerability was patched concurrently with the broader three-level resolution fix in August 2025.

1. **Mass Assignment via User-Controlled argumentCollection in Local/Public Functions (CVE-2025-XXXXX - Note: Speaker stated December 2025 patch, implying a future CVE or a typo in date)**:

• Vulnerability: Beyond remote functions, Reilly discovered that even local, public, or private functions could be vulnerable if they explicitly obtained their argumentCollection from a user-controlled scope, such as the form scope. The ColdFusion documentation itself highlighted that an entire user-controlled struct could be passed as argumentCollection. If an application then used argumentCollection to populate variables, it could inadvertently use user-supplied values for sensitive data.
• Impact: This enabled attackers to manipulate internal function logic and variables, even in functions not directly exposed as remote endpoints. Reilly demonstrated this by overwriting server.os.name by supplying it within a form-based argumentCollection.
• Resolution: This vulnerability was patched in December 2025 (as stated by the speaker, implying a future patch or a date discrepancy in the transcript). The fix included changes to the default scope resolution process and introduced reserved words, preventing built-in scope names from being used as function arguments. This was also a breaking change for applications that relied on such dynamic behavior.

These findings collectively highlight deep-seated architectural assumptions within ColdFusion regarding variable trust boundaries and resolution mechanisms, demonstrating how seemingly innocuous features can become powerful attack vectors.

Technical Deep Dive

▶ Watch: User-controlled argument collection in non-remote functions (14:30)

The core of Brian Reilly's research lies in the intricate and sometimes counter-intuitive mechanisms ColdFusion employs for variable resolution and argument passing. The vulnerabilities he uncovered exploit specific code paths and search orders within the ColdFusion engine, allowing user-controlled input to subvert intended application logic.

The initial mass assignment vulnerability in remote functions stemmed from ColdFusion's handling of the argumentCollection. When a remote function is invoked, and arguments are supplied as a JSON object or WDDX packet via argumentCollection, the ColdFusion engine processes these values. If an application's code then attempts to access a variable, say application.env, but a key named env is present within the argumentCollection, the engine, under certain conditions, would prioritize the user-supplied env from the argumentCollection over the legitimate env from the application scope. This effectively allowed an attacker to "inject" their own value for env, bypassing the application's intended environment check. This behavior, while patched, revealed a fundamental flaw in how ColdFusion reconciled identically named variables across different scopes when argumentCollection was in play.

The second, more nuanced vulnerability involved the distinct code paths for variable resolution based on the "depth" of the variable name. Reilly observed that ColdFusion internally differentiates between resolving variables with two levels (e.g., scope.variableName) and those with three or more levels (e.g., scope.subscope.variableName).

• For two-level variables, the resolution process was relatively straightforward: the engine would look for variableName directly within scope. If application.env was referenced, it would strictly retrieve the value from the application scope.
• However, for variables with three or more levels, the engine invoked a different internal function, resolveSplitNames. This function would parse the dot-separated variable name (e.g., server.coldfusion.productversion) and then initiate a scope search order. Crucially, this search order, when triggered by a function call, prioritized the argument scope. This meant that if an attacker passed server.coldfusion.productversion as an argument (either individually or within an argumentCollection) to a remote function, the resolveSplitNames function would first find the user-controlled value in the argument scope before looking elsewhere. This allowed an attacker to effectively "spoof" the value of deeply nested variables that the application assumed were derived from trusted server-side configurations.

The impact of this three-level resolution bypass was clearly demonstrated by the blind SSRF in the ColdFusion administrator. The checkFileExists method relied on application.updateSettings.downloadHomePath to determine the source for downloading updates. Since application.updateSettings.downloadHomePath is a three-level variable, it fell victim to the resolveSplitNames vulnerability. By supplying a malicious URL or file path for application.updateSettings.downloadHomePath in a function call, an attacker could force the ColdFusion server to make an outbound request to an arbitrary location, thus achieving SSRF. The "blind" nature implies the attacker might not see the response, but the request itself confirms the vulnerability.

Adobe's fix for the three-level resolution vulnerability was significant: they implemented strict typing for function arguments. This means that all arguments passed to a function must now be explicitly defined with their data types. This change prevents the dynamic insertion of arbitrary variables into the argument scope, thereby closing the loophole exploited by resolveSplitNames when encountering undeclared arguments. However, Reilly noted that this was a "breaking change" for many existing ColdFusion applications that relied on more dynamic or implicit argument handling.

Finally, Reilly addressed the vulnerability of mass assignment in local/public/private functions. While previous examples focused on remote functions, this finding showed that even internal functions could be compromised. The key here was when a function explicitly obtained its argumentCollection from a user-controlled scope, such as form. The ColdFusion documentation itself supported passing an entire user-controlled struct (ColdFusion's equivalent of a dictionary or map) as an argumentCollection. If an application's public or private function was designed to accept argumentCollection and populated it directly from form data without sanitization, an attacker could then supply values for any variable expected by the function. Reilly illustrated this by showing how server.os.name could be overwritten. When the function then accessed server.os.name, it would retrieve the attacker-supplied value from the argumentCollection (which was populated from the form scope), rather than the actual operating system name from the trusted server scope.

The patch for this last vulnerability involved two main components:

1. Modified default scope resolution: Changes were made to how the engine resolves variables, likely prioritizing explicit scope declarations or trusted scopes more rigorously.
2. Reserved words: ColdFusion introduced a list of reserved words, essentially preventing developers from using the names of built-in scopes (like server, application, form, url, etc.) as function arguments. This directly prevents an attacker from supplying a variable named server.os.name via argumentCollection if server is a reserved word for arguments. This, too, was a breaking change for applications that might have inadvertently used such names.

In essence, Reilly's research exposes how ColdFusion's dynamic nature and complex variable resolution logic, designed for developer convenience, can be weaponized when trust boundaries between user input and internal application state are blurred. The vulnerabilities highlight the perils of implicit variable handling and the critical need for explicit validation and strict typing, especially in legacy systems.

Demo / Proof of Concept

▶ Watch: Two-step process to identify ColdFusion application vulnerabilities (16:10)

While Brian Reilly's talk did not feature a live, interactive demonstration, he effectively illustrated each vulnerability with clear, concise code examples and their corresponding proof-of-concept (PoC) outputs. These "contrived code" snippets served as highly effective demonstrations of the underlying technical mechanisms.

For the initial mass assignment vulnerability in remote functions, Reilly presented a simple ColdFusion Component (CFC) function designed to check an environment variable:

He explained that if an attacker called this remote function and supplied argumentCollection={"env":"dev"} (e.g., via JSON in the request body), the application.env check would mistakenly resolve to the user-supplied "dev" value, even if the actual application.env variable was set to "prod" in the server's configuration. This demonstrated the successful bypass of an environment check.

The three-level variable resolution bypass was illustrated with a low-impact but highly indicative example: the getBuildNumber method from ColdFusion's admin API. This method's intended purpose was to retrieve server.coldfusion.productversion. Reilly showed that by simply fuzzing this endpoint with a user-controlled server.coldfusion.productversion supplied as an argument, the provided value was echoed back. This was "really, really strange" because it shouldn't be possible to directly influence a server-scope variable. This simple echo confirmed that the user-supplied value was being prioritized over the legitimate server-side variable due to the resolveSplitNames function's search order.

A more impactful example of the three-level resolution bypass was the blind SSRF vulnerability. Reilly described the checkFileExists method, which relied on application.updateSettings.downloadHomePath. He explained that application.updateSettings.downloadHomePath is a three-level variable. An attacker could craft a request that supplied their own arbitrary URL or file path for this variable. When the checkFileExists method was then invoked, it would use the attacker-controlled downloadHomePath to initiate an outbound request, demonstrating a functional SSRF.

Finally, for the mass assignment in local/public/private functions, Reilly provided an example of a public function that accepted argumentCollection from the user-controlled form scope:

He showed that without tampering, the function would print "Hello, Guest!" and the actual server OS name. However, if an attacker submitted form data including name=Attacker and server.os.name=MaliciousOS, the function would print "Hello, Attacker!" and "Server OS: MaliciousOS". This clearly demonstrated that even non-remote functions, if they dynamically consume user-controlled data into argumentCollection, can be tricked into using attacker-supplied values for seemingly trusted variables like server.os.name.

These illustrative examples, though not live demos, were highly effective in conveying the exact mechanics of each vulnerability and their potential impact, serving as strong proof-of-concept cases for Reilly's findings.

Defensive Implications

▶ Watch: Methodology for finding scope injection vulnerabilities via code review (21:00)

The vulnerabilities highlighted by Brian Reilly in Adobe ColdFusion carry significant defensive implications for organizations operating these legacy systems. The core message is clear: user input, no matter how indirect or deeply nested, must always be treated as untrusted, and architectural assumptions about variable trust boundaries must be rigorously re-evaluated.

1. Aggressive Patch Management is Mandatory: The most critical defensive measure is to ensure all ColdFusion environments are running the absolute latest patch releases. As Reilly and the conference host emphasized, ColdFusion, like many legacy platforms, has a long tail of vulnerabilities, with 10-15 year-old bugs still being exploited in ransomware campaigns. Adobe's patches, while sometimes introducing breaking changes, are essential. Organizations must prioritize patching, even if Adobe's update process is perceived as difficult. This is not optional; it's a fundamental requirement for maintaining a secure posture.

1. Rigorous Code Review for Argument Handling:

• Remote Functions: Any function with access="remote" should undergo intense scrutiny. These are direct API endpoints exposed to potential attackers. Developers must meticulously review how these functions handle argumentCollection and how variables passed within it interact with other application scopes.
• Local/Public/Private Functions: Even internal functions are not immune. Defenders must identify any function that obtains its argumentCollection from user-controlled scopes (e.g., form, url, cookie). These functions are susceptible to mass assignment even without being directly callable via a URL.
• Variable Resolution: Pay close attention to how variables are resolved, especially those with three or more levels of nesting (e.g., scope.subscope.variable). If these variables are used in security-sensitive contexts (authentication, authorization, encryption, file paths), and their values can be influenced by user input, they represent a high risk.

1. Strict User Input Validation and Sanitization: This is Security 101, but it bears repeating. All user input, regardless of its source (URL, form, cookies, JSON, WDDX), must be strictly validated against expected formats, types, and allowed values. This can help filter out malicious attempts to inject arbitrary values into sensitive variables before they reach the vulnerable ColdFusion engine logic. If a parameter is expected to be a simple string, it should not be able to contain a complex object or a dot-separated path.

1. Understand and Plan for Breaking Changes: Adobe's patches for these vulnerabilities involved significant breaking changes, such as strictly typing function arguments and introducing reserved words for argument names. Defenders and development teams must be aware of these changes, plan for necessary code refactoring, and thoroughly test applications after applying patches to ensure continued functionality and security. Ignoring these changes can lead to either an unpatched system or a broken application.

1. Layered Security with WAFs and Other Mitigations: While application-level fixes are paramount, a Web Application Firewall (WAF) can provide an additional layer of defense. WAFs can be configured to detect and block suspicious patterns in requests, such as attempts to inject dot-separated variable names into unexpected parameters or the presence of structured data (JSON/WDDX) where simple values are expected. However, WAFs are not a silver bullet and should complement, not replace, patching and secure coding practices.

1. Source Code Review for Deep-Seated Bugs: As Reilly noted, finding these types of language-level vulnerabilities often requires access to source code and detailed analysis of decompiled Java class files. Organizations with ColdFusion applications should conduct regular, in-depth source code reviews, specifically looking for patterns identified in this talk: dynamic argumentCollection usage, implicit variable resolution, and sensitive variables that could be manipulated.

1. Isolate and Segment Legacy Systems: If patching or refactoring legacy ColdFusion applications is exceptionally challenging, consider isolating them within the network. Implement strict network segmentation, limiting inbound and outbound connectivity to only what is absolutely necessary. This reduces the attack surface and potential impact if a vulnerability is exploited.

By adopting these defensive strategies, organizations can significantly reduce their exposure to the types of sophisticated language-level attacks demonstrated by Brian Reilly, safeguarding their ColdFusion applications from potential compromise.

Key Takeaways

• ColdFusion's Complexity is an Attack Surface: The platform's 30-year history, Java rewrite, and intricate variable scoping rules create a complex environment ripe for subtle, powerful vulnerabilities.
• User Input is Always Untrusted: Even when seemingly indirect or deeply nested within argumentCollection or multi-level variable paths, user-controlled data can subvert core application logic if not rigorously validated and handled.
• Language-Level Quirks Can Break Trust Boundaries: Distinct code paths for variable resolution (e.g., two-level vs. three-level variables) and dynamic argument handling can be exploited to bypass security assumptions and inject malicious values into trusted scopes.
• Mass Assignment is a Persistent Threat: This class of vulnerability, where attackers can set values for variables they shouldn't control, continues to appear across various platforms, including ColdFusion, with significant security implications.
• Patch Management for Legacy Systems is Non-Negotiable: Given the long tail of vulnerabilities in platforms like ColdFusion, keeping systems fully patched is the most critical defensive measure, despite potential challenges like breaking changes.
• Source Code Review is Essential for Deep Bugs: Identifying and understanding these language-level vulnerabilities often requires in-depth source code analysis rather than relying solely on black-box testing.

About the Speaker(s)

Brian Reilly is a highly experienced security engineer and researcher with approximately 25 years in the industry. In his day job, he leads a small security team at a technology company within the entertainment space. Independent of this role, he conducts independent security research and private consulting, with the insights shared in this talk being a result of this independent work.

Reilly's career has a strong focus on ABSSAC (Application Security Assurance and Compliance) and offensive security, demonstrating his expertise as a skilled exploit developer with significant operational time "on keyboard." He also possesses considerable experience in defensive security response, giving him a well-rounded perspective on security challenges. His early career involved supporting higher education and state and local government sectors, providing him with an understanding of the unique obstacles faced by organizations in those verticals. More recently, his experience has concentrated on the tech and financial services industries. Brian Reilly has previously presented his research at various security conferences, including SummerCon and Bsides LV.