Drupal is a powerful and popular content management system (CMS) used by millions of sites worldwide. But like all complex software, Drupal sometimes deals with security vulnerabilities. In early 2022, Drupal uncovered a serious issue related to its image handling: CVE-2022-25275. If you’re building or running a Drupal site—especially one that stores sensitive images—this long read will explain what happened, how to check if you’re at risk, and what you need to do to stay safe.

The Problem: How CVE-2022-25275 Works

Drupal’s Image module lets you create "derivatives" (such as thumbnails or resized versions) of images uploaded to your site. Normally, if an image is stored outside of your site's normal "public" folder (say, in a private directory), Drupal should check if the visitor has permission to see that image before showing it—even as a derivative.

But what CVE-2022-25275 revealed is this: Drupal core doesn’t always double-check access if your files use a custom file system (created by contributed modules), instead of the built-in "public" or "private" ones. This creates a loophole: people might get access to images that should stay private if the conditions are right.

The Conditions

- Your Drupal site has a custom file system (like a cloud-based storage or another non-standard way of handling files) provided by a module.
- You have either Drupal 9’s $config['image.settings']['allow_insecure_derivatives'] or Drupal 7’s $conf['image_allow_insecure_derivatives'] set to TRUE.

The default is FALSE, but some sites flip this setting for performance or legacy reasons.

If both apply, image derivatives from outside the public folder may be generated and exposed without access checks.

Someone discovers the URL to the derivative image (like a thumbnail or resized version).

- Drupal should check, "Is this user allowed to see this image?" before creating or serving the thumbnail.

Here’s the risky code path, summarized

// Simplified access check before the fix (Drupal core)
if ($scheme == 'private') {
  // Only check access for private files
  // But not for 's3', 'gcs', or custom schemes
  check_access($filepath);
}

After the fix, Drupal would always check access for any non-public file, regardless of the scheme.

Drupal 9+ uses the settings in settings.php

// settings.php
$config['image.settings']['allow_insecure_derivatives'] = TRUE; // Insecure! Change to FALSE

Drupal 7 uses

// settings.php
$conf['image_allow_insecure_derivatives'] = TRUE; // Insecure! Change to FALSE

If you see either line set to TRUE, your site could be vulnerable.

Attackers can

- Try to guess or brute-force the URLs for image derivatives (Drupal's predictable naming sometimes helps)

A simple proof-of-concept exploit (Python) to test for accessible derivatives

import requests

# URL to a derivative image you know exists but should be private
url = 'https://example.com/sites/default/files/styles/thumbnail/private/secret-images/top-secret.jpg';

r = requests.get(url)
if r.status_code == 200:
    print("Derivative accessible! Vulnerable to CVE-2022-25275")
else:
    print("No access - probably secure")

Official References

- Drupal Security Advisory SA-CORE-2022-003
- CVE-2022-25275 in NVD
- Drupal.org Issue #3247774

Update Drupal core: Always upgrade to the latest stable version.

3. Audit custom file systems: If you use modules that create new file schemes (like , s3fs, gcs, etc.), confirm they are patched and compliant.
4. Check access after updates: Review the release notes for your version. Some sites may need to manually clear caches or update old settings.
5. Test derivative image URLs: Try to access image derivatives you know should be private. If you get a 404 or access denied, you’re probably safe.

Sample: Ensuring Secure Setting in Drupal 9’s settings.php

// Make sure this is either absent or FALSE
$config['image.settings']['allow_insecure_derivatives'] = FALSE;

Final Notes

CVE-2022-25275 teaches us a lot about the importance of secure defaults and careful configuration. The good news? If you left your settings alone, you were always safe. The bad news? If you or a contributed module enabled the risky setting, private images might have leaked.

Remember:

Check your configuration after security releases

- Never use allow_insecure_derivatives = TRUE unless you’re absolutely sure you need it (and even then, double-check access)

For more details or help, start at these official pages:  
- Drupal Core security-advisory release notes
- Drupal Documentation: Securing image derivatives
- Original Patch Discussion

Timeline

Published on: 04/26/2023 14:15:00 UTC
Last modified on: 05/09/2023 14:36:00 UTC