Security Fix
This release addresses an issue where authenticated user data (such as draft posts, private content, or other permission-restricted data) could be incorrectly cached and served to public users when using the Object Cache feature.
Users with Object Cache enabled should update immediately.
What was happening?
When an authenticated user (e.g., an admin logged into WordPress) made a GraphQL request, WPGraphQL core calls wp_set_current_user(0) during authentication validation after the query has already executed. This caused WPGraphQL Smart Cache to incorrectly identify the request as unauthenticated and cache the response—including any permission-restricted content the authenticated user could see.
Subsequent unauthenticated requests could then be served this cached response containing data they shouldn't have access to.
The Fix
- #306: fix: prevent authenticated request data from being cached and served to public users
- Uses
AppContext->viewer(which is set at request initialization and remains stable) instead ofis_user_logged_in()for authentication state detection - Adds Cache-Control: no-store header for authenticated requests to prevent network/CDN caching
- Ensures cache key generation uses the stable viewer context
- Uses
Chores
- ci: update deprecated GitHub Actions (actions/checkout, actions/cache) to v4
- ci: fix Gherkin test compatibility by pinning behat/gherkin < 4.9
- chore: update "Tested up to" WordPress 6.9
Full Changelog: v2.0.0...v2.0.1