Is Your Drupal Site a Security Risk? 5 Signs You Need to Migrate Now

11 min readBlueDrop IT
securitymigrationauditdrupal

You patched Drupal core last week. The site loads. There are no obvious errors. So you're fine — right?

Not necessarily. Drupal sites accumulate risk in places that don't show up on a status page or an uptime monitor. By the time the symptoms become obvious, the work to fix them has multiplied.

This article is a triage tool. Five concrete signs your Drupal site is becoming a security liability, each with a hands-on check you can run today. If three or more apply, the question is no longer whether to migrate — it's how fast.

If your site is on Drupal 7, start with our deeper look at the Drupal 7 end-of-life. The signs below apply to every version — including Drupal 9 and 10 sites that look healthy but have been quietly accumulating exposure.

Sign 1: Your PHP version is at or near end-of-life

PHP version drift is one of the most under-noticed Drupal security risks. Drupal 10 requires PHP 8.1+; Drupal 11 requires PHP 8.3+. Sites stuck on EOL PHP inherit every unpatched CVE in that runtime, regardless of how current Drupal core is.

PHP support timeline:

  • PHP 8.0 — EOL November 2023
  • PHP 8.1 — EOL December 2025
  • PHP 8.2 — EOL December 2026
  • PHP 8.3 — supported through December 2027
  • PHP 8.4 — current stable

Run this check

drush php:eval 'echo PHP_VERSION;'
# or directly on the server
php -v

Cross-reference the output with the official PHP supported versions list. Anything below PHP 8.2 is on borrowed time. Anything below 8.0 is already past EOL.

If your hosting provider is still advertising "PHP 7.4 with extended support," that's a paid lifeline, not a fix. Treat it the same as Drupal Extended Security Support: a stopgap, not a destination.

Sign 2: Contrib modules that haven't been updated in years

Drupal core gets the most attention, but a typical site runs 30–60 contributed modules. Each is an independent project with its own maintainer and its own decay curve. A module that hasn't shipped a release in 24+ months is running unpatched third-party code in your stack — even if Drupal core is on the latest patch.

Run this check

drush pm:list --status=enabled --type=module --no-core --format=table

For each module, open its drupal.org project page and look for two things:

  1. Last release date. Older than two years on a 9-month Drupal release cadence is a red flag.
  2. Security coverage status. A banner reading "This project is not covered by the security advisory policy" means even discovered vulnerabilities will not get coordinated patches.

Triage each enabled module into one of three buckets:

  • Green — actively maintained, latest release within the last 12 months, security coverage in place.
  • Yellow — maintained but version trails core, or security coverage is partial. Plan replacement.
  • Red — no release in 24+ months, or no security coverage. Replace or remove now.

A site with more than five reds is not a maintenance problem. It's a migration project waiting to be scoped.

Sign 3: Unfamiliar user accounts or rising form spam

The classic indicator of an in-progress compromise: user accounts and content you didn't create. By the time these are visible in the admin UI, the attacker has typically been on the site for weeks. Spam volume on contact and registration forms is the same problem in a less-alarming costume — bot traffic that has decided your site is worth attacking.

Run this check

drush sql:query "SELECT name, mail, FROM_UNIXTIME(created) AS created
                 FROM users_field_data
                 WHERE created > UNIX_TIMESTAMP(NOW() - INTERVAL 90 DAY)
                 ORDER BY created DESC;"

