Drupal is a little cagier than most CMSs. It'll happily tell you the major version - 7, 8, 9, 10, 11 - and then clam up about the exact point release, which is the bit you actually need. Here's how I get both.
Quickest way: run a full scan
Point ScanTower's full scan at the URL. The technology section reads what Drupal exposes:
| Signal | Source | Confidence | Value |
|---|---|---|---|
| Generator meta tag | HTML | 90 / 100 | Drupal 10 |
Note the value: Drupal 10, not 10.2.4. That's by design - the meta tag only carries the major version. The scan then tries to pin down the exact release from other signals and checks it against published CVEs, which is where it earns its keep.
Read it yourself
Drupal announces the major version in two places. The HTML head:
<meta name='Generator' content='Drupal 10 (https://www.drupal.org)' />...and an HTTP response header. Grab both in one line:
curl -sI https://example.com/ | grep -i x-generatorGetting the exact point release
For the full version number, the old reliable is the changelog: /CHANGELOG.txt on Drupal 7, or /core/CHANGELOG.txt on 8 and later - the top line lists the current release. Plenty of hardened sites block it, in which case you're back to fingerprinting core asset hashes. That's exactly the fallback the full scan automates.
Why confidence isn't 100
The generator tag and X-Generator header are both self-reported and easy to strip - Drupal even has a "Prevent Version Disclosure" module for it. Present, it's usually honest; absent, you lean on the changelog and asset fingerprints instead.
Why the version matters: CVEs
Drupal has a history of fast-weaponised core bugs, so the version is really one question: is this site patched? Some of the big ones:
| CVE | Type | Affected | Fixed in |
|---|---|---|---|
| CVE-2026-9082 | Highly critical SQL injection (in CISA KEV, actively exploited) | 10.5.x - 11.3.x | patched May 2026 |
| CVE-2018-7600 (Drupalgeddon2) | Unauthenticated remote code execution | <7.58 / <8.5.1 | 7.58 / 8.5.1 |
| CVE-2014-3704 (Drupalgeddon) | Pre-auth SQL injection | Drupal 7 <7.32 | 7.32 |
The Drupalgeddon bugs were exploited within hours of disclosure, and Drupal 7 reached end of life in January 2025 - if a site is still on 7, it gets no more security fixes at all. Confirm the exact affected range against the official advisory before acting on any of these.
If it's your site
- Update.
composer update 'drupal/core-*'then run database updates. On Drupal 7, plan a migration to 10 or 11 - it's past EOL. - Hide the version with the Prevent Version Disclosure module and block
/CHANGELOG.txt. - Re-scan to confirm the version moved and the CVE flags cleared.
While you're in there, the security headers checker and HTTP security checker catch the misconfigurations that tend to ride along with an out-of-date CMS. Running something else? We've got the same write-ups for Joomla, Ghost and WordPress.