Incident with ClassicPress documentation site

As some of you may have noticed, our documentation site was down for a little less than 48 hours over the weekend.

This is currently a ClassicPress site, and @1stepforward recently reported seeing some defaced pages there (spam content and links).

Because of existing security measures, the impact was limited to the creation/addition of spam content on a few pages on the docs site. Our main website, updates API, code hosting including ClassicPress core, etc were not affected and are not vulnerable to the same issue. Read on for more details.

Upon receiving this report we took the docs site down immediately and began investigating. The cause: a previously active user account with access to edit pages on the docs site was using a weak password, which was guessed by bots after a couple thousand attempts.

Thanks to John we know this particular password was of the form myusername46 - the username on the site plus two digits appended to the end. Passwords should never be a variation of the username, first/last/full name, email address, etc. However this is a common password scheme and it’s one of the first patterns checked by automated attacks.

What we did well

  • We accepted the report of this issue privately and took appropriate action quickly.
  • We required 2-factor authentication (2FA) for most privileged accounts. Extending this requirement to more users would have prevented this issue.
  • We isolated our various sites and user-level permissions from each other. We keep different applications on different servers, and only grant users the permissions they need. This ensures that the impact of any single incident is limited.
  • We reviewed almost all plugin code in use on this site, or otherwise verified that the plugins in use have a good security record. This helps avoid other vulnerabilities, for example privilege escalation from a limited account to an administrator account.
  • We used an activity log plugin that allowed us to accurately investigate and diagnose the issue.
  • We required password resets to be done manually by an administrator.

As a result of these existing security measures, the intrusion was limited to these unwanted edits on a few pages on the documentation site only, and we were able to see the full history of the changes made to the site as well as which user account made them. The user account in question did not have permission to upload plugins or modify site files, so no lasting damage was done.

Further steps

  • We’ve extended our 2FA requirements for privileged users.
  • We’ll be revisiting our password policies and making improvements where needed. We’ll contact users individually if any changes are needed, most likely via a private message here on the forums.
  • We’ll be revisiting and improving our monitoring system for logins and other account activity.
  • We’ll be contacting users who have permissions on our systems but haven’t used them in a while, to see if those permissions are still needed. (If you think you might be in this situation, feel free to send us a private message).
  • We’ve brought the docs site back up with even more security measures aimed at preventing a similar incident in the future.

Summary and recommendations

Weak passwords are still one of the most common attack vectors for online applications (the other one is known vulnerabilities, so keep your plugins and core up to date!)

If you’re running an online service then it is a good idea to set and enforce a password policy. Some starting points for ClassicPress sites:

Two-factor authentication is also an excellent way to prevent almost any kind of attack related to passwords. This is often done by sending a one-time code via email or SMS (text message), which is better than nothing but still not very secure. Time-based codes (TOTP) generated by an app are a better option.

Two-Factor is a free plugin that enables this kind of extra authentication security for ClassicPress sites. You can find more general information about 2FA including app recommendations in this article from Kaspersky.

An activity log or audit log plugin is a good idea for monitoring and if you need to diagnose an issue. WP Security Audit Log is a good plugin for this, though not all options are available for free. There are lots of other choices out there, you’ll want to make sure your choice will report on failed login attempts (not all of them do).

ClassicPress is committed to security. It may seem counter-intuitive but this is the reason we’re making this post. We believe it’s important to handle and disclose security issues responsibly, and we’re also using this as a learning experience and a way to open a discussion about best practices.


Just a quick observation. When I click on the “John” link above, Malwarebytes blocks the site “due to Trojan”. Might be best to remove the link for now.


Removed, though my Malwarebytes didn’t seem to care about the site :man_shrugging:

People reading this will think: “Who is John”? Removing the link removes their way of answering that question.

I’ve updated the link to point to a Wikipedia page instead. This is a pretty silly thing to block anyway though, I expected better from Malwarebytes.


Makes sense, sorry I was on mobile :slight_smile:

1 Like

I’ve raised a “false positive” ticket with Malwarebytes.


A post was split to a new topic: Policy for non-GPL plugins