The Risk

A remote code execution vulnerability allows an attacker to cause code of their own choosing to execute on your server.

This type of attack is just as bad as it sounds, it is a critical vulnerability that should be among your highest priority to mitigate.

Vulnerable Example

iif(len(url.name), de(url.name), de("Anonymous"))

The second and third arguments of the iif() function evaluate dynamically. This means that if the variable passed in to it contains CFML it can be executed.

In this example if the attacker passed Mr #getCurrentTemplatePath()# we would see the server file system path to the cfm or cfc file containing the iif code.

An IIF Example That Is NOT Vulnerable

iif( qry.currentrow == 1, de("First"), qry.currentrow )

Not all instances of iif are vulnerable to remote code execution. The second and third argument must contain a CFML variable, and the attacker would need to be able to manipulate its value.

In this example we are using qry.currentrow in the third argument, which is a variable, but it is always going to be an integer and it cannot be externally manipulated.

Due to the poor security and poor performance of the iif function in ColdFusion and Lucee it is recommended to remove them from your code using one of the mitigation techniques below.

Mitigating IIF RCE With The Ternary Operator

Our vulnerable example:

iif(len(url.name), de(url.name), de("Anonymous"))

Can be safely rewritten using the ternary operator:

len(url.name) ? url.name : "Anonymous"

Mitigating IIF RCE With an If Statement

Since iif (or inline if) is just a shortcut for an if statement, we can instead just rewrite our code to use a cfif in CFML tags or if within cfscript:

if (len(url.name)) {
    greeting = url.name;
} else {
    greeting = "Anonymous";
}

Or perhaps using CFML tags:

<cfif len(url.name)>
    <cfoutput>#encodeForHTML(url.name)#</cfoutput>
<cfelse>
    Anonymous
</cfif>

Note that we've added encodeForHTML here to avoid Cross Site Scripting (XSS) because we are outputting the variable.