WPML Website Hacked, Customer Emails Compromised

On Saturday, January 19, WPML customers started reporting having received an email from someone who seems to have hacked the plugin’s website and gained access to customer information.

https://twitter.com/gytisrepecka/status/1086753453429481473

The hacker claims to be a disgruntled customer who had two websites hacked due to vulnerabilities in the WPML plugin:

WPML came with a bunch of ridiculous security holes which, despite my efforts to keep everything up to date, allowed the most important two of my websites to be hacked.

WPML exposed sensitive information to someone with very little coding skills but merely with access to the WPML code and some interest in seeing how easy is to break it.

I’m able to write this here because of the very same WPML flaws as this plugin is used on wpml.org too.

The hacker also claims to have exploited the same vulnerabilities in order to send the email to WPML’s customers and has published the same message to the plugin’s website. The text is still live at this time and product pages have also been defaced.

The commercial multilingual plugin has been in business since 2009 and is active on more than 600,000 WordPress sites. It is a popular plugin for business sites in Europe, North America, Asia, and South America, especially those with a global audience. Customers are still waiting for an official explanation from WPML.

We contacted the company for comment but have not yet received a response. If you are using the plugin, you should deactivate it until the company pushes an update to patch the security vulnerabilities. This story is developing and we will publish new information as it becomes available.

Update from WPML founder Amir Helzer: “The customer is an ex-employee who left an exploit on the server (not WPML plugin) before leaving. Besides fixing the damage, we’ll also be taking legal actions.”

23

