Drupal has long relied on organisations and individuals who contribute beyond their immediate needs. Yet that responsibility remains unevenly distributed. According to figures published by the Drupal Association in February 2025, just 219 of the 1,440 organisations active on Drupal.org accounted for 96% of recorded contributions in 2024. The challenge is not simply attracting more contributors, but making responsibility for Drupal's upkeep more widely shared.
Two proposals outlined by Drupal Association Interim CEO Tiffany Farriss on 28 October 2026 suggest how that might happen. A broader Drupal Certified programme could recognise makers, patrons and advocates, extending recognition beyond agencies. Alongside it, a dedicated maintainers fund could help organisations without development capacity financially support the people maintaining software they depend on.
Together, these proposals revisit Dries Buytaert's long-standing makers-and-takers argument. They also raise questions about what counts as a fair contribution. Financial support cannot automatically substitute for technical responsibility, and certification must recognise different capacities without favouring organisations that can afford to pay. How funding reaches maintainers, and how their work is valued, will matter as much as the proposed framework itself.
Neither proposal has been implemented. Their significance lies in an attempt to move from contribution as an expectation placed on a committed minority towards a responsibility shared across the ecosystem. Drupal will remain freely available, but sustaining that freedom requires continuing work. The real test is whether more beneficiaries can help support it without compromising the openness and independence that make Drupal worth maintaining.
Follow The DropTimes on LinkedIn and Bluesky, or join #thedroptimes on Drupal Slack.
Allen Jason wrote and curated this issue of Editor’s Pick.
In the Open is a weekly series from Drupal Association Interim CEO Tiffany Farriss, sharing what she is hearing across the Drupal community and where the Association is headed. In this episode: how AI is changing vulnerability discovery for everyone, what the Drupal Security Team and the Alpha-Omega funded SEIR program have achieved in five months, and how site owners, hosts, and organizations can help.
"In Drupal now that finding these bugs is really cheap, fixing them and fixing it safely is not."
The following is a transcript of Tiffany’s remarks, lightly edited for readability.
What’s changing for everyoneToday I want to talk about security. I think Drupal’s story is about a community that is adapting pretty well to some pretty trying times.
I want to talk about what’s changing for everybody, what we do, what we’ve seen so far, and then how you can help and get involved.
It’s a completely new situation in the last 12 months. AI-assisted analysis is making finding vulnerabilities cheap and automatable in commercial software and open source software. It’s not a Drupal problem. It’s not an open source problem. It’s an everyone problem.
AI is astonishingly good at finding vulnerabilities. And it’s not just individual vulnerabilities, it’s about chaining them together. In COVID, we all learned about the Swiss cheese model of safety, the idea being that the holes in the cheese don’t line up in the various layers. But AI is just so good at figuring out how to chain one vulnerability to another one, to another one, and it navigates it at a pace and in a way that we just haven’t ever seen before.
From an open source perspective, we know that open source is in almost everything. 96% of all applications use open source libraries, and every vendor’s product inherits the security of all of the dependencies, whether they’re in your software or they’re in open source.
One of the core problems that all of open source is looking to solve, and that I’m looking to solve for Drupal, is that companies expect enterprise-grade security from people who are fundamentally volunteers. They’re either volunteer maintainers or, in the case of Drupal, a largely volunteer security team.
To address this, Alpha-Omega, which is a project of the Linux Foundation, has been funding security experts in residence for a broad swath of the ecosystem. They’ve been doing it for PHP, Node, Ruby, Rust, Python, Perl, Erlang, FreeBSD, Eclipse, and now Drupal. I think Drupal is the first one of our layer of open source software to be included, and we’re super, super grateful.
And it’s not just about the funding that we’ve gotten from Alpha-Omega. It’s the fact that we’ve been invited into this cohort to share ideas and resources with each other. That makes it feel like every ecosystem is really working on this together.
How Drupal security works todayFor those who aren’t as familiar with what Drupal already does, we have one of the most amazing security teams. If you see any member of the security team, you need to thank them, because as a largely volunteer effort they have protected millions of sites for over two decades.
One of the things people are often surprised about is that not only do we have very mature practices, but we use our own scoring method and we have our own CVE numbering authority, which a lot of folks aren’t. Our coverage includes core and then contributed projects that opt into security coverage.
Several years ago, our security team came up with the idea of Drupal Steward. Drupal Steward is web application firewall rules that protect against any critical or highly critical issue that is preventable by a WAF, or web application firewall. We distribute those rules to any of the trusted Drupal Steward partners. There was also a community tier that allowed people to put the Drupal Steward WAF in front of their WAF. That last product hasn’t been as successful. People haven’t really been able to put their WAF behind our WAF. So really, the folks who end up being protected are the ones who get it through their hosts.
In the first several years of Drupal Steward being available, it wasn’t activated very much. We didn’t have very many vulnerabilities that were preventable by a WAF or that were that critical, and the pace was much, much slower. This year it has been activated, I think, three times already. Given what we’re seeing across all of open source, I do expect there will be more activations to come.
If you’re already working with one of the partners that is a member of Drupal Steward, you’re protected. But we’re also working on a new way to distribute our WAF rules through CDX, and I hope to be able to share more about that in the future.
I want to talk a little bit about those partners who are members of Drupal Steward, because they’re ones who are known to us. The way the program is designed, these partners have members of the security team. That’s critical for us for a couple of different reasons.
One, it keeps our circle of trust really small. Advanced notice is only as safe as the smallest group that holds it. When we’re working through an organization that already has an existing security team member, the early details stay with an organization that already had access to them. They know they’re bound by the security team’s disclosure policy, and that policy makes it really clear that you can’t disclose this beyond what gets disclosed publicly to everyone. So there’s no inherent advantage.
But security work in Drupal takes Drupal expertise. Any of the fixes that we put into Drupal Steward require knowing how to block the exploit itself without blocking or breaking existing real sites. So the Drupal context is as important as the WAF rules.
What the last five months have shown usOur team responds to reports. That’s the operating MO. One of the things the SEIR grant has allowed us to do was to actually begin doing some scans on different pieces of it. What we found, and this is in a blog post I released a few days ago, is that AI reporting has gotten so easy to do that we instead shifted the time from the folks who are in SEIR to really focusing on fixing, and then creating some very durable tools to help us manage this onslaught.
If you hadn’t caught up on the post: in the five months that we’ve been involved in the SEIR project, from June through the end of October, there were 256 advisories issued by our security team. That’s more than the previous 30 months combined. Prior to the start of this June wave, there were generally around eight per month.
We also found that the number of credited reporters since June has more than doubled since last year. There were 134 credited reporters since June alone, in this five-month period. In all of last year, there were 68. I think this gives us some sense of how fast these issues are being found and disclosed.
But I also think it’s important that we’re really clear that it doesn’t mean the code got worse. It just means that we’ve gotten better at finding these issues, and it’s now cheaper to do so.
In Drupal, now that finding these bugs is really cheap, fixing them, and fixing them safely, is not. That still takes deep Drupal knowledge. What we promise, both in our security team releases and in Drupal Steward, is that you fix the vulnerability but you also care that you can’t break anything. So the security fixes make the smallest change that closes the security gap. We want to make sure that there are no new APIs and no breaking changes when possible. If any of our updates break sites, it decreases the number of people who’d be willing to apply them. And an unapplied fix isn’t really a fix, is it? The cleaner, proper version can be worked on in a public issue queue once it’s disclosed and once we have a good patch.
It is important that everybody on the security team be first and foremost Drupal experts. So if you are someone who does Drupal security work, or you have worked with the security team on your own contrib modules, and you’re interested in levelling up and learning more, please reach out to the security team and see how you might be able to get involved.
Drupal’s threat model is its own thing. We have very specific trust boundaries and permissions that restrict access, and things that are meant just for our trusted administrators. What we find in reports that come from folks who don’t necessarily know Drupal, or even in fixes that come from folks who don’t know Drupal, is that they might miss those details. It impacts how you tell a real vulnerability from an intended behavior that Drupal already has.
The funded reviewer pool that we have comes from the existing security team, and this is why any of the hosting partners or CDNs who get active in Steward would have to have a security team member. Even as we scale the program, that’s still going to continue to be true. We need to focus on adding capacity without widening the circle, and make sure that we actually have folks who are there.
Who is carrying the loadAlpha-Omega has been providing the SEIR program for years with some of the projects, but this was Drupal’s first term in it. We’re in the first six-month engagement. What was different about the way that Drupal did it is really a reflection of that entire process. You have to fund not just one person to go in and find and fix bugs, you have to fund the whole security workflow. If we just focused on one researcher, everything would be stuck. You need to make sure that throughput is the primary focus. So we have several roles that are partially funded, instead of the usual single person funded full-time. I think our results five months in have shown that it made a big difference.
That SEIR team, which includes Drew Webber, Greg Knaddison, Michael Hess, and Neil Drumm, supported by both Tim Lehnen and myself, participated in about 87% of the advisories, including those two critical core fixes a few weeks ago. They’ve also started to focus on creating reusable tooling and on finding and fixing some upstream bugs that were in fact impacting us downstream. There have been maybe half a dozen hardening changes, and also fixes to issues in Drupal.org’s infrastructure itself. So I’m very grateful to them and their work, and to Alpha-Omega for funding it.
But it would be remiss of me not to note that it didn’t fund all of the work. This is a huge influx and a huge increase in the number of vulnerability disclosures that the team is working on. As we have seen throughout Drupal’s entire history, it’s largely funded and largely done by people who are volunteers. Almost every member of the security team, even those who weren’t funded by SEER, increased their contribution year over year, if I look at June through October of this year versus June through October of last year. It impacted maintainers as well. They needed to write, test, and ship fixes on timelines.
Some members of the team also have time that’s sponsored by their employers. We know that they likely go above and beyond that. I think that’s just always true, and I am deeply grateful for folks’ willingness to do that. Some were funded through the Drupal AI Initiative to do some work, and that allowed it to spill over into their security team subsidies. And then there’s also some Drupal 7 end of life work.
If you are one of the companies who encourage people to do this work, I’m thinking here of Tag1. The security team has told me that without Swan Colada’s participation, the last few months would have been impossible to manage. So I really appreciate their work, and also Tag1 for sponsoring some of it.
But it took more than 100 volunteers to work on all of the security issues that Drupal has had to endure over these last five months. So I thank you deeply. I thank any companies that are sponsoring you, either directly or indirectly, to do this work. I appreciate it.
But it’s really clear that we need to find ways to increase the amount of funding that goes not just to the security team, but also to the core release team. Every vulnerability that we address only matters once it’s been released to the public. We need to make sure that we aren’t just relying on people’s spare time indefinitely, and find a way to improve that.
What I’m looking at are ways that we can move beyond just relying on grants or individual organizations to fund huge chunks of people’s time, and thinking about how we might make it easier for other people to opt in, and how we can make Drupal Steward accessible to more people. At the end of the day, my priority, my mission as part of the DA, is to get as many Drupal sites as secure and as protected as possible. And I want to do that in a way that respects the time and the expertise of the people who build it: maintainers, core release managers, security team members, all of us. I think that’s how we protect the commons as we move forward.
How you can helpFirst and foremost, please make sure that you are covered by Drupal Steward. If you’re a site owner, you can ask your CDN or your host provider, “Are you a Drupal Steward partner?” If they’re not, please encourage them to become one. If you are a shared host, a Drupal platform, or a CDN, get in touch. We’re happy to have some conversations about how you can become a Drupal Steward partner. You pass that protection on to your customers, and then help us increase the capacity of our security team.
Also, if you haven’t yet, and I really hope you have by the time you watch this video, please patch PHP and keep your sites updated. Drupal Steward will buy you time for Drupal vulnerabilities, but it can’t replace anything upstream, and it certainly never replaces updating your sites to secure versions of the modules that we release.
And if your organization depends on Drupal, sponsor people who know Drupal, either in your own organization or in the community, to contribute to security specifically.
I want to end this with huge thanks, as always, to the volunteers who do our core release management, to those on the security team, and to all of the maintainers who’ve been involved in absorbing this AI wave. I unfortunately don’t see it abating anytime soon, but I think we can continue to collaborate and stay in conversation about how we can make it more manageable and more sustainable for all of us.
So with that, I want to thank Alpha-Omega again. I want to thank our colleagues over at the PHP Foundation for all of their work last week, Trail of Bits for helping us find our critical vulnerability, and OpenAI, as well as Anthropic, who have both been providing us with AI tools to manage this work.
Follow the conversationNew episodes of In the Open publish each week. Subscribe on the Drupal Association YouTube channel to follow along.
With thanks to Stephen Cross of Second Signal Media for producing this series.
Drupal 12.0.0 and 11.5.0 are scheduled for the week of December 7, 2026. In preparation for these upcoming releases, our schedule targets release candidates for these versions for less than two weeks from now, the week of November 9.
Before we create our release candidates, we will commit several "beta target" changes that are likely to conflict with existing core merge requests. These include issues to increase Drupal's PHPStan rule level to 3 for improved testing of coding standards and static analysis, and specific large cleanups like adopting constructor property promotion and removing a legacy test annotation format. New PHPStan failures are also likely on existing merge requests.
These beta targets need to be committed in a certain order, and will conflict with each other as well as many other merge requests in the Drupal core issue queue. Commits that introduce merge conflicts with the beta targets may be reverted in order to ensure these large changesets can land smoothly without needing to be repeatedly regenerated.
Once the beta targets are completed, Drupal 12.0 and 11.5 will enter their release candidate phase, and all disruptive changes (aside from critical dependency updates and similar issues) will begin targeting Drupal 12.1.
Today we are talking about AI, Drupal, and what's new with guests Dr. Christoph Breidert & Scott Falconer. We'll also cover Drupal AI Demo as our module of the week.
For show notes visit: https://www.talkingDrupal.com/576
TopicsChristoph Breidert - 1xINTERNET.com breidert Scott Falconer - managing-ai.com scott-falconer
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
This post is being published in consultation with the Drupal Security Team.
As the maintainers of Drupal Commerce, we are advising users to upgrade immediately to the recently published releases of Commerce Core to protect against a vulnerability that may have financial impact.
We received two reports of attempts by malicious users to place fraudulent orders using a vulnerability patched in Commerce Core 3.3.13 and 8.x-2.41 (SA-CONTRIB-2026-254). Centarro and the Drupal Security Team looked for broader abuse of this issue. As of now we do not believe it was scripted or exploited beyond the initial sites.
We analyzed the issue in private with the Drupal Security Team, who coordinated the testing, packaging, and release of the module updates on October 28, 2026.
Attempted exploits have been observed on live sitesThose who reported the issue were merchants who observed suspicious activity on live sites, not merely security researchers evaluating the platform for vulnerabilities. Given that merchants observed this behavior, we highly recommend every user evaluate recent orders to determine whether or not any were fraudulently placed.
This vulnerability impacts both full-stack and headless sites, with attack vectors that differ based on the site’s architecture.
Identifying potential exploitsTo determine if any of your recent orders were fraudulently placed or otherwise manipulated, evaluate them according to the following rubric organized according to exploits of increasing sophistication. Every Drupal Commerce site is unique, so you should evaluate the results of each item based on your knowledge of the legitimate behaviors your site supports.
Read moreFor most organizations, the question is no longer whether AI matters, but how AI fits into their own work, on what terms, and at what cost.
On December 1, 2026, the Drupal AI Summit Paris will bring together experts and organizations that have already worked through those questions, including EU institutions and medical researchers, to share what they learned.
Your summit ticket also gets you all three days of the Future of Software Technologies (FOST) conference, December 1-3, with over 300 sessions to choose from.
Marketing and Content Teams Moving Faster Without Losing Their VoiceFor marketing and content teams, trustworthy content is essential. It has to sound like their brand and get published without weeks of waiting. That’s the promise of Drupal AI.
When pages drift off-brand and don't keep up with the brand, they lose their importance and credibility. They lose what sets them apart.
AI working as the editor, not the author, is the focus of this session. Bruno Bruno from 1xINTERNET will show how AI can review content against an organization’s own standards and suggest fixes, keeping hundreds of pages consistent. All while people still write the content and decide what gets published.
Landing pages are often the centerpiece of a campaign. The summit will also feature Canvas AI, showing how you can build a complete, brand-compliant landing page from a text prompt or by drag and drop, and then route it to the right people for approval. That way, the page goes live on time and in the right voice.
Marketing teams also have to make changes across many pages at once. Fabian Franz from Tag1 will demonstrate how AI can make a change across an entire university site in a separate workspace, so nothing reaches the live site until a person reviews and publishes it.
Preparing for a Changing Search LandscapeThe way people discover information online is changing. Increasingly, potential customers are turning to AI assistants and answer engines to research products, services, and organizations.
For website owners and marketing teams, this raises an important concern: content that performs well in traditional search may not necessarily be discoverable or cited by AI systems.
Two sessions at the summit tackle this question: one focused on what’s changing and the other on how to respond.
Martin Anderson-Clutz from Acquia will look at how AI is changing the role of websites, from how content is discovered to how organizations approach personalization and digital marketing.
Christoph Breidert from 1xINTERNET picks up from there with a practical approach to Answer Engine Optimization (AEO), building on one of last year's most popular discussions about AI search visibility. His session will explore how organizations can with S1xSignals assess their content for citation readiness, query alignment, content structure, authority and trust, semantic clarity, and technical accessibility.
Content structure, metadata, and schema are at the heart of these signals, and Drupal does these well.
Learning From Organizations Already Putting AI to WorkThere is a considerable difference between showing what AI can do and making it work in an organization with established systems, responsibilities, and regulatory requirements.
Tens of thousands of candidates turn to the European Personnel Selection Office (EPSO) for information about careers with the European Union institutions. Working with Dropsolid, EPSO implemented an AI-powered answer engine to help them find what they need in all 24 official EU languages.
It uses EPSO's own documentation rather than general AI information, cites the source behind every answer, and runs on European-sovereign infrastructure with governance and auditability built in. At the summit, Dominique De Cooman, Founder and CEO of Dropsolid AI, will explain how Drupal's structured content and API-first architecture make all of that possible.
Not every use of AI faces the public. At the Clinical Practice Research Datalink (CPRD), it works inside the review process. CPRD provides anonymized clinical data to researchers around the world, and every application to use that data goes through a careful, multi-stage human review. CPRD added an AI reviewer that checks each application against its own rules on data use, while people still make the decisions. At the summit, Vijay Mani from Reading Room will share how they made it work in a highly regulated environment.
On top of EPSO and CPRD, Dan Lemon from amazee.io will present more examples of Drupal AI in production, including content classification, accessible content rewriting, and improved search experiences, all supported by private AI infrastructure. Some of these organizations went from not using AI to making it an integral part of their work cycle.
Moving Forward With AI While Maintaining ControlFor many European organizations, responsible AI and data sovereignty are central to technology choices. Decision-makers need straightforward information to make clear, well-thought-out plans.
Of course, they also have to follow the GDPR, and the fines for getting it wrong can be large. So they need to know where their data is processed, which providers can access it, and who reviews what AI produces. Open source lets them make those choices for themselves, and Drupal AI supports multiple models and providers, including locally hosted options, so each organization can choose what fits best.
Two sessions pick up from there: Jamie Abrahams from FreelyGive will look at how subscriptions, the fear of lock-in, and the push for national AI sovereignty are leading people, companies, and governments toward open source. Wolfgang Ziegler from drunomics will show how people and AI agents can combine efforts while always allowing for approval to rest with people.
Both point to the same idea: adopting AI shouldn't mean giving up control of an organization's data, content, or decisions.
One Summit, Hundreds of Opportunities to LearnThe Drupal AI Summit opens the Future of Software Technologies (FOST) conference, December 1-3, 2026, at CNIT Forest in Paris. More than 5,000 people are expected across the three days.
If you make decisions about AI, run a website, or work in marketing, it’s a chance to see how AI can improve what you already do, and what may shape your next decisions.
Friends of the Drupal Community can get a summit ticket for €149, which covers all of FOST. The regular FOST pass is €499, so it's a remarkable value, especially with everything else that's included.
Last year's event sold out, and we expect the same this time, so if you’re thinking about coming, get your ticket now.
Frequently Asked Questions When and where is the Drupal AI Summit Paris 2026?On 1 December 2026, at CNIT Forest in Paris. It opens the Future of Software Technologies (FOST) conference, which runs 1 to 3 December.
How much does a ticket cost?For Friends of the Drupal Community, a summit ticket is €149, and it covers all of FOST. The regular FOST pass is €499.
What does a summit ticket include?All three days of FOST, with more than 25 conferences and over 300 sessions.
Who should attend?Marketing and content teams, IT and compliance teams, and business leaders who want to see how AI can fit into their own work, on their own terms.