Scan the output for:

  • Accounts created when public registration is supposedly disabled (it isn't disabled if the registration form is still reachable).
  • Random-string usernames like kj923jkl9d — bots.
  • Disposable email domains (mailinator.com, tempmail.io, guerrillamail.com).
  • Accounts assigned to administrative roles without a corresponding ticket or approval trail.
  • Spikes — 40 accounts created on the same day with no marketing activity.

Then check watchdog for repeated failed login attempts:

drush watchdog:show --type=user --severity=Warning --count=50

A constant trickle of failed logins from rotating IPs is brute-forcing. If you have no rate-limiting (Flood Control), no CAPTCHA, and no two-factor on admin accounts, the brute force will eventually succeed.

Sign 4: Outdated security configuration

The HTTP security headers and configuration defaults that are standard in 2026 didn't exist — or weren't widely adopted — when most older Drupal sites were built. Sites that haven't been re-hardened in years pass the eye test but fail every contemporary audit.

Run this check

curl -sI https://your-site.com/ | grep -iE 'strict-transport|content-security|x-frame|x-content-type|referrer|permissions-policy'

At minimum you should see:

  • Strict-Transport-Security with max-age >= 31536000 and includeSubDomains
  • Content-Security-Policy set explicitly (a stub default-src 'self' is not enough)
  • X-Content-Type-Options: nosniff
  • X-Frame-Options: DENY or SAMEORIGIN
  • Referrer-Policy: strict-origin-when-cross-origin or stricter
  • Permissions-Policy declaring which browser features your site uses

Then audit file system posture:

  • settings.php permissions: stat -c '%a' web/sites/default/settings.php should return 440 or 444, not 644.
  • find web/sites/default/files -type f -perm -o+w should return nothing — no world-writable files.
  • Direct access to vendor/, private/, and composer.json should return 403 from a browser.

Finally, run Mozilla Observatory against your domain. The graded report takes one minute and produces an actionable list. Anything below B is a finding.

Sign 5: Compliance gaps you've been pretending don't apply

Even if your site is "secure enough" by your own internal standards, regulatory frameworks have tightened in the last few years. PCI DSS 4.0, HIPAA Security Rule, SOC 2 Common Criteria, and GDPR Article 32 all read unsupported software as a control failure. The grace period most auditors gave during the 2023–2024 transition is over.

Run this check

  1. Get the absolute facts: drush status (Drupal version + PHP version + database version + active config).
  2. Confirm support status. Drupal 7 lost coverage in January 2025. Drupal 8 lost coverage in November 2021. Drupal 9 lost coverage in November 2023. Drupal 10 is currently supported, with end-of-life targeted for December 2026.
  3. Cross-reference your data classification: PII, payment data, PHI, regulated data. The higher the data class, the shorter your remediation window.
  4. Check your audit calendar. The next PCI assessment, SOC 2 readiness review, or vendor security questionnaire is the real deadline — not the abstract concept of "secure software."

For a deeper look at what compliance frameworks specifically flag, see Drupal 7 end-of-life: what it means for your website security. The compliance pattern applies equally to any unsupported Drupal version.

What happens when you ignore these signs

The cost curve is non-linear. Three patterns recur in our migration intake:

Slow degradation, sudden incident. The site runs unpatched for months. A vulnerability scanner finds it, an attacker exploits it, and you're doing forensics at 2 AM with PR and legal on the call. Recovery cost scales with dwell time — every month the breach went undetected adds to the cleanup.

Audit failure with no migration plan. Your annual SOC 2 or PCI assessment flags the unsupported software. You now need a migration on a 30-day timeline against an external deadline. The price is 2–3x a planned migration, and the result is worse — corners get cut where they shouldn't.

Compounding maintenance debt. Every month you delay, more modules deprecate, more PHP versions reach EOL, more dependencies break. A migration that scoped to 12 weeks last year scopes to 16 weeks this year and 20 weeks next year.

The cheapest migration is the one you start before you have to.

Your migration path: immediate, short-term, medium-term

You don't have to choose between "do everything now" and "do nothing." Stage the work.

Immediate (this week)

  • Run all five checks above. Write down what you find — even the ones that come back clean.
  • Apply pending security updates: composer update "drupal/core-*" --with-dependencies, then drush updb -y and drush cr.
  • If sign 3 turned up suspicious accounts: lock public registration, force password resets for every administrator, rotate API keys in settings.php and external services.
  • Verify backups: when was the last successful run? When was the last tested restore? Both answers should be measured in days, not months.

Short-term (next 30 days)

  • Inventory every enabled contrib module. Tag green/yellow/red. The red list is your migration scope preview.
  • Address the easy wins from your Mozilla Observatory report: HSTS, X-Content-Type-Options, X-Frame-Options. These are config changes, not code changes.
  • Audit roles and permissions. Review every account with administer permissions or similar. Disable rather than delete, so the audit trail remains.
  • If PHP is at or near EOL, schedule the PHP upgrade as a discrete project — don't wait to bundle it with the Drupal migration.

Medium-term (60–90 days)

  • Pick a target version. Drupal 11 is the recommended target as of 2026; choose Drupal 10 only if a specific dependency forces it.
  • Scope the migration: contrib replacement plan, theme rebuild, content audit, redirects map, integrations.
  • Get two or three quotes if you're outsourcing. Compare scope and migration philosophy, not just price.
  • Pick a launch window that doesn't collide with audits, traffic peaks, or holiday code freezes. Build in 2–3 weeks of buffer between cutover and your next external review.

If the immediate-week checks surface severe findings — active spam at scale, credentials in version control, no working backup, exposed admin paths — collapse the timeline. Treat it as incident response, not maintenance planning.

Frequently asked questions

How can I tell if my Drupal site has already been compromised?

Look for what you didn't create: new admin accounts, modified content (especially in node bodies and templates), unfamiliar files under sites/default/files/, unrecognized scheduled cron jobs, and unusual entries in your watchdog log. Run drush watchdog:show --severity=Error --count=100 and skim. If you find one indicator, assume there are more — take a forensic snapshot before any cleanup so you preserve evidence.

Is Drupal 10 still secure, or do I need to migrate again?

Drupal 10 currently receives security advisories, but its end-of-life is targeted for December 2026. The same pressure that hit Drupal 7 in January 2025 will arrive for Drupal 10 within roughly seven months. If you're starting a migration today, target Drupal 11 directly to avoid a near-term repeat.

Can I just patch instead of migrating?

On a supported Drupal version (10 or 11), yes — patching is the path. On Drupal 7, 8, or 9, no. Those versions have reached end-of-life, which means new vulnerabilities will not get core patches. A patch-only strategy on an unsupported version is a holding action, not a fix.

What's the cheapest way to assess my Drupal site's risk?

The five checks in this article take about an hour total and require nothing beyond drush, curl, and a browser. For an automated second opinion, install the Security Review module and run Mozilla Observatory. For a human read, most Drupal agencies — BlueDrop IT included — will do a free 30-minute assessment.

How urgent is migrating off Drupal 9?

Drupal 9 reached end-of-life in November 2023. If you're on D9 in 2026, you have been running unsupported software for over two years. The urgency profile is the same as Drupal 7: every month of delay compounds migration cost and security exposure. Plan the move within 90 days.

Does hardening my current site delay or replace migration?

Hardening is necessary regardless. It buys you safety during the migration window and reduces incident risk while you finish. It does not replace migration on an unsupported version. Run both tracks in parallel.

Get a free migration risk assessment

If three or more of these five signs apply to your site, you already have a migration project — you just haven't named it yet. We've moved Drupal sites through every version transition since Drupal 6 and can deliver a concrete scope, timeline, and risk readout in 30 minutes.

Schedule a free Drupal migration consultation →