23 responses to “WPML Website Hacked, Customer Emails Compromised”

  1. The customer is an ex-employee who left an exploit on the server (not WPML plugin) before leaving. Besides fixing the damage, we’ll also be taking legal actions.

      • Jasper, if this vulnerability is really present in WPML itself don’t you think other WPML websites would get hacked?

        Don’t you think security researches would have already discovered it, or will soon?

        Don’t you think the actual vulnerability would be disclosed?

        Don’t you think the “hacker” would provide some actual proof of the vulnerability?

        This entire story smelled fishy from the start. This just isn’t how vulnerabilities are disclosed by security researches, or exploited by malicious hackers.

        A malicious hacker would hack sites.

        A real security researcher would responsibly disclose, so the vuln would get fixed before being made public.

        Stuff like this is unheard of unless the company ignores the vuln when it is responsibly disclosed to them.

    • I expect you reimburse your clients. Your clients that trusted you with your data. This is a big deal, you have to take action!

    • Amir,

      Let me just grace the elephant in the room:

      WPML support constantly gains access to both development and production sites belonging to e-commerce businesses. We trust you with this information, because we often have to. There’s simply too many flaws in WPML and it’s too complex to deal with for most, hence we often need to give your support personal access.

      We have given access to our production site a few times due to critical errors. What’s to stop an employee from stealing data and exploiting that data later on, e.g. payment provider API credentials, user data, et cetera?

      How can we be sure that our database was completely deleted after it was copied/cloned by your employees? That it won’t be abused?

      As I see it, the only responsible thing to do with WPML is to get completely rid of it. Such as headache.

      • Our support asks for login when clients want us to check their site from inside the WordPress admin. You surely understand that this is not our first priority.

        When clients need help checking things inside their site, we prefer that they create duplicates in our sandbox site. There, we can experiment as much as we want without the risk of breaking anything. When our debug completes, we delete these sites. We do that because we want to protect your privacy and because we have limited storage space on that sandbox site.

        If clients give us login to their sites, we recommend to create temporary accounts and delete them when we’re done.

        From this recent incident we also learned and we have already improved our workflow. We’re now auto-deleting private replies when tickets complete or get abandoned and we send reminder emails suggestion to clients to delete any private information that they shared with us. Yes, it would be nice if we had thought about it earlier, but we didn’t.

        Nothing is to stop an employee from stealing data. If you don’t trust us and our employees, don’t give this access. There are ways to debug problems without giving us that access. For example, we offer live chat support. You can show the supporter what you are seeing and the supporter will guide you in real time.

        How can you be sure of anything? We work remotely. Let’s say that we’re employing a crooked employee and he decides to damage both WPML and you. There’s nothing that will stop him. BTW, that’s the same about crooked policemen, crooked politicians (you do give them part of your income every month), etc. I hope you understand the stealing your data is not a company policy.

        Our team has helped several hundreds of clients find what private information they shared with us so they can remove it from their site.

        If we didn’t manage to help you better, I apologize. The recent hack to our server was our fault and not your and you have every right to be upset.

  2. To publish this story and a recommendation to “deactivate [WPML] until the company pushes an update to patch the security vulnerabilities. ” before finding out whether it was a vulnerability in WPML or not is extremely irresponsible.

    A perfectly legitimate company has been harmed by a malicious ex-employee, and the harm has now been exacerbated by terrible journalism.

    I hope a correction will be published that reaches at least as many people as the original story.

    #fakenews

    • Actually Mark, I’d say the journalism here is spot on.

      In the case of any security concern, until such time that another side is known, it’s quite right to warn people. Now that WPML’s side is known, they’ve updated the article.

      Poor journalism would have been to have waited for a full response before telling anyone, imo.

      • A security breach should always be discussed in private until confirmed.

        WPML is not a trivial plugin, deactivating it on a production site is not a good idea. Now that the breach has been has been confirmed as a internal security problem, you should delete this sentence:

        ” If you are using the plugin, you should deactivate it until the company pushes an update to patch the security vulnerabilities.”

      • Actually David, if I understood this correctly there was no issue with WPML plugin at all.

        Exploit was on the server and ex-employee used this exploit to change wpml.org site and access send those emails.

        This means that journalist have failed and mislead people that there is something wrong with the plugin.

        Poor journalism would have been to have waited for a full response before telling anyone

        No, poor journalism is when you assume something and warn people without actual proof. They could have check with someone if there is in fact any exploit in the plugin (not necessary wpml.org) and then warn people.

        This is like assuming there is a killer in someones neighborhood and they are warning people based on assumptions not actual proof just to find out that the person is not a killer at all.

        Journalism is about the proof, not assumptions, that’s tabloids 😉

      • Sorry, but don’t quite agree. Assuming a story is true without checking is not journalism, that is gossip.
        The story states “until the company pushes an update to patch the security vulnerabilities” and clearly states that they are believing a story without checking.
        For the moment there are still two stories out there, and neither of them are confirmed to be true and correct.

      • Assuming a story is true without checking is not journalism, that is gossip.

        The site had been hacked and that is what was reported. The idea that it’s gossip until all views have been sourced is ridiculous. In this case, Sarah has updated the article as WPML has given an official reply.

        A security breach should always be discussed in private until confirmed.

        But what about a security breach that has been made public already, as in this case?

  3. I have a short update.

    1. We’re still working on our website (wpml.org). The work will complete today. Much of the security update includes applying 2 factor authentication to critical points.

    2. The first thing that we checked was that the plugins (WPML and its components) are not affected. They are not. There is no malicious code in our plugins.

    3. No payment information was lost. We don’t store payment information on wpml.org (use PayPal and Stripe who are keeping the payment information secure on their systems).

    4. We wrote an email to our clients describing the incident. Mostly, we asked in this email to change their passwords on wpml.org.

    5. I’ll write a blog post on wpml.org with all the relevant information once we’re 100% done, but we shouldn’t do it before.

    Since the attacker had access to our site’s admin, he also had access to our mailer. We immediately disabled the mailing from our server. This would explain not getting a question from WPTavern or from other concerned clients. During this time, our site did not send out emails, so a number of clients are still waiting for their login details. We’re completing this now and will get back to everyone.

    We have to admit that our site was not secured well enough. If someone previously had admin access and stopped working for us, we should have been more careful and avoided this situation.

    BTW – This can be a wakeup call for others. We talk a lot about the benefits or remote work and most of the WordPress industry works remotely. This made us realize that we need to be a lot more pessimistic when we allow any access to our system.

    For example, the fact that we’re now coding for ourselves a requirement to login with 2fa, means that we’re not alone in this exposed situation.

    • And we, the people and businesses who give WPML full access to our WP installs and databases for support reasons, needs to seriously think twice about that too.

      You could argue that we, your customers (a little while longer), should always give access to a staging or development site instead of production. However, it’s not very likely that all sensitive data is removed from all test sites. Hence, your employees gain copies of or access to an insane amount of customer and order data, plus part of API credentials, etc. Every single day. Scary!

      How many copies of e-commerce sites does this disgruntled ex-employee have? And other employees? You have no way of knowing, do you? What kind of security measures do you have in place to prevent this?

    • In my career, which started a long time ago, before there was Internet to worry about, businesses had standard procedures in place so that, if we had to fire someone or lay off a bunch of people, we could protect the company, shareholder and employee livelihoods.

      The first thing the unfortunate individual knew about his or her impending departure was that their building entry pass no longer worked, or, the company car was no longer in the car park. This was shortly followed by the necessary discussion with their line manager, or company meeting where it was made official.

      I have had years of experience seeing what people do to retaliate against the company that decides they can do fine well without them, so cancelling logins 2FA etc., all seem like sensible “standard procedure” to me.

      But there again I am old school. Not all touchy-feely and frightened of hurting people’s feelings as seems to be prevalent these days.

      I guess this kind of incident is just a logical outcome of treating people more like people and not ticking time-bombs.

  4. I am a WPML customer, using the plugin on a new site, and did not get the email from the supposed hacker.

    When I learned about the hack I scanned my site with a couple of security tools and could not find any indications for security issues with the WPML plugin.

    Whatever the internal issue at WPML may be, I wish you good luck with the resolution.

  5. Starting in mid December, my WP site has been hacked. Every morning I find 4-5 new users with “email” address with “subscriber” status. I am not a program, just a business that uses WP because of its capabilities. But I can’t go on using WP if I have to fight hackers.

    I called “Sitelock” and they cost $30 per month. I felt like I was visited by the mafia…. “Pay me to protect you or suffer the consequences”. That next morning I got 20 new hackers. Imagine that.

    • @Dwight

      1. Go to Settings > General
      2. Uncheck “Anyone can register”

      I doubt your site is getting hacked, bud. Probably you just don’t know how to manage it. You probably should look into a monthly support option.

      Cheers.

    • Henry’s advice below is prudent. You could pay your hosting company to give you more protection that they should be giving you anyway, but in this case it sounds more like a configuration issue. If the means of registration is not inhibited in anyway, you can and will be visited by bots.

      Heck, the host I am on only has about four hundred customers total, and using a free plugin to monitor that kind of activity, I get twenty attempts a day to log in as me. Forget signups, that could really be bad. But that’s not hacking. That’s a jerk playing pretend in a very real way.

      There’s nothing you can use that’s free and self-hosted that will protect you from these things out of the box, but there’s also nothing you have to do that costs money that cannot at least help if not outright mostly fix the situation.

      I was on a site last year that was holding a design contest, but it was only for the United States. The people were upset because they had 8000 form submissions, but only 2000 contestants. Turned out a lot of automated submissions were going through their very short signup form that had no reCAPTCHA or even a hidden field to trick bots. Also, in their settings, there was no sending out of an activation link or anything. You just instantly were able to log in.

      So they asked their host to block traffic from the source (eastern Europe) and since nobody outside of the country cared about the contest either, nobody complained and they got maybe two dozen fake signups a day afterwards instead of several hundred. When they added reCAPTCHA it stopped.

      I can appreciate your concern, but all hope is not lost; just be mindful and put feelers out there for help. The worst anyone can say is no and the platform is one of the nicer ones out there for normal people to get stuff done on.

  6. What I am more curious about is their statement that the hacker may be able to log into wpml.org accounts because their database was compromised. Does this mean they are storing account passwords in plain text? No salt? No encryption?

    • The attacker probably had access to the salts. That makes it significantly easier to break the hashes. Also, if you have remote code access, it literally takes a couple lines of code to make WordPress accept any password for any user. See the `authenticate`hook. The same hook allows you to capture and record any passwords entered into login form.

Newsletter

Subscribe Via Email

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