Can you explain this vulnerability to me?

This vulnerability in the Discourse platform allows non-staff users to access read receipt metadata for staff-only posts that they are not authorized to see.

Specifically, while the actual content of the posts remains protected, unauthorized users could view information about who read the post and when, which is sensitive metadata.

The issue was caused by missing post-level authorization checks in the system, allowing this metadata disclosure.

It has been fixed by adding proper authorization checks to ensure only users with permission to view the post can access its read receipt information.

Useful 0 Not Useful 0

How can this vulnerability impact me? :

This vulnerability can impact you by exposing sensitive metadata about user interactions with staff-only posts.

Even though the post content is not exposed, the read receipt information reveals who has read certain private or staff-only posts and when they did so.

Such information leakage could lead to privacy concerns, unauthorized insight into staff activities, or potential social engineering risks.

To mitigate this impact, it is recommended to upgrade Discourse to the patched versions where this issue is resolved.

Useful 0 Not Useful 0

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves unauthorized access to read receipt metadata of staff-only posts in Discourse. Detection would involve checking if non-staff users can access reader metadata for whisper posts or staff-only posts they should not see.

Specifically, you can test the behavior of the `PostReadersController#index` endpoint by attempting to retrieve reader data for whisper posts as a non-staff user. If the system returns reader metadata instead of a forbidden response, the vulnerability may be present.

There are no explicit commands provided in the resources, but a practical approach would be to use API calls or HTTP requests to the Discourse instance as a non-staff user to access the reader data endpoint for posts that should be restricted.

• Use an HTTP client (e.g., curl or Postman) to send a GET request to the `PostReadersController#index` endpoint for a whisper post.
• Check if the response includes reader metadata (who read the post and when) without proper authorization.
• If the response is HTTP 403 Forbidden, the vulnerability is likely mitigated.

Useful 0 Not Useful 0

What immediate steps should I take to mitigate this vulnerability?

The primary and recommended mitigation for this vulnerability is to upgrade your Discourse installation to a patched version.

• Upgrade to Discourse version 2026.1.3, 2026.2.2, or 2026.3.0 or later, where the vulnerability has been fixed.

The fix includes adding an authorization check (`guardian.ensure_can_see!(post)`) in the `PostReadersController#index` method to ensure only authorized users can access reader metadata.

Until you can upgrade, restrict access to the reader metadata endpoints or limit non-staff user permissions to reduce exposure.

Useful 0 Not Useful 0

How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability allows unauthorized non-staff users to access metadata about who read staff-only posts and when, without exposing the post content itself.

This unauthorized disclosure of user interaction metadata could potentially impact compliance with privacy regulations such as GDPR or HIPAA, which require protection of personal data and user privacy.

Since the exposed data includes read receipt information, it may be considered sensitive metadata that organizations need to protect to maintain compliance with these standards.

The issue has been patched in later versions, and upgrading to these versions is recommended to mitigate the risk and help maintain compliance.

Useful 0 Not Useful 0