Vulnerability Directory | CVE-2026-1556 | Drupal 7

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.

When multiple users upload files with the same filename, the module incorrectly overwrites the file URI during processing. Modules using hook_node_insert() (e.g., commonly used when sending email attachments) then receive the wrong (previously uploaded) private file.

An authenticated attacker can exploit this by uploading a file with a colliding name, causing another user’s private file to be disclosed via the insert hook, bypassing normal access controls.

Information exposure, often referred to as information disclosure or sensitive data exposure, can often be a high-severity vulnerability where applications inadvertently reveal confidential or useful details to unauthorized parties due to inadequate protections, such as weak cryptography, misconfigurations, or flawed access controls.
According to OWASP, this can stem from transmitting data in clear text, using outdated cryptographic algorithms, improper key management, or failing to sanitize error messages and responses, allowing attackers to intercept, infer, or directly access information like configurations, server details, user credentials, or API keys. It aligns with OWASP Top 10 categories including A01:2021 – Broken Access Control (ranked first) and A05:2021 – Security Misconfiguration (ranked fifth), as well as evolving from the 2017 A3: Sensitive Data Exposure, now encompassed in A02:2021 – Cryptographic Failures (ranked second). Attackers exploit this through techniques like network sniffing, analyzing error outputs, or leveraging misconfigured endpoints, potentially leading to escalated attacks.

Ramifications include:

Data breaches
Identity theft
Financial losses
Further exploits
Legal penalties, and
Reputational damage.

This issue affects the File Field Paths module version 7.1.2 and lower.

‍

Details

Module Info

Product: Drupal
Affected code: File Field Paths module
Affected versions: >=7.1.0 <=7.1.2
Project page: https://www.drupal.org/project/filefield_paths
Fixed in: File Field Paths NES 7.1.3

‍

Vulnerability Info

This medium-severity vulnerability is found in all versions of the Drupal File Field Paths module for Drupal 7 sites.

‍

Steps To Reproduce

1. Create a Drupal 7 installation and install a File Field Path module version that is vulnerable to the exploit, such as 7.1.2.

2. Install token , which is a dependency, and nodeaccess, which is used to reproduce the exploit.

3. Enable file and image core modules; enable filefield_paths, token, and nodeaccess.

4. Set up private file folder and make it writable then set file_private_path to that directory:

mkdir -p sites/default/files/private
chmod 0777 sites/default/files/private
drush vset file_private_path sites/default/files/private

5. Set up fields:

In the Article content type: edit field_image → set Upload destination to Private files.
Add a new image field to the Basic Page content type and set the field_image upload destination to Private files and set its File (Field) Paths destination to the same path string as Article (e.g., field/image).
Save both.

6. Set up access (Nodeaccess):

At /admin/config/people/nodeaccess: remove “view” for anonymous and authenticated on Article and Basic page.
Grant “view” + “edit” on Article to role-foo; grant “view” + “edit” on Basic page to role-bar.
Rebuild node access with:

drush ev 'node_access_rebuild();'

7. Create a custom module that demonstrates the leak.
filefieldtest.module:

<?php
  function filefieldtest_node_insert($node) {
    if (!empty($node->field_image['und'][0])) {
      $img = $node->field_image['und'][0];
      $data = file_get_contents($img['uri']);
      file_put_contents('/tmp/' . $img['filename'], $data);
    }
  }

filefieldtest.info:

name = FileField Paths Leak Helper
description = Minimal helper to log the file URI handed to hook_node_insert().
core = 7.x
package = Testing
dependencies[] = file
dependencies[] = filefield_paths
files[] = filefieldtest.module

Enable the module.

8. Set up users:

Create user foo with role role-foo; user bar with role role-bar.

9. Trigger the leak:

As user foo: create an Article, upload foobar.jpg; ensure it has unique content. After saving it, check /tmp/foobar.jpg; it should contain foo’s file. Remove or rename it so the next write is obvious.
As user bar: create a Basic page, upload a different foobar.jpg with different content.

10. Observe:

Inspect /tmp/foobar.jpg.
You’ll find it contains foo’s file, not bar’s, showing that the FileField Paths module handed hook_node_insert() the previous user’s private upload.

‍

Mitigation

Users of the affected components should apply one of the following:

Use private files everywhere: set file_default_scheme to private and configure a writable private:// path; in each field_image (and any File Field Paths-configured field) choose “Private files” for Upload destination. Avoid public:// entirely.
Avoid predictable collisions: set File (Field) Paths patterns to include unique tokens (e.g., [uid]/[random:hash] or timestamps) instead of shared paths like field/image, so two users don’t land in the same target path.
Disable the module (note that you may lose significant functionality this way).
Review hook_node_insert() (and similar) code that reads $file['uri'] and send/forwards files; add sanity checks so you don’t act on a file owned by another user (e.g., confirm $file->uid === $node->uid or check scheme/path before copying).