Custom Content Type Manager Plugin Update Creates a Security Nightmare

Custom Content Type Manager Plugin HeaderOver the years, we’ve told users that the WordPress plugin directory is the safest place to download and install plugins from. This is due in large part to the dedication of volunteers who act as gatekeepers and review plugins before they’re added to the directory. Plugin updates, however don’t receive the same scrutiny as there’s too many of them.

Sucuri Security representative Denis Sinegubko, published an in-depth post that explains how an update to the Custom Content Type Manager plugin, which is active on more than 10k sites, turned into a security nightmare for some users. Custom Content Type Manager enables users to create custom fields for dropdowns, images, and more.

According to Sinegubko, a user by the name of Wooranker was added as a maintainer on February 5th. Wooranker is also listed as a contributor to the Postie plugin but according to its author, Wooranker does not and will not have access to change the source code. On February 19th, Wooranker pushed out an update that included the CCTM_Communicator.php file and inserted new code into the plugin’s index.php file.

On March 1st, MartinCDS created a thread in the plugin’s support forums and reported the following:

I recently updated a few of my sites and since then my site was hacked. According to my log files the code was injected via custom-content-type-manager/auto-update.php. I navigated there and there is a form input. Please fix this in the next update. I don’t see a reason for an automatic update anyways- this is a known vulnerability by hackers.

Other users also reported that their sites had been hacked due to the auto-update.php file. This file allowed the attacker to upload a c.php file into the plugin directory. The c.php file was used to create a more sophisticated attack shell named wp-options.php in the site’s root directory. The c.php file was deleted once wp-options.php was created, making it harder to detect.

Custom Content Type Manager is Fixed

Samuel ‘Otto’ Wood, who helps maintain, left a comment on the article acknowledging that the plugin has been fixed on the directory:

The plugin has been updated to, which is a copy of (the last good version). This will remove the malicious code from the plugin, but not any code that was added to sites in the meantime. Please follow through with the Mitigation steps given by Denis in the post.

To learn how the attack works, insight into who Wooranker may be, and to see a list of mitigation steps, I encourage you to read the post.

A Concerning Reminder

I feel bad for those who updated their plugins from a trusted source only to make their sites vulnerable to attack. Unfortunately, there is no way to prevent situations like these from occurring unless every line of code for each update is scrutinized by a security professional, but that doesn’t scale.

This doesn’t detract the trust I have for the WordPress plugin directory but users need to realize that what happened with Custom Content Type Manager can happen to other plugins as well. Your best defense is to use security scanning software of your choice that keeps track of file changes and to make routine backups.


