Check for logged-in content leakage

Treat any suspicion that private or personalized content entered a shared cache as a security incident. Contain delivery first; preserve only sanitized evidence needed to understand the scope.

Immediate containment

1. Disable or remove optional Apache direct-cache rules for the affected HTML and JSON paths.
2. Disable the relevant POM Cache runtime switches.
3. Clear both current-site HTML and progressive JSON.
4. Invalidate affected CDN objects or the approved emergency path scope.
5. Disable any other reverse proxy or application cache that can retain the response.
6. Keep the affected personalized feature unavailable until anonymous and authenticated behavior is verified.

Changing only a WordPress switch may not stop a copied Apache rule, because that rule can serve a file before PHP reads the setting.

If cached output included active nonces, reset links, tokens, private file URLs, or session material, follow your incident procedure and rotate or revoke the affected credentials where applicable.

Preserve safe evidence

Before the evidence disappears, record:

• timestamp and exact sanitized public path;
• site and hostname;
• whether HTML or JSON contained the private value;
• response status and non-sensitive cache/CDN headers;
• anonymous versus authenticated reproduction;
• relevant POM Cache switch state;
• whether Apache and CDN delivery were active;
• a redacted description of the exposed field.

Do not paste the private body into a public ticket. Never share cookies, authorization headers, license keys, personal records, nonces, credentials, or absolute private server paths.

Test session separation

After containment:

1. create two separate private browser profiles with no shared cookies;
2. keep one anonymous and sign the other into a low-privilege test account;
3. request the same URL in both;
4. repeat with commerce/cart, password-protected, subscription, or membership sessions used by the site;
5. inspect both initial HTML and follow-up JSON/network requests;
6. confirm that a personalized response is never reused in the anonymous profile.

Use synthetic test data, not a real customer's information.

Find the cause

Check whether the private output varied by a property absent from the cache key:

• user identity or capability;
• authorization or subscription;
• cart or session;
• cookie not covered by a bypass;
• nonce or one-time URL;
• meaningful query parameter;
• geography, currency, language, or device;
• late client-side request that was independently cached.

Then review when the feature declares DONOTCACHEPAGE, whether a late read filter can miss the early phase, and whether the file existed before the feature became private.

Safe recovery

Before re-enabling:

• prevent future writes of the personalized representation;
• ensure bypass cookies cover all relevant sessions;
• clear old files again after deploying the fix;
• verify PHP origin behavior;
• verify Apache rules separately;
• verify the CDN with a fresh object;
• repeat the two-session matrix;
• test invalidation after account and content changes.

A normal plugin filter cannot be the only safeguard if an existing file can be served during advanced-cache.php or by Apache. The architecture and route design must make the shared representation public by construction.