 ![](/sites/default/files/media/image/2026-11/drupal-open-security-icon-v2.svg)

 

 

 Image

        ![John Money](/sites/default/files/styles/post_content_attribution_headshot/public/media/image/2026-11/Blue.png?h=3cd06fc8&itok=NGTm7jm1) 

 

 

 

 [John Money](/about-us/team/john-money) Director, Product Marketing, Platform &amp; Drupal Acquia

 

 

 

 

Put every Drupal security fix into production.

 

[Book a Demo](https://www.acquia.com/products/acquia-cloud-platform#form)

 

 

 

 



# Drupal's Open Security Model Wins in the Age of AI

Published: November 10, 2026

Last Updated: November 12, 2026

9 minute read

 

 [Share this blog post on LinkedIn

 ](https://www.linkedin.com/sharing/share-offsite/?url=https://www.acquia.com/markdownify/node/61881) [Share this blog post on Twitter

 ](<https://twitter.com/intent/tweet?text=Drupal's Open Security Model Wins in the Age of AI&url=https://www.acquia.com/markdownify/node/61881&via=acquia>) [Share this blog post via Email

 ](<mailto:?subject=Drupal's Open Security Model Wins in the Age of AI&body=https://www.acquia.com/markdownify/node/61881>)   Copy Markdown  

 

 

 AI can read any codebase, open or closed. See why Drupal’s public security process, exploit data, and module coverage make open source the safer CMS choice. 

 ![](/sites/default/files/media/image/2026-11/drupal-open-security-icon-v2.svg)

 

 

**Key takeaway:** An open source CMS can be more secure than a closed one, because security depends on how fast flaws are found and fixed, not on hiding the code. AI now reads open and closed code alike. Drupal pairs public code with a dedicated Security Team, scheduled advisories, and coverage for its most-used modules.

## The enemy will learn how your system works

In 1883, Auguste Kerckhoffs, a Dutch-born linguist teaching in Paris, published two articles on military cryptography. He listed six rules for a field cipher. One of them has outlived the telegraph, the Enigma machine, and the Cold War: a system must not require secrecy, and it must be able to fall into enemy hands without harm.

Kerckhoffs was thinking of cipher equipment carried by soldiers who might be captured. His logic was simple. Assume the enemy will learn how your system works. Build it so that the knowledge does not help them.

Security engineers have repeated that rule for more than 140 years. The National Institute of Standards and Technology put it in [federal guidance in 2008](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf): "System security should not depend on the secrecy of the implementation or its components."

The opposite belief still survives in enterprise software buying. Recently, a manufacturer told one of our partners that it requires a high level of security, so an open source CMS was not an option.

That belief deserves a direct answer, and in 2026 the answer has sharpened. AI can now read any codebase, open or closed. Kerckhoffs's enemy has the machine. What matters now is who finds the flaws first, and who fixes them in the open.

## How AI changes open source vs. closed source security

Security through obscurity was always a questionable defense. In the age of agentic AI, it is indefensible. Three shifts in the past year explain why.

**Finding flaws is now cheap.** Anthropic reported in May 2026 that its Claude Mythos Preview model scanned more than 1,000 open source projects and [flagged 23,019 potential vulnerabilities](https://anthropic.com/research/glasswing-initial-update), about 6,200 of them rated high or critical. Of the high- and critical-severity findings reviewed by humans, 90.6% were valid. In October, Anthropic opened a [free scanning service to open source maintainers](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source). Open source projects now get frontier-model security review at no cost. A proprietary vendor has to fund the equivalent on its own.

**Closed code is readable.** In March 2026, a researcher at the cloud security firm Wiz used an AI reverse engineering assistant on the compiled, [closed-source binaries of GitHub Enterprise Server](https://darkreading.com/application-security/reverse-engineering-ai-unearths-high-severity-github-bug) and found a high-severity remote code execution flaw. "It's become much easier, faster, and cheaper to do things like reverse-engineer closed-source binaries," he told Dark Reading. Attackers have the same tools. Closed code keeps out the defenders who would have reviewed it.

**The window to patch has collapsed.** VulnCheck found that [28.96% of the flaws first exploited](https://www.vulncheck.com/blog/state-of-exploitation-2026) in 2025 were attacked on or before the day they were published, up from 23.6% the year before. Content management systems ranked second among the most targeted technologies. When attackers move that fast, the time from discovery to a deployed fix decides the outcome. Drupal ships the fix with the advisory, so site owners know exactly what to patch, and when.

## Is open source less secure because anyone can read the code?

The instinct behind "open source is not secure enough" is easy to understand. If anyone can read the code, attackers can read it too. Open source projects also publish a steady stream of security advisories, and a long list of advisories looks like a long list of problems. Supply chain incidents, such as the 2024 backdoor planted in the xz-utils compression library, add to the unease.

Each of those concerns misses how security works in practice. Published code gives the same view to defenders, researchers, and customers, and they outnumber the attackers. Security technologist Bruce Schneier [wrote in 1999](https://www.schneier.com/crypto-gram/archives/1999/0915.html), "Public security is always more secure than proprietary security." The xz-utils backdoor makes the case: an engineer outside the project noticed half a second of extra login delay, traced it to the source, and raised the alarm before the code reached mainstream Linux releases. That is only possible when the code is public.

"Public security is always more secure than proprietary security."

\- **Bruce Schneier**, Founder &amp; CTO, Counterpane Internet Security

The question for a CIO is which model finds flaws faster, discloses them honestly, and gets fixes into production first. On that question, Drupal has a strong record and the data to back it, starting with what attackers exploit.

## What the exploit data shows

Counting vulnerabilities tells you how much scrutiny a codebase gets. A published CVE means someone looked, found a flaw, and fixed it in public. A short list can mean clean code, or it can mean few people are looking.

The better measure is what attackers use. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) keeps a catalog of [Known Exploited Vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog): flaws confirmed to be exploited in the wild. Divide a platform's entries in that catalog by its published CVEs, and you get the share of its disclosed flaws that attackers turned into working attacks.

About 2% of Drupal core’s published CVEs appear in CISA’s Known Exploited Vulnerabilities catalog, compared with 11.4% of Sitecore’s.

CMS

Published CVEs

Known exploited

Share exploited

Sitecore

35

4

11.4%

Drupal core

~219

5

~2%



*Sources:* [*National Vulnerability Database*](https://nvd.nist.gov/) *and CISA Known Exploited Vulnerabilities catalog, November 6, 2026. The Drupal core count excludes CVEs for contributed modules.*

For comparison, take Sitecore, a closed source CMS that competes for the same enterprise buyers as Drupal and has enough published CVE history to measure. Drupal publishes about six times as many CVEs as Sitecore. Attackers have exploited about one in 44 of Drupal's published flaws, and about one in nine of Sitecore's. One conclusion is that the platform that discloses more gets exploited less.

Attackers did not need Sitecore's source code to find and exploit its flaws. Keeping the code closed did not stop them.

## How Drupal does security in public

Drupal's record reflects a process, run by people, on a published schedule.

**A dedicated Security Team.** The [Drupal Security Team](https://www.drupal.org/drupal-security-team) is a standing group of experienced community members, including engineers from Acquia. Researchers report issues to the team privately. The team works with maintainers on a fix, keeps the issue confidential until the fix is ready, and then publishes an advisory and the patched release together.

**A fixed window and a published risk score.** Security releases ship on Wednesdays, so IT teams can plan for them. Every advisory carries a risk score out of 25, calculated from published criteria. For the most dangerous issues, the team posts a public service announcement days ahead so site owners can line up staff before the release.

**AI on defense, in the open.** In September 2026, the Drupal Security Team shipped the largest batch of advisories in its history. Much of it came from a maintainer who used an AI model to audit Webform, one of Drupal's most-installed modules, and fix what he found. The Drupal Association has also [received funding from the Linux Foundation's Alpha-Omega project](https://www.drupal.org/association/blog/drupal-association-secures-alpha-omega-grant-to-future-proof-open-source-security-for-the-ai-era) for a Drupal AI Security Initiative. A spike in advisories like that is a project finding its own flaws first and fixing them in public.

Drupal's record is not spotless. Drupalgeddon 2 in 2018 was exploited at scale, and a May 2026 SQL injection flaw affecting sites on PostgreSQL drew attacks two days after its advisory. In both cases, the fix shipped with the disclosure, and the risk fell on sites that had not yet updated.

## Drupal vs. WordPress security: core and add-ons

Open code is the starting point. Security depends on who reviews that code, who coordinates the fixes, and whether the process reaches the add-ons a site runs. On that last point, the two largest open source CMS projects, Drupal and WordPress, take different paths.

**Coverage for add-ons as well as core.** This part of Drupal's model gets the least attention. A Drupal module maintainer can opt into [security advisory coverage](https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or-distribution-project/security-coverage/opting-into) after a one-time review of their code. From then on, the Security Team handles flaws in that module through the same private reporting, coordinated fix, and Wednesday advisory process it uses for core. Each covered project carries a visible shield on its Drupal.org page.

The add-ons Drupal sites depend on are almost all covered. Of the 100 [most-installed contributed projects](https://www.drupal.org/project/usage) on Drupal.org, 99 have security advisory coverage. The one exception is the legacy CKEditor 4 module, which CKEditor 5 in core has replaced.

WordPress's security team focuses on WordPress core. Advisories for plugin flaws come mostly from commercial security firms such as Patchstack and Wordfence, each working with individual plugin developers on their own schedules. The volume is large. Patchstack, which sells WordPress security services, counted [11,334 new vulnerabilities in the WordPress ecosystem](https://www.patchstack.com/whitepaper/state-of-wordpress-security-in-2026/) in 2025: 91% in plugins, 9% in themes, and only 6 in core. Almost half, 46%, became public before the developer had released a fix.

Drupal is one of the few platforms, open or closed, where the same security process covers both the core and the add-ons sites depend on.

## "But we have a pen test"

Proprietary vendors, especially SaaS vendors, will answer all of this with a penetration test. Pen tests are valuable, and every serious platform should run them. A pen test is a sample. Open source review, properly implemented like Drupal, is a process.

A pen test examines one version of a product, at one point in time, within a scope the vendor chooses, usually once a year. Meanwhile, the product ships new releases, and attackers start working on new flaws the day they become public. Even more, a pen test cannot check what it was never scoped to look at.

A pen test also stops at the vendor's own code. Proprietary vendors often push third-party add-on security fixes to the marketplace publisher, and do not incorporate the fixes into their own advisory process.

Drupal gets reviewed by its Security Team, by module maintainers, by independent researchers, and now by AI scanners that run regularly. None of that requires an NDA to verify.

## Is Drupal secure enough for the enterprise?

Kerckhoffs assumed the enemy would capture the machine. In 2026, the enemy does not need to. AI can read any codebase, open or closed, at a speed no human team can match.

That leaves one question for every organization that runs a CMS: when a flaw is found, who finds it first, and how fast does the fix reach production? **Drupal's answer is public.** A standing Security Team, a published process, coverage for the add-ons sites use, and AI working on defense in the open.

[Open source, run with Drupal's discipline](https://www.acquia.com/blog/reasons-not-use-drupal-debunking-5-common-myths), is the secure choice. Everything about it is open to inspection, including its mistakes.



 

 Image

        ![John Money](/sites/default/files/styles/post_content_attribution_headshot/public/media/image/2026-11/Blue.png?h=3cd06fc8&itok=NGTm7jm1) 

 

 

 

 [John Money](/about-us/team/john-money) Director, Product Marketing, Platform &amp; Drupal Acquia

 

 

 

 

 

 [Share this blog post on LinkedIn

 ](https://www.linkedin.com/sharing/share-offsite/?url=https://www.acquia.com/markdownify/node/61881) [Share this blog post on Twitter

 ](<https://twitter.com/intent/tweet?text=Drupal's Open Security Model Wins in the Age of AI&url=https://www.acquia.com/markdownify/node/61881&via=acquia>) [Share this blog post via Email

 ](<mailto:?subject=Drupal's Open Security Model Wins in the Age of AI&body=https://www.acquia.com/markdownify/node/61881>)   Copy Markdown  

 

 

 

 

## Frequently Asked Questions

  Is an open source CMS secure enough for the enterprise?

   Yes, when it’s run with a disciplined security process. Security depends on how quickly flaws are found, disclosed, and fixed, not on whether the code is public. Drupal pairs open code with a dedicated Security Team, scheduled advisories, and published risk scores.



 

 

  Does AI make open source software less secure?

   No. AI can now read and analyze both open and closed code, including compiled binaries. What AI changes is the speed of discovery, which makes a fast, public process for fixing flaws more important than keeping code hidden.



 

 

  How does Drupal handle security vulnerabilities?

   Researchers report issues privately to the Drupal Security Team, which works with maintainers on a fix and keeps the issue confidential until it’s ready. The advisory and the patched release ship together, usually on a Wednesday. Each advisory carries a risk score out of 25.



 

 

  Is Drupal more secure than WordPress?

   The two take different approaches to add-ons. Drupal’s Security Team covers opted-in contributed modules through the same process it uses for core, and 99 of the 100 most-installed projects have that coverage. WordPress’s security team focuses on core, and most plugin advisories come from commercial security firms.



 

 

  Is security through obscurity effective?

   No. Security through obscurity relies on keeping a system’s design secret, and security engineers have rejected that approach since Auguste Kerckhoffs set out the principle in 1883. NIST’s federal guidance states that system security should not depend on the secrecy of the implementation or its components. AI has made obscurity even weaker, because tools can now analyze closed code as easily as open code.



 

 

 

 

 

## Keep Reading

 [View More Resources](/resources) 

  [Image

        ![](/sites/default/files/styles/card_tablet/public/media/image/2026-11/php2shell-blog-icon-v2%201.png?h=10d202d3&itok=Z22WRtsO) 

 

 

 

 Blog Article 6 min 

######  PHP2Shell and the New Clock for Patching

 AI found a 14-year-old PHP flaw in weeks. Here is how Acquia patched every Drupal application it hosts the same day, with sites online throughout. 

 Read article  

 

 ](/blog/php2shell-and-new-clock-patching)



  [Image

        ![Two boxing gloves facing each other with "DRUPAL vs. WORDPRESS" text in blue outline style](/sites/default/files/styles/card_tablet/public/media/image/2026-01/Blog%20Graphic-Drupal-Drupal%20vs.%20Wordpress_%20Which%20Platform%20is%20Better_.png?h=c3635fa2&itok=5ePQ9o-q) 

 

 

 

 Blog Article 11 min 

######  Drupal vs WordPress Comparison: Choose the Right CMS for 2026

 We break down the pros and cons of Drupal versus WordPress when it comes to selecting the best content management system for your organization. 

 Read article Drupal  

 Drupal 

 ](/blog/drupal-vs-wordpress-comparison-choose-right-cms-2026)



  [Image

        ![Group of three people above the word Drupal](/sites/default/files/styles/card_tablet/public/media/image/2023-06/Blog%20Graphic-Drupal-Acquia%20vs.%20DIY_%20Why%20You%20Shouldn%E2%80%99t%20Go%20It%20Alone%20with%20Drupal%20Hosting.png?h=10d202d3&itok=zqlZgA6k) 

 

 

 

 Blog Article 6 min 

######  Acquia vs. DIY: Why You Shouldn’t Go it Alone with Drupal Hosting

 Drupal DIY efforts aren’t scalable, lack security and, ultimately, cost more time and energy than expert Drupal hosting with Acquia. 

 Read article Drupal Hosting  

 

 ](/blog/acquia-vs-diy-why-you-shouldnt-go-it-alone-drupal-hosting)