Rabbit Hole
A visitor could view content a site had configured to hide or avoid a configured redirect. Anyone with no login could alter the settings that hide a piece of content. They could not read the hidden content itself.
- Who could do thisAnyone visiting the site. No login needed.
- Does it apply to youThe first vulnerability affects every site that relies on this module to deny access to or hide content, and the second affects sites where an attacker has a role with the access right to edit the affected content and the site exposes a write path that bypasses the content form such as a data feed with writes enabled.
- Has it been used in attacksNo sign of it.
- How urgentDrupal rates this moderately critical. Include it in your next routine update, within the month.
Tell your developerUpdate Rabbit Hole to 8.x-1.3 or 2.0.0-beta3, whichever branch you are on.
For developers: what the fix changed
The fix prevents query parameters from overriding internal request attributes by using `$request->attributes->get()` instead of `$request->get()` in `src/BehaviorInvoker.php`. It also implements `hook_entity_field_access()` in `rabbit_hole.module` to enforce the administer permission on Rabbit Hole fields, preventing unauthorised modification via APIs like JSON:API or REST.
Also in this release The release also adds cacheability metadata to redirect responses, removes settings from confirmation forms, encodes redirect paths exactly once, fixes a schema mismatch, and populates empty values with defaults.
config/install/rabbit_hole.behavior_settings.default.yml+2 −2config/install/rabbit_hole.behavior_settings.default_bundle.yml+2 −2config/schema/behavior_settings.schema.yml+3 −1modules/rh_node/rh-node.js+2 −1rabbit_hole.install+102 −0rabbit_hole.module+54 −2 fixrabbit_hole.permissions.yml+1 −1rabbit_hole.post_update.php+17 −1src/BehaviorInvoker.php+37 −5 fixsrc/BehaviorInvokerInterface.php+1 −1src/BehaviorSettingsManager.php+1 −1src/EntityExtender.php+1 −0