This issue was discussed by the Drupal Security Team, and their decision was that this can be solved in a public issue.
Problem/Motivation
The Drupal token system has an access permissions vulnerability. Currently, there is no way for it to reliably check entity view permissions when replacing tokens, which can lead to inadvertent information disclosure.
Steps to reproduce
When sending an email with token-embedded messages, such as notifying user B about content created by user A:
- Token::replace() is called to replace tokens in the email body.
- Tokens might embed sensitive information (e.g., the title of a restricted node or user details).
- While the calling code (e.g., email notification logic) may verify user B's access to objects in $data, token implementations can define new tokens that query data internally without knowing the recipient (user B).
- Hook implementations cannot check access for the recipient because they only know the current user (or none, in cases like cron runs).
Proposed resolution
Add an optional $account parameter to Token::replace() and hook_tokens() to specify the recipient for proper access checks. This should be added via the $options argument to maintain backward compatibility.
Remaining tasks
Determine if adding the $account parameter to $options in Token::replace() and hook_tokens() is the most robust and future-proof solution.