Edit page Add new page

GovPress plugin advisories

Workflow #

We’ll normally create an advisory as a result of a plugin inspection where we were able to quickly prove that the plugin is vulnerable. We may also do so as a result of issues found in a pen test.

The steps for progressing an Advisory are:

  1. Check for existing advisories
  2. Write up an advisory
  3. Report the advisory to the plugin author
  4. Notify the WordPress plugin admins (only in special circumstances)
  5. (at a later date) Publish the advisory
  6. Request a CVE

The progress of advisories and inspections should be tracked on the Support and Maintenance Backlog

Check for existing advisories #

patchstack provides an annual report on WordPress security, generated from a database of existing vulnerabilities, which can be searched from their website or via their API.

It’s important that we avoid publishing advisories that have already been reported by someone else.

Writing up advisories #

Naming the advisory #

Titles should be in the following format:

[Vulnerability Type] in [Plugin Name] allows [User Type] to [Do Bad Things]

Here are some Harry-approved examples:



Reflected XSS in [plugin name] allows an unauthenticated attacker to do almost anything an admin can


An attacker able to convince an admin to visit a link of their choosing is able to execute arbitrary JavaScript

…the attacker can then use JavaScript to perform almost any action an admin can take (including creating new users, executing arbitrary PHP through the theme editor or exploiting vulnerabilities in WordPress or other plugins which normally require the user to be authenticated as an admin).”

or maybe:

If an attacker is able to convince a logged-in admin user to follow a link (phishing emails can be made to look very convincing), then …

Proof of concept:

If a logged-in administrator user clicks the submit button on this form, a JavaScript alert will display on [A SPECIFIC PAGE] (In a real attack the form can be made to auto-submit using JavaScript).”

Unserialize #


Unserialize vulnerability in [plugin name] allows an attacker to run code on the server


If there are classes with methods like __destruct() that have certain properties, the attacker can …

Mitigations #

CVSS Scores #

Reporting an advisory #

In order to publish advisories responsibly there are a number of steps which must be followed:


Notify the plugin Author #


In extreme cases where the advisory will have a significant impact we may need to request an encrypted email connection for these communications. In all other cases, normal email is fine.

As an example of a humanising intro:

Hello We’ve found a security vulnerability in Version 2.8.2 of the Advanced Access Manager plugin – please see the details below. After you’ve had a chance to investigate could you please let us know a timeline for a fix – our disclosure policy is linked at the bottom of the report. Best regards Duncan

Notify the WordPress plugin admins #

There are two scenarios in which the WordPress plugin admins (plugins@wordpress.org) should be contacted:

  1. If we really couldn’t get in touch with the plugin dev
  2. If the vulnerability is really serious and the plugin is popular (say over 100,000 downloads), so needs to be taken down ASAP

Their policy is this:

Every attempt to contact the developer directly should be made BEFORE you reported the plugin to us. Since our policy is to close the plugin (preventing new downloads) until it’s fixed, you may not be alerted until the plugin is updated.


If we couldn’t get in touch with the plugin author then WP Org may be able to contact them on our behalf, BUT we shouldn’t expect them to feed back any information to us, or even to confirm that they have successfully contacted the author (they are extremely busy).

Therefore we shouldn’t say things like “No response from WP Org” (because we shouldn’t expect one) or “No response from author to WP Org” (because we don’t know that’s the case).

Publishing an Advisory #

There are two reasons that we will publish an advisory:

If an author has at any point been in touch and shown willingness to cooperate then we should give them the benefit of the doubt and make several attempts to get in touch.

Preparing advisories for publication #

If the issue is fixed:

If the issue is NOT fixed:

If the plugin was removed from the directory:

Publishing the advisory and associated inspection #

Once the advisory has been published the associated inspection can also be published:

Once it’s published we can alert upstream:

Request a CVE #

Note that most CVEs cannot be requested before publication due to the rules of the Distributed Weakness Filing project. Vulnerabilities in plugins made by WordPress itself follow different rules as they’re covered by MITRE.

Last updated: 19 September 2023 (history)