ScanTitan detects identifiable Drupal core, contributed modules and themes using multiple external signals, then matches the detected versions against the Drupal Security Team’s advisories, CVE records and the CISA Known Exploited Vulnerabilities catalog, with HTTP evidence attached to findings it can verify externally.
Imperva saw 15,000+ exploit attempts across ~6,000 Drupal sites
Drupal 10 reaches end of life on 9 December 2026
CVE-2026-9082 entered the CISA KEV catalog with a 27 May 2026 federal deadline
Drupal runs over a million sites, concentrated in government, education and enterprise
Imperva saw 15,000+ exploit attempts across ~6,000 Drupal sites
Drupal 10 reaches end of life on 9 December 2026
CVE-2026-9082 entered the CISA KEV catalog with a 27 May 2026 federal deadline
Drupal runs over a million sites, concentrated in government, education and enterprise
A Drupal vulnerability scanner is an automated tool that inspects a Drupal site for known weaknesses in its core, contributed modules and themes. It identifies the version of each component it can detect, then matches those versions against the advisories published by the Drupal Security Team, SA-CORE for core and SA-CONTRIB for contributed projects, plus the CVE feeds.
Drupal makes detection harder than most platforms: core no longer prints a generator tag by default, module versions live in .info.yml metadata rather than a public manifest, and a tidy site blocks the obvious paths. A website vulnerability scanner that relies on a single signal may produce uncertain results, so ScanTitan cross-checks multiple signals and shows the evidence behind what it reports.
You can scan a Drupal site for vulnerabilities online in minutes, then add authenticated access for the components an external scan cannot reach. Findings are ranked by whether they are actually being exploited, not by severity language alone.
Six stages, from identifying the core branch to a verified fix.
Narrows the core release from the X-Generator header, any exposed CHANGELOG.txt, drupalSettings, asset paths, install and update endpoints, and file signatures that differ between releases.
Contributed projects are detected from info.yml metadata, /modules/contrib and legacy paths, library aggregation and known signatures, wherever those signals are externally visible.
"Core 10.6.9" becomes SA-CORE-2026-004, CVE-2026-9082, a Drupal risk score of 20 out of 25, and the release that closes it.
Readable CHANGELOG.txt, settings.php copies, database dumps and backup archives in the public files directory, reachable update.php, open registration and enumerable accounts.
Verifiable findings ship with the request and response behind them, using non-destructive checks. Version-inference findings are labelled as such, so you know which is which.
Ranked by Drupal's risk score, CVSS, EPSS probability and KEV membership, each with a fix and a re-scan that checks whether it is closed.
A fintech shipping a REST API imported its OpenAPI spec and, on the first authenticated scan, found a BOLA flaw on the /accounts/{id} endpoint that returned any user’s balance by changing the ID. Fixed and re-verified in a day, before any bug bounty report.
An unauthenticated scan sees what an anonymous visitor sees. On most Drupal sites that identifies the core branch and a substantial list of modules. It is not a complete inventory, and no external scanner can honestly claim otherwise.
Components that expose no public assets, sit behind authentication, publish no version metadata, are renamed or custom, are not used on the pages crawled, or are shielded by a WAF or CDN may not be detected externally. An authenticated scan closes most of that gap by reading the update status report and the extend page directly.
Request volume, deep enumeration sends a large number of requests, so ScanTitan rate-limits it and lets you schedule it off-peak. You can allowlist our scan sources and lower the rate if your host is strict.
Findings ship with a fix tailored to the component: the release to move to, the Composer command, the permission to revoke, or the file to remove from the web root.
A one-click re-scan then checks whether the vulnerable release is still detectable and attaches a clean-scan record to the issue, useful as evidence in a compliance review or client report.
Clean stays clean, advisories are published in a Wednesday release window. Scheduled scanning, as often as daily, flags the day a new SA-CONTRIB lands for a module you run.
Drupal holds around one percent of all websites by W3Techs’ measure, and that number hides the risk profile. It is concentrated in government portals, universities, healthcare and large enterprises, so one compromised site is worth far more than a small business blog, and mass scanning starts within hours of a highly critical advisory.
| How Drupal sites get compromised | Documented example | What ScanTitan looks for |
|---|---|---|
| Unpatched core advisory | Highly critical SA-CORE-2026-004 / CVE-2026-9082, anonymous SQL injection on PostgreSQL sites, CVSS 9.8, in CISA KEV | The detected core release, matched to SA-CORE advisories that apply to it |
| Contributed module flaws | Critical June 2026 PHP object injection advisories: Formatter Field before 2.0.0, Flag attendance field before 8.x-1.2, Plotly.js Graphing before 3.0.2 | Detected module and theme versions, matched to SA-CONTRIB advisories and CVE records |
| End-of-life core branches | No fixes ever Drupal 7 ended support on 5 January 2025; Drupal 9, 10.5 and earlier, and 11.0 to 11.2 get nothing further | EOL detection, remaining coverage window, and findings that will never be patched upstream |
| API and file surface | Moderate to critical June 2026 advisories tied to JSON:API write access and image-upload MIME validation | Exposed /jsonapi and /rest endpoints, anonymous write permissions, and upload validation |
On an unsupported branch, a scan result is not a to-do list, it is a migration business case. Status below reflects the Drupal core release schedule as of 5 August 2026.
| Branch | Status | Security coverage | What it means |
|---|---|---|---|
| Drupal 11.4.x | Current | Until June 2027 | The target for new builds and the longest runway available |
| Drupal 11.3.x | Supported | Until December 2026 | Patched normally, but plan the move before the December window |
| Drupal 10.6.x | Final 10 minor | Until 9 December 2026 | A hard deadline, not a soft recommendation |
| 11.0–11.2, 10.5 and earlier | End of life | None | Every new advisory stays permanently open |
| Drupal 9 | End of life | Ended November 2023 | Unsupported, and hard to keep on current PHP |
| Drupal 7 | End of life | Ended 5 January 2025 | Commercial extended support, or migrate |
| Drupal 12.0.0 | Scheduled | Week of 7 December 2026 | Ships with 11.5, which is why Drupal 10 coverage stops that week |
A few Drupal CVEs earned names because they changed how the community thinks about patch windows: Drupalgeddon (CVE-2014-3704, SQL injection, fixed in 7.32), Drupalgeddon2 (CVE-2018-7600, unauthenticated remote code execution, CVSS 9.8, in CISA KEV), Drupalgeddon3 (CVE-2018-7602) and the REST unserialize chain (CVE-2019-6340). Automated tooling never stopped scanning for them, and every abandoned Drupal 7 install is still a match.
Twelve years apart, Drupalgeddon and CVE-2026-9082 are the same story: a flaw in the database abstraction layer, anonymous exploitation, and a patch window measured in hours. ScanTitan checks the historic chains and current advisories in the same pass.
The Drupal attack surface, not just a core version number.
Narrows the core release from the X-Generator header, exposed CHANGELOG.txt, drupalSettings, asset paths, install and update endpoints, and file-level signatures.
Identifies contributed projects, themes and sub-themes from info.yml metadata, /modules/contrib and legacy paths, and library aggregation, with authenticated access filling what external signals miss.
Flags end-of-life core branches and scores projects with no advisory but real risk: no release in years, no maintainer, marked unsupported, or no release compatible with your next core version.
Findings carry the SA-CORE or SA-CONTRIB ID, the Drupal risk score out of 25, the CVE record and CVSS 3.1 score, plus EPSS probability and CISA KEV status where available.
Readable CHANGELOG.txt, settings.php copies and swap files, .env and composer.lock, exposed version control directories, reachable install.php or update.php, and database dumps or Backup and Migrate archives in the public files directory.
Exposed /jsonapi and /rest endpoints, write access granted to anonymous roles, Views pages publishing more than intended, enumerable usernames, open registration and weak flood control.
People searching for a Drupal exploit scanner want one of two things: a tool that fires exploit code at a site, which is a penetration testing decision, or a scanner that knows which findings attackers are using now. ScanTitan does the second, deliberately not the first, using public sources you can verify.
In May 2026 a core advisory went from disclosure to a CISA-mandated federal patch deadline in seven days. The July 2026 core advisories were all rated theoretical. Severity language alone will not tell you which is which.
Exploitation confirmed, with a binding federal deadline under BOD 22-01. Surfaced on the finding itself. KEV catalog
FIRST's estimate of exploitation likelihood in the next 30 days, often a better patch-order signal than CVSS alone. FIRST EPSS
The Security Team's own rating per advisory, preserved rather than flattened into a generic label. Drupal advisories
Built for two readers: the developer who runs the Composer command and the director who explains the risk. Exportable as PDF, JSON and HTML.
Detected core, modules and themes with versions and supported status, plus what could not be identified externally.
Findings tied to their SA-CORE or SA-CONTRIB ID, CVE record, Drupal risk score and CVSS score.
The request and response behind verifiable findings, plus the change that closes each one.
How long your branch still receives fixes, and which findings will never be patched upstream.
Authenticated scanning means handing a third party access to a production site. Agencies, government and higher-education teams should ask exactly how that is handled before connecting anything, so here are the answers up front.
Authenticated access uses a dedicated, least-privilege account or connector token that you create and can revoke at any time. Credentials are encrypted in transit and at rest in a managed secrets store, used only for your scans, and deleted when the connection is removed.
Access is role-based within your organisation. Support staff cannot read stored secrets, and any access to your data for troubleshooting requires your request and is logged in an audit trail.
Results are retained for the period set in your workspace settings. You can delete a scan, a site or your whole history at any time, and deletion removes the associated evidence and exports.
Scans originate from a published list of static IP ranges so you can allowlist them at your WAF, CDN or firewall and distinguish our traffic from an attacker's in your logs.
Checks are non-destructive: no exploit payloads, nothing written to your site. Request rates are limited by default, configurable per site, and deep scans can be scheduled off-peak.
Scan data can be processed and stored in the region you select, which matters for public sector and European teams with residency obligations. Contact us for the current region list and subprocessor details.
Updating removes known vulnerabilities. Hardening removes the conditions that make the next one cheap to exploit: trusted host patterns, a non-writable settings.php, private files and backups outside the web root, no PHP execution or directory listing in public files, restricted update.php, errors logged rather than displayed, two-factor authentication on privileged roles, tight flood control and security response headers. ScanTitan reports these as configuration findings with the setting to change.
Update Status, drush pm:security, the Composer advisories package and Security Review answer "are my versions current" from the inside. Free, precise, and blind to external exposure.
External, continuous, covers configuration and exposure as well as versions. Finds known and detectable issues, not logic flaws unique to your build.
A human engagement reviewing custom code, access control logic and integrations, usually with a scoped penetration test. Audit vs scanner, compared.
A university runs forty department sites on one codebase; an agency maintains thirty client builds on different branches. ScanTitan watches every property from one dashboard, triggers scans from the API, and alerts the right person when a site turns vulnerable.
curl -X POST https://api.scantitan.com/v1/drupal-scans \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"target": "https://portal.example.org",
"scan_type": "authenticated",
"notify": ["slack","email"]
}'
# Response
{
"scan_id": "dr_7c1e93",
"core_branch": "10.6.x",
"modules_detected": 38
}
One dashboard for every site and branch. Findings flow into the tools your team already uses, and white-label reports make quiet security work visible.
All sites, one screen
Daily / weekly / monthly
Auto-create tickets
Shared codebase, many hosts
Client-ready reports
Advisory alerts
Last reviewed 5 August 2026. Reviewed every 90 days.
July 2026
Coverage for SA-CORE-2026-010, -011 and -012, with fixed releases 11.4.4, 11.3.14 and 10.6.13 mapped to each finding.
June 2026
Added the 11.4 branch with its June 2027 coverage window, plus detection for the contributed projects carrying PHP object injection advisories.
May 2026
Detection for SA-CORE-2026-004 and CVE-2026-9082 shipped on the day of disclosure, with escalation once the CVE entered CISA KEV.
March 2026
Portfolio scanning now recognises multisite deployments sharing one codebase and reports per-site configuration differences separately.
All are legitimate tools, and the open-source ones are excellent at enumeration. The table below records what each vendor’s own documentation describes, not our opinion of the tools.
| Feature | ScanTitan | Droopescan | Drupwn | Pentest-Tools | HackerTarget |
|---|---|---|---|---|---|
| Core, module and theme enumeration | ✓ | ✓ | ✓ | ✓ | ✓ |
| Advisory and CVE matching | ✓ | Not documented | CLI | ✓ | Partial |
| Drupal risk-score mapping | ✓ | Not documented | Not documented | Partial | Not documented |
| KEV and EPSS exploitation context | ✓ | Not documented | Not documented | Partial | Not documented |
| Authenticated scanning | ✓ | Not documented | Basic auth | ✓ | Partial |
| HTTP evidence attached to findings | ✓ | Not documented | Not documented | ✓ | Not documented |
| End-of-life branch intelligence | ✓ | Not documented | Not documented | Not documented | Not documented |
| Scheduled multisite portfolio scanning | ✓ | Not documented | Not documented | Partial | Membership |
| Entry point | Free scan | Open-source CLI | Open-source CLI | Free light scan | Free basic |
How to read this table: ✓ the capability is described in the tool’s official documentation. Partial available with documented limits, or only in a paid tier. CLI available from the command line only, with no managed or scheduled equivalent. Basic auth supports HTTP basic authentication but not a full authenticated session. Membership requires a paid membership tier on that platform. Not documented means we found no description of the capability in the sources below at the time of review; it is not a claim that the tool cannot do it.
Sources reviewed 5 August 2026: Droopescan repository · Pentest-Tools Drupal Scanner · HackerTarget Drupal Security Scan · Drupwn project documentation.
Next scheduled review: November 2026. Spotted something out of date? Tell us and we will correct it.
An automated tool that inspects a Drupal site for known weaknesses in its core, contributed modules and themes. It identifies the version of each component it can detect, then matches those versions against the Drupal Security Team's SA-CORE and SA-CONTRIB advisories and the CVE feeds. A malware scanner detects code that is already malicious; a vulnerability scanner finds what an attacker could exploit first.
Enter your URL and run an unauthenticated scan, which identifies core, modules and themes from external signals in a few minutes with no installation. Add authenticated access for admin-side depth. Detected versions are matched against Drupal.org advisories and CVE records, and each finding arrives with its risk score, exploit status and the release that fixes it.
An unauthenticated scan sees what an anonymous visitor sees, which is not a complete inventory. Components with no public assets, behind authentication, without version metadata, custom or renamed, unused on the pages crawled, or shielded by a WAF or CDN may not be identified externally. Authenticated access closes most of that gap.
No. ScanTitan uses non-destructive checks: it looks for evidence that a vulnerable version or exposed path exists without running exploit code, and does not write to your site. Firing live payloads at production is a scoped penetration test. What it adds instead is exploit context: CISA KEV listing, EPSS probability and public exploit availability.
Yes, for the projects it can identify, and that is where most real exposure lives. Contributed projects are detected from info.yml metadata, asset paths and known signatures, then matched against SA-CONTRIB advisories, including the June 2026 PHP object injection issues in Formatter Field, Flag attendance field and Plotly.js Graphing. Unmaintained projects are scored as elevated risk even without an advisory.
Nothing breaks on the day; the site keeps serving traffic. What stops is the flow of security fixes. Drupal 7 ended on 5 January 2025 and Drupal 10 ends on 9 December 2026, with 10.6 as its final minor. After that, new core issues stay permanently open unless you buy commercial extended support.
Authenticated access uses a dedicated, least-privilege account or connector token that you create and can revoke at any time. Credentials are encrypted in transit and at rest in a managed secrets store, used only for your scans, and removed when the connection is deleted. Access is role-based, support staff cannot read stored secrets, and you can delete scan results at any point.
Checks are non-destructive: no exploit payloads are sent and nothing is written to your site. An unauthenticated scan is low-impact. A deep authenticated scan generates considerably more traffic, so request rates are limited by default, configurable per site, and schedulable off-peak. Scans come from published static IP ranges you can allowlist.
ScanTitan scans detectable Drupal core, modules and themes against published SA-CORE and SA-CONTRIB advisories, CVE records and the CISA KEV catalog, and tells you what to patch first.
OSCP · CISSP · 12 years in web application security · Author profile →