CVE-2026-77152

Overview

Drupal is an open-source content management system known for its flexibility, robust features, and strong community support. Organizations of all sizes use it to build and manage dynamic websites and web applications.

Field Collection provides a field-collection field that can contain any number of attached fields. Each field collection is represented internally as an entity embedded in a host entity, so collection items can also be viewed and edited separately.

The Field Collection module for Drupal 7 fails to check access to the parent (host) entity when authorizing edits to field collection items, so any user with the "edit field collections" permission can edit or delete field collection items attached to entities they are not permitted to modify. This access bypass lets a low-privileged authenticated user alter content on nodes or other host entities that node/entity access controls should have protected.

Broken Access Control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do, enabling attackers to access unauthorized functionality, data, or resources. It often stems from inadequate validation of user permissions, allowing someone to bypass intended security boundaries and perform actions beyond their assigned role.

Details

Module Info

• Product: Drupal 7
• Affected packages: Field Collection
• Affected versions: 7.1.0
• Repository: https://git.drupalcode.org/project/field_collection
• Published packages: https://www.drupal.org/project/field_collection
• Package manager: composer
• Fixed in: Field Collection NES 7.1.3

Vulnerability Info

This medium-severity vulnerability is found in versions of the Drupal Field Collection module for Drupal 7 sites, version 7.1.0.

Prior to the fix, field_collection_item_access() in field_collection.module authorized edit and delete operations on a field collection item by checking only user_access('edit field collections'), never consulting the access controls of the host entity that owns the item. Because a field collection item is not an independently-permissioned entity but a child of a host entity (e.g., a node), this allowed any authenticated user holding that single permission to reach the item's /field-collection/{field}/{item_id}/edit and /delete menu callbacks and mutate content on host entities they had no update access to, bypassing node/entity access entirely. A secondary weakness meant that when the host entity could not be loaded, the check defaulted to granting access rather than denying it.

Steps To Reproduce

1. On the latest stable version of Drupal 7, install a susceptible version of the Field Collection module (such as 7.x-1.0).
2. Enable Field Collection; accept enabling Entity API when asked.
3. Go to Structure → Content types → Article → Manage fields.
4. Add a new field named "Test Collection" for the field type, select "Field collection", for the widget type select Embedded. Click Save twice.
5. Go to Structure → Field collections → click "Test Collection" → Manage fields.
6. Add a new text field named "Product" with a field type of Text. Click Save then Save field settings.
7. At Content → Add content → Article, create an Article with a title, no need for a body. Click Save.
8. Click the Edit tab of the article you just made. On the node edit form that appears, fill in the collection's text field with any value and Click Save.
9. On the Article page that appears, hover your mouse over the Edit link to the right of the Delete link (not the Edit tab) and note the field collection {item ID} from the inline "Edit" link. It will look something like /field-collection/field-test-collection/{item_id}/edit
10. At People → Permissions tab → Roles:
    • Add Role A with View Published Content + edit field collections permissions
    • Add Role B with View Published Content + Article: Edit any content + Edit field collections permissions
11. At People → +Add user, create User A with Role A and User B with Role B.
12. Clear the cache with drush cc all.
13. Test the fix (User A — parent view access, no parent edit/update access):
    • Log in as User A.
    • Go to /field-collection/field-test-collection/{item_id}/edit — expect 403.
    • Go to /field-collection/field-test-collection/{item_id}/delete — expect 403.
14. Test no regression (User B — has node access):
    • Log in as User B.
    • Go to /field-collection/field-test-collection/{item_id}/edit — expect 200.

Without the fix, instead of getting a 403 User A will be able to access the pages.

Addressing the Issue

Users of this module should apply one of the following mitigations:

• If the risk is unacceptable, disable the Field Collection module until the fix can be deployed.
• Restrict the "edit field collections" permission to highly trusted users only—ideally only roles that already have edit access to the host content.
• Audit field collection content on existing nodes and other host entities for unexpected edits or deletions, and restore any content altered by users who lack access to the parent entity.
• Sign up for post-EOL security support—HeroDevs customers get immediate access to a patched version of this module.

Credits

Ra Mänd (ram4nd)