20 responses to “Custom Content Type Manager Plugin Update Creates a Security Nightmare”

  1. There is only one way to make WordPress safe, but it’s never going to happen,because of marketing, and because the core developers are not serious about security (let the attacks and the propaganda begin).

    Let’s not consider server security for now, and just concentrate on WordPress. There are 3 areas of concern – the core, the plugins, and the themes. Even if the core is secure (which it never is, since the core gets constantly being patched, but let’s assume it is), NOTHING is being done about plugins and themes. I’m not necessarily mean those from the repository, which btw, in this case it came and caused a huge situation, but I’m specifically referring to third party sources. Even if those sources are trusted (is there such a thing?), those “secure & trusted” sources can be compromised as well, look what happened to Linux Mint 2 weeks ago.

    I said it a thousand times before, and I’ll say it again, since the core does not check for themes and plugins that are insecure to get activated, WordPRess is never going to be secure. So, if you try to activate a plugin or a theme, the core should check for security holes, and if it finds them, should refuse to activate the said plugin or the theme. At the repository, a big percentage of the plugins have security issues, which I can’t understand how they got approved to begin with. If you don’t believe me, download and run plugin tests with the “Plugin Inspector”, found at, and see it for yourself.

    As I said before, this is never going to happen, since WordPress is run like a big government. Quality takes the backseat to activity. They rather have activity (43,000+ plugins for example), as oppose to 10,000 quality plugins, that will not put your website in danger.

    There is no other way to maximize WordPress security, the core has to take action, and refuse any unsafe code to get activated. Until then, just like politicians and governments, everything else is just white noise, propaganda, and false sense of security.

    I have nothing against the core developers, the plugin and theme teams who approve them, they have tremendously huge and important jobs and I do admire and respect them, but at least admit the shortcomings, and finally do something meaningful about the security issues. After more than a decade of developing WordPress, this is almost embarrassing. Security issues like this, should have been a huge priority over things like distraction free writing and other meaningless things, as an example the new shortcuts proposals, and among countless other things… All the people who are really in charge, are 100 times more intelligent than me, so I’m sure this has crossed their minds, but chose to do nothing, while keep telling us WordPress is safe. The reality is that unless you code your own themes and plugins, your WordPress websites will never be safe, as it stands today.

    • I feel like it would be practically impossible for core alone to look through source-code of plugins and themes to pin-point specific security holes. Hackers are clever in that they can obfuscate code or just hide it in plain site as a “feature”. The amount of false-positives would be astronomical which would cause aggravated users and an unfriendly end experience.

      While that plugin you listed is nice it also seems fairly generic in what it looks for. Maybe the best thing is does it checks against WPScan Vulnerability Database but that looks for already known vulnerabilities which, even if added to core, who knows how many websites would be infected before the vulnerability is reported to the WPSV DB.

      I’m by no means a security expert but it sounds impractical to implement a lightweight be-all and end-all security fix solution to core.

  2. I like to quote Mario Peshev

    code itself does not matter at all

    . That’s why I use/buy a developer, not code.
    If a plugin is not updated for almost a year, that does not give me much comfort about stability, security or compatibility in the future.

    Maybe plugin’s team can check updates by “untrusted” and new maintainers more. Plugin’s directory contains a lof of old, broken and junky plugins. For average user’s eyes – it’s broken WordPress, not a plugin.

    Also required a detailed changelog with each update, which has to match the changes in the code can help to prevent this in the future.

  3. In the case of plugins, there are only three people on that team I think. And automating security checks is just like automating accessibility checks. You might catch some legitimate things, but for every one legitimate thing, there would be at least five false positives that would have to be checked. So how exactly, given the number of people on the plugins team, who do this in their spare time, does the magic happen that keeps stuff like this from happening again?

    • false positives are probably not a bad thing when it comes to security. As such tool will look for shady code It will probably indicates bad coding practice even if not actual security problem.

      plugins that fail the test are simply rejected, it should not generate more work for the plugins team.

      • Totally agree with you, and bad coding is almost as bad a shady coding. Bad coding is the main reason why there are so many plugin conflicts that cannot co-exist with each other. But as I said above, nothing will be done.

  4. The lack of any real screening in the plugins directory is WordPress’s single biggest security gap. Anyone who has a plugin on there knows how easy it would be to add malicious code.

    The lack of oversight is somewhat baffling to me. Our community is this big, the plugins directory is this active, and all we have are a couple volunteers maintaining it?

    You would think Automattic would be willing to lend some resources. It’s certainly in their interest to make sure WordPress doesn’t develop more of a reputation for having security issues.

    Meanwhile the theme review team has become incredibly strigent over the past few years. Why can’t the same be true for plugins? There is a ton of cruft in there currently. A little more oversight would lead to slower updates and heavier curation but I think that’s a tradeoff most people would welcome.

      • That is awesome Otto, thanks for that. This is exactly what I’m talking about, about being serious, and things are like a big government!

        How is expanding the team going to make the plugins 100% safe? Can you guarantee 100% safety, even just for the repository plugins? You simply can’t, there are always going to be those insecure plugins that will fall through the cracks. And how are we going to be protected from third party plugins, like from Envato and elsewhere? Even if the repositories are 100% cleaned up, WordPress itself will still remain unsafe.

        Some people suggested that by doing what I suggested (look first reply above, WordPress not allowing unsafe plugins and themes to get activated), we might get a lot of false positives. And they might be right, but there is an easy solution for that too. The site admin can overwrite the core’s decision in not activating a certain theme or plugin, especially if it gets a false positive. And trust me, even with false positives, it will force the plugin developers to write cleaner codes.

        I can’t see any other way to make WordPress secure. Your answer to this overall WordPress security issue proves one my points exactly. Let’s face it, the people in charge are simply not serious about security, because what you are doing with the redesign is simply not enough, not by a longshot. And by saying otherwise, it’s really insulting to me, since it questions my level of intelligence.

        In fact, if WordPress does what I’m suggesting, you don’t have to expand the team, in fact you don’t even have to monitor anything, because unsafe plugins won’t be able to be used anyways, since WordPress will refuse to activate them. Again, this will never happen, since it makes too much sense, and like governments, we don’t like results, just meaningless activity, and the false sense of something is being done, while in the meantime the opposite is the truth.

        I want to sincerely apologize for my brashness, I need to get attention to this subject (and hopefully not me). I want someone in real power, to get what I’m suggesting, and run with it and get 100% credit for it too, and forget even my existence. I really hope Otto, that person is you, I have read many of your posts in the past, and I think you are one of the people I need to grab attention to this very serious problem.

        • Mobile, so short post.

          There is no way for one set of code to determine if another set of code will even ever stop running. Look up the “Halting Problem”.

          If you have some sort of magic black box code that can determine “safety”, then by all means, present it. Otherwise, consider that anything we add to core to prevent something can be bypassed by something more clever. What you’re suggesting is a never ending arms race that solves nothing.

  5. I knew I had the right person for this… thank you for the reply, and thank you for being nice, I was expecting a drone outside my window to be honest…

    You make a very valid point, regarding the arms race. But isn’t it better to have even an arms race, over doing nothing? Then why bother about patching the core? Every time we get an update, 2-3 weeks later, we get a sub-version, that has bug fixes, and security fixes. Isn’t that an arms race? In a real life analogy, what good is it to secure the airports and the ports, when people can simply drive through the borders?

    As far as solutions go, how about for starters, making the Plugin Inspector, and the theme check plugin as feature plugins (so merge them with the core), and at the very least warn the site admins that a certain plugin or a theme is not safe, when trying to get activated. The only ways to bypass this and beat the system would be actually to hack the core, or the server, unless the site admin activates an unsafe theme or plugin despite the warnings. And as an added bonus, plugin and theme developers will have to start coding the right way, (to avoid the warnings) – the WordPress way. I have one thousandth of your expertise and I have no idea what type of technical limitations you might encounter, but isn’t this important enough to at least think about this, over distraction free writing, and the syntax of shortcodes? Am I the only one who thinks this way?

    I mean no disrespect, I am just very passionate about security…

    • To be fair, at some point Microsoft had to include virus and malicious code scanning into Windows, I’m not sure we’re there yet with WordPress, but we do have an enormous target on our backs and find ourselves in a similar situation.

        • @trevor, think about your windows machine (or about some unlucky guy like me using one ;) ) Once you have installed some software as root, it has the capability to hide itself from any anti virus scan, and to root itself so hard in the OS, nothing less of a format will be enough to take it out.

          At WP once something is on your server, it might be an attack vector even if it was not activated as a plugin, and once it is active, it can suppress all notifications. You can not check the plugin at activation because the plugins code already runs then, and it is actually very easy to write a plugin with a back door that will comply with whatever coding standard you want.

          (I assume that Otto here means that by distributing the check code you are exposing the coding standard and helping the bad guys test their malware against it. If it is so then it smell like security by obscurity which has its merits, but usually is considered a bad idea).

          To have a proper security against something you have already installed on your machine, you need the OS to supply facilities against it, because usually applications can not obstruct the way the OS works. If you heard about “secure boot” this is one effort in that direction.
          The equivalent in wordpress would be for PHP to provide such facilities, and as long as it doesn’t there is very little little you can do.

          Modern OS like IOS and android do not AFAICT even try to detect malware on the machine and rely on off machine security related acceptance testing.
          WordPress here actually follow industry standard and I assume that if apple and google did not find a way to detect malware after it is installed, it will be unrealistic to expect Otto and the small group of people helping him to come up with a better scheme.

          It is not like nothing can be done at all, but engineering a system in which plugins do not “run” as root and therefor can be monitored by wordpress core is very far from being trivial, and will probably require changes in most plugins in addition to the changes done in core.

        • Plugins are PHP files that are simply included by WordPress. They can do anything WordPress can. There is no sandboxing of the code they can run.

          So, suggesting that core “scan” the file for malicious code is not helpful, because to date, nobody has actually created anything that can actually “scan” for maliciousness. Virus scanners and the like rely on “signatures” and other similar types of mechanisms to identify already known sets of code. Some have heuristic mechanisms to identify possible bad code, however such methods are not very good and have frequent false positives.

          The short of it is that there is no way to check for “intent”. I can write a piece of code that includes a script from a third party site. Is that good or bad? The script could be to include a Facebook sharing button, or it could include a piece of javascript that steals your authentication credentials. How do you know that it’s bad? Do you scan that script? What if I make it such that it only returns the bad script when it’s included by a very specific site?

          For any type of “scan” you could perform in an automated manner, somebody else can usually trivially modify their code to pass the test. Thus, making the scan public knowledge is not useful to protect against bad actors.

          Theme Check, for example, does not have the primary purpose of making themes safe, it has the purpose of helping theme authors make sure they didn’t forget anything. In that respect, it doesn’t need to be a secret, it actually needs to be public information. If we write a Plugin Check, it’s not going to try to detect malicious code either. It’s going to check for things like copyright info, incompatible licenses, use of code that can cause incompatibilities, things that will help plugin authors improve their plugins. Any “security” checks it does will be fairly meaningless. We can do things like checking for unescaped inputs and such, but even then it’s going to have false positives. No check is perfect.

          And nothing “built into core” will secure your site from a malicious plugin that you actually install and turn on yourself. We don’t have a PHP sandbox environment to work with, and there’s no real plans to create one. The best defense is simply one of trust. Don’t install plugins and themes from untrustworthy sources. If you find something bad in the official directories, you can email us about it and we’ll take actions to mitigate the problem, fix up sites, ban those authors, etc. We do it on a regular basis. We get reports of security issues in plugins all the time. We get the plugins fixed and updates pushed. Reporting and rapid mitigation is the strategy here.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: