Field value tokens chained through entity reference fields do not check access to the referenced entity

This issue has been tagged for public follow-up by the Drupal security team.

This module has an Information Disclosure vulnerability.

Token module extends Drupal's token system to allow for chained tokens through entity reference fields. When a token such as [node:field_profile:entity:field_first_name:value] is in use, the field value will be shown even if the entity referenced via field_profile is unpublished.

Steps to reproduce:

1. Install Token
2. Create a Profile content type, with a field_first_name plain text field
3. Add a Profile entity, fill in First Name field; save it unpublished
4. Create an Article content type, with a field_profile reference field
5. Add an Article entity, reference the Profile added in #3
6. Call `Drupal::token()->replace('[node:field_profile:entity:field_first_name:value]', ['node' => $node])` somewhere like a page controller or hook_preprocess_node() to print the output (or use Metatag module)
7. View Article page from #5 as an anonymous user

Expected outcome: the First Name value from the unpublished Profile node should not be displayed

Actual outcome: the First Name value is shown.

• Version: 8.x
• Original reporter: les lim
• Initially created: Tue, 2023-01-10 14:33

Discussion in the private issue was centered around whether and how token access checking should work. Key points raised:

• The token API was designed without access control by default, so tokens have historically been treated as safe only for admin-like users who can view all content.
• Metatag doesn't interact with token access and may not be able to.
• A proposal to add an optional check_access option to Token::replace() ran into the problem of when and as whom to check. Access may need checking at configuration time (where no concrete entity or user exists) as well as replacement time, and using the current/global user at runtime is problematic.
• Some entities (e.g. taxonomy terms used as keywords) might legitimately surface even when the viewing user lacks access to the entity's canonical page, especially where modules like RabbitHole only override the page controller without touching access control. This was partially accepted, with the caveat that genuine $entity->access() failures should still suppress output.