1. Adel

    I have 7 sites with WP GDPR Compliance and they were all hacked – new admin users + a few uploaded scripts-
    All of them had Wordfence premium installed but it didn’t stop the attack :(


  2. Plugin Vulnerabilities

    What happened there is a good reminder of the usefulness of making sure plugins are up to date at all times, which you can set WordPress to do for you, since that would have protected websites from being hacked, where even something like Wordfence’s paid service Wordfence Premium didn’t stop websites from being hacked.

    You are behind in these vulnerabilities though, since we full disclosed a vulnerability of the same type in the plugin Kiwi Social Share, which has 30,000+ installs, earlier today. Anyone using that plugin would want to disable that plugin until a fix is released, since as that other vulnerability shows, that type of vulnerability will be exploited. We only full disclosed that vulnerability instead of working with the developer to fix it before disclosing it due to the WordPress teams’ continued refusal to clean up the inappropriate behavior of the moderators of the wordpress.org Support Forum.


  3. John

    Van Ons said they requested the Plugin Directory team do a forced update but they said it was not an option in this case.

    It would be good to know why? Didn’t WordPress.org already force update for a few plugins because of security issues?


    • Otto

      We didn’t say a forced update wasn’t possible, just that it would not have helped. They released the update a day earlier. By the time this was asked for, a third of the sites had already been updated. The timeline of updates is something we know very well, and since the exploiting was already underway, forcing it would not move the needle any faster.

      It isn’t that we can’t, it’s that it was too late. You need to plan for forced updates before releasing the fixes.


      • Quick Math Matt

        Currently 13% of active installations are 1.3.x or older.

        The plugin has 100k+ active installations, 78k downloads during last week, that’s about since the incident.

        That means at least 22k are not at latest version yet, at least 9k of those are in 4.x.

        Result of quick math:

        An absolute minimum of 9k sites can still be taken over completely due to this vulnerability.

        Maybe over 22k sites, if the vulnerability also exists in 1.3.x version.

        The actual still vulnerable number is higher, the unknown real number behind 100k+ is actually more than 100k.


      • Otto

        “Forcing” an update doesn’t actually “force” anything. We don’t actually control individual WordPress sites. Consider that in your flawed math.


      • Plugin Vulnerabilities

        Your team should have been the ones planning for forcing the update before it was released, seeing as the plugin was a possible vector for a previous exploitation and it had at least two vulnerabilities that were fixed that were likely to be exploited.

        There is the additional big issue with that process currently, which is that you are providing the new version of the plugins to hackers before websites can easily upgrade to it, since the new version gets added to the Subversion repository while the plugin is stilled closed. It usually is easy to work back from the changes being made to how to exploit the vulnerability being fixed if you know what you are doing.

        You really need to bring in additional people that have a better understanding of security or be willing to work with others, like us, that have a better understanding of it, so that your processes can be improved, because right now your team is making mistakes that should be easy to fix. Not just with this, but, for example, with your failure to make sure your manual security reviews of new plugins before they are allowed in the Plugin Directory don’t miss easy to spot exploitable vulnerabilities (we have repeatedly offered to help your team with that).


  4. Rasmus Jürs

    Oh, the irony…

    Government forces every website to implement complicated user and consent management.

    This forces even the most basic website to implement ways for users to accessing their information.

    The extra layer of user consent management makes basic websites orders of magnitude more open to unauthorised access.


  5. Daniel James

    I don’t understand what this plugin does that you can’t already achieved with the plugins it’s supposedly supports. You can ‘become compliant’ with the likes of Contact Form 7 and Gravity Forms by adding checkboxes with privacy statements in their respective form builders and ensuring you handle user data correctly and safely.

    From what I’ve read, this plugin just adds another layer on top of these contact form plugins (plus WooCommerce) which seems to just add complexity and in this case scenario, a vulnerability that could have been avoided.

    Van Ons said they requested the Plugin Directory team do a forced update but they said it was not an option in this case.

    I’d imagine this may have something to do with the fact that auto updating the plugin may have masked the need for some people to do a full post-mortem of the hack they suffered and left admin accounts and scripts lying around. I don’t see any other reason to prevent an auto update to affected sites.


    • Not Evil

      About time, there are more targets around just waiting. Lots of bad coded no-extra-value GDPR spam plugins, lots of Gutenberg mega-blocky-thing spam with similar code-quality far from any wordpress code guidelines… only due to low installs nobody cares, yet.

      Another problem in repository, there is currently no way to also push/provide an update with a small fix within an older branch of a plugin, e.g. after an incident.

      Some already exploited plugin with 100k+ installs still has 30% users on an older major branch, still vulnerable to full RCE, because the newer branch release of the plugin broke compatibility too hard for existing sites, so users simply stopped updating.

      Fun times, if you are evil.


  6. Gryzli

    We are seeing another wave of attacks, where attackers try to guess the passwords of the malicious users being inserted in the previous exploitation phase.
    Requests are made upon the XMLRPC interface “/xmlrpc.php” and look like this :




Comments are closed.

%d bloggers like this: