Recently, we’ve seen a flurry of hacks here at Byte HQ. We’ve had to disable a lot of sites due to a new kind of exploit being abused. We haven’t seen these kinds of exploits before, but it always was a matter of time before someone tried a more intelligent approach to breaching sloppy PHP applications 🙂


Try this:

This reads all environment variables, and evaluates them in php5.
If one of the variables contains php code marked with <? – it will be executed:


First line is some rubbish, but the second: it is the output of a system command. In this case ‘echo’ but it could be more malicious.

In practice

To validate a file name many component developers for Joomla use the JRequest::getVar($varname) function.

It fetches the GET/POST request variable $varname and cleans it up. The problems arise when the function is incorrectly used:

The POST variable controller is validated using getVar(‘controller’) and then used as a file name.
Unfortunately getVar() doesn’t filter the input properly. It allows slashes and dots, so any path can be put in the $controller variable, e.g.:

Notice the final null character. It causes the ‘.php’ extension to be omitted by require_once.

Exploting the bug

    1. make a HTTP request to a Joomla website with a buggy component and set a environment variable to contain some php code. This can be done, e.g., by setting specifying a strange user agent:

    1. specify as [ADDRESS] a url with variable ‘controller’ set to the appropriate path.
    2. Joomla+buggy module+php5 will do the rest:

Solution 1: Patch the component

Patch your buggy module to use getCmd instead of getVar.

According to the documentation: getCmd() is a proxy to getVar(), but it sanitizes the
variable to contain only letters and other appropriate characters for use in filenames.

For example:

Solution 2: Patch Joomla

If you have a LOT of modules installed and you are willing to take your chances with file uploads, then you can also choose to patch the _cleanVar() function in libraries/joomla/environment/request.php:

Best solution 🙂 : Host at

Since discovering these hacks, at Byte we’ve decided to mitigate the attack system-wide. On March 22 we’ll patch PHP so these and future hacks that use the environment won’t work at all. 🙂


Some people may argue if it is a Joomla bug or if the modules are written inappropriately. Actually it doesn’t matter:

  • yes, the module is written inappropriately
  • but Joomla makes it very easy to write an inappropriate module.
  • tomato is a fruit

A short list of components that are reported to be unsafe (or have been unsafe):

  • com_myblog
  • com_rwcards
  • com_rokdownloads (update available!)
  • com_gcalendar (update available!)
  • com_sectionex
  • com_ninjarsssyndicator (update available!)
  • com_ckforms
  • com_svmap

Inappropriate cleaning of request variables in Joomla

Scan je eigen Magento shop op veiligheidslekken