- Package
- drupal/oauth2_token_manager
- Fixed in
- 1.2.0
- Published
- Wed 28 Oct 2026, 17:42 Lisbon
In plain words
The module does not restrict access to its OAuth2 routes, so an anonymous visitor could connect the site's Box, Quip or Slack integration to an account they control. The attacker must first obtain the OAuth2 state value from a previous system token initialisation.
Am I affected?
Look for drupal/oauth2_token_manager and its installed version in composer.lock. The advisory lists 1.2.0 as fixed but gives no affected version range. Check whether an OAuth2 state value from a previous system token initialisation could be obtained, for example from server access logs.
What to do
Check which version you have, then update to a fixed release for your branch (1.2.0):
composer show drupal/oauth2_token_manager | grep versions
composer update drupal/oauth2_token_managerIf your version constraint in composer.json keeps you below a fixed release, raise it first. Whether your configuration is affected, and the exact version ranges, are in the advisory itself.
If you cannot update yet
The advisory says the vulnerability is mitigated by the attacker needing to obtain the OAuth2 state value from a previous system token initialisation, for example from server access logs.
The advisory's description
This module lets you manage system-wide OAuth2 access and refresh tokens for Box, Quip, and Slack integrations through Drush and an OAuth2 validation callback.
The module doesn't restrict access to its OAuth2 routes, allowing an an anonymous visitor to potentially connect the site's integration to an account they control.
This vulnerability is mitigated by the fact that an attacker must obtain the OAuth2 state value from a previous system token initialization (for example, from the server access logs).