CVE-2026-88974

WPGraphQL provides a GraphQL API for WordPress sites. Prior to 2.22.2, the updatePost mutation in src/Mutation/PostObjectUpdate.php checks only the collection-level edit_posts capability and the post author, but does not enforce the object-level edit_post capability or require publish_posts for public status transitions. An authenticated Contributor can therefore publish the Contributor's own draft without editorial approval or modify the Contributor's previously published post despite lacking edit_published_posts, while posts owned by other authors remain protected. This issue is fixed in version 2.22.2.

WPGraphQL provides a GraphQL API for WordPress sites. Prior to 2.22.2, the updatePost mutation in src/Mutation/PostObjectUpdate.php checks only the collection-level edit_posts capability and the post author, but does not enforce the object-level edit_post capability or require publish_posts for public status transitions. An authenticated Contributor can therefore publish the Contributor's own draft without editorial approval or modify the Contributor's previously published post despite lacking edit_published_posts, while posts owned by other authors remain protected. This issue is fixed in version 2.22.2.

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"}' \
 …

WPGraphQL provides a GraphQL API for WordPress sites. Prior to 2.22.2, the updatePost mutation in src/Mutation/PostObjectUpdate.php checks only the collection-level edit_posts capability and the post author, but does not enforce the object-level edit_post capability or require publish_posts for public status transitions. An authenticated Contributor can therefore publish the Contributor's own draft without editorial approval or modify the Contributor's previously published post despite lacking edit_published_posts, while posts owned by other authors remain protected. This issue is fixed in version 2.22.2.

WPGraphQL provides a GraphQL API for WordPress sites. Prior to 2.22.2, the updatePost mutation in src/Mutation/PostObjectUpdate.php checks only the collection-level edit_posts capability and the post author, but does not enforce the object-level edit_post capability or require publish_posts for public status transitions. An authenticated Contributor can therefore publish the Contributor's own draft without editorial approval or modify the Contributor's previously published post despite lacking edit_published_posts, while posts owned by other authors remain protected. This issue is fixed in version 2.22.2.

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"}' \
 …