Drupal 7 One Year After End of Life: The Growing Compliance and Security Gap

Drupal 7 hit end of life in January 2025. That means the Drupal core security team stopped shipping security fixes for Drupal 7 core, even when the same vulnerabilities exist and are fixed in modern Drupal core or modules. This same reality applies to the huge ecosystem of contributed modules that many production sites still depend on.

If you run Drupal 7 in a regulated or security-sensitive environment, this puts you in an awkward spot. Your platform might still be stable operationally, but your compliance obligations did not go away. And the vulnerabilities showing up after EOL make it clear this is not a hypothetical problem.

‍

Post-EOL vulnerabilities are real (and they keep coming)

Since Drupal 7’s end of life, every month between 2 and 6 vulnerabilities are identified in widely used contributed modules. These vulnerabilities frequently have high severity scores signaling the potential for unauthorized system access and other threats. The difference now is simple: these issues are no longer eligible for official Drupal 7 fixes, even when they are actively exploitable in the real world.

‍

Here are a few of the many examples HeroDevs has patched in our Drupal 7 Never Ending Support:

XSS vulnerabilities in common modules:

• Form Builder (CVE-2026-0749)
  
  
• Webform (CVE-2025-12848)
  
  
• Facebook Pixel (CVE-2025-14557)
  
  
• Colorbox (CVE-2025-3900)
  
  
• Coffee (CVE-2024-13247)
  
  

Access control and authorization issues:

• Access Code (SA-CONTRIB-2025-028): broken access controls
  
  
• View Bulk Operations (SA-CORE-2025-002): privilege and access boundary violations
  
  

Higher-integrity risks:

• Commerce Paybox signature forgery (CVE-2026-0750), which impacts payment workflows
• jquery-BBQ Prototype Pollution (CVE-2021-20086) allowing malicious property injection

‍

These are not weird edge-case modules nobody uses. They are foundational building blocks in a lot of long-lived Drupal 7 installs. The pattern is consistent and with tens of thousands of Drupal 7 modules still widely used, we don’t expect the pace of vulnerability discovery to stop.  The problem owners of Drupal 7 sites now face is that vulnerabilities still get discovered but the official remediation path stopped.

‍

Why compliance teams care (even if “nothing has happened” yet)

Most compliance frameworks (PCI DSS, HIPAA, SOC 2, ISO 27001, FedRAMP, and others) boil down to a shared expectation: known vulnerabilities must be fixed within defined timelines.

‍

So if you are running software that:

• is no longer supported by upstream maintainers, and
  
  
• continues to rack up publicly disclosed CVEs,
  
  

you are in a tough position. Even if the system feels “fine,” the inability to patch can be interpreted as failing to maintain reasonable security controls.

From a risk and audit standpoint, three problems stack up quickly:

• Documented exposure: CVEs are public, timestamped, and attributable.
  
  
• No upstream fix: there is no official patch path.
  
  
• Audit defensibility: “planned migration” usually is not enough by itself.

‍

Migration is the right endgame, but it is not an immediate fix

For most orgs, migrating off Drupal 7 is the correct long-term strategy but this isn’t a task taken lightly. The path from Drupal 7 to modern Drupal is usually a complete rebuild. So the issue is timing, a large customized Drupal 7 platform often supports critical business processes, and migrations can take years, not months.

In the meantime, you still have to do the work:

• patch newly disclosed vulnerabilities
  
  
• show active vulnerability management
  
  
• meet SLA-backed remediation timelines.
  
  

Without supported security updates, that story gets harder and harder to defend to auditors, customers, and regulators.

‍

Where extended security support fits

This is the gap extended support is meant to cover. For example, HeroDevs’ Drupal 7 Never-Ending Support (NES) is positioned as a governance and risk solution while migration is in progress, not a replacement for migration.

Extended support is intended to:

• provide ongoing security fixes for newly disclosed vulnerabilities
  
  
• cover both core and contributed modules
  
  
• offer documented SLAs that align with compliance requirements
  
  
• reduce the risk exposure window during long migrations.
  
  

And in practice, that includes ongoing work like the daily vulnerability review (reviewing new vulnerabilities that may affect modern Drupal and understanding the risks to Drupal 7) and regular patch releases HeroDevs does for Drupal 7 module risks as part of extended end-of-life support.

‍

The real question in a post-EOL world

Drupal 7’s end of life did not stop vulnerability discovery. It removed the official mechanism for remediation. That is why the list of post-EOL CVEs matters: unpatched Drupal 7 systems accumulate measurable, auditable risk over time.

For IT leaders and compliance teams, the question is not “Are we still running Drupal 7?”
It is:

• How are newly disclosed vulnerabilities being addressed?
  
  
• Can we prove timely remediation?
  
  
• Is our risk posture defensible today, not just after the migration is done?

Post‑EOL Drupal 7 is a compliance problem, not just a technical one: vulnerabilities keep surfacing and there’s no community-supported upstream patch path. Although migration is the  destination, extended security support is the bridge that keeps sites secure until the migration happens.

‍

FAQs

‍

Q: When did Drupal 7 reach end of life?
A: Drupal 7 reached end of life in January 2025, meaning the Drupal core security team no longer provides security patches for core or contributed modules.

Q: Are new vulnerabilities still discovered in Drupal 7 after end of life?
A: Yes. Post-EOL, between two and six vulnerabilities per month continue to be disclosed in widely used Drupal 7 contributed modules, including XSS, access control flaws, and high-integrity risks.

Q: Why is running Drupal 7 after EOL a compliance problem?
A: Most compliance frameworks require timely remediation of known vulnerabilities. Once upstream support ends, organizations can no longer patch CVEs through official channels, creating documented and auditable risk.

Q: Does “nothing has happened yet” reduce audit or security risk?
A: No. CVEs are public, timestamped, and attributable. Auditors typically focus on whether known vulnerabilities are being addressed, not whether an incident has already occurred.

Q: Is migration off Drupal 7 the only solution?
A: Migration to modern Drupal is the correct long-term solution, but it is often a multi-year rebuild. Migration alone does not address newly disclosed vulnerabilities during the transition period.

Q: How can organizations manage Drupal 7 risk during long migrations?
A: Extended security support can provide ongoing patches for newly disclosed vulnerabilities, cover contributed modules, and offer SLA-backed remediation aligned with compliance requirements.

Q: What is the real risk of post-EOL Drupal 7?
A: The risk is cumulative and measurable. Vulnerabilities continue to surface, there is no community-supported patch path, and unpatched CVEs weaken an organization’s ability to defend its security posture to auditors, customers, and regulators.

‍

‍