#! code: LocalGov Drupal Camp 2026
LocalGov Drupal Camp 2026 was held on 11th and 12th June in the city of Sheffield in the north of England. I drove over the Pennines from my home in Cheshire to attend the camp for the two days.
LocalGov Drupal, in case you weren't aware, is a Drupal distribution that is set up in a way that makes it easy for councils to publish their content. Since it's built on Drupal the sites can also make use of the many Drupal modules available. There are also lots of additional LocalGov Drupal modules that integrate with waste collection systems, bus timetables, election results, and many more.
Last year, LocalGov Drupal was being used by 57 council websites across the UK. This year, that figure has jumped to 73! A fantastic achievement, with that number only set to get bigger.
The camp itself consisted of a Wednesday night social night, a day of talks and other sessions, followed by a day of workshops and sprints.
Wednesday NightThe social on Wednesday night was held at the National Videogame Museum in Sheffield city centre. On entry we got a couple of free drinks, and there was plenty of pizza to go around (perhaps too much pizza!).
This was amazing venue to have a social! After spending a while catching up and chatting with lots people we went into the museum itself and played some games for a while. 4 player Pacman and Ultimate Chicken Horse were particular favourites from the evening.
philipnorton42 Sun, 06/21/2026 - 18:49Webpro Company blog: Drupal 7 Migration Statistics in 2026: What the Numbers Really Mean
Webpro Company blog: Drupal vs Headless CMS: which approach fits a large organization's digital platform?
Peoples Blog: AI Creates Content, CMS Keeps It Under Control: Why Drupal Still Matters in the AI Era
The Drop Times: Robert Menetray Builds DruScan to Simplify Drupal Audits
Aten Design Group: Search Across Multiple Drupal Sites with Pantheon SOLR
Search feels like a solved problem. Until you're managing a network of Drupal sites and your users expect to find content regardless of which one it lives on, that is. At that point, the question stops being "how do we add search?" and starts being "how do we build a unified search experience across an entire digital ecosystem?"
The obvious workaround is to bring in a third-party Solr provider. That works, but it means another vendor, another bill, and another service to monitor and secure. For organizations already invested in Pantheon's managed infrastructure, it further fragments the operational footprint rather than simplifying it.
At Aten, this challenge comes up regularly with clients running multi-site Drupal architectures on Pantheon. The solution we've landed on keeps everything within the platform, using four contributed modules working together as a hub-and-spoke proxy. This post walks through the architecture, why it exists, and how to implement it.
The Constraint You Can't Route AroundPantheon's managed Solr is excellent: zero server administration, mTLS-secured connections, schema management handled through a purpose-built API. But it comes with a hard platform constraint: each Drupal site environment gets exactly one Solr core, and that core is network-isolated to that environment.
There is no platform mechanism to point a second Drupal site at another site's Solr instance. Each site can only talk to its own.
This is a reasonable security tradeoff for single-site use. But for a multi-site architecture where you need a single search index spanning many sites, it forces you to think architecturally rather than just reach for a configuration option.
The Architecture: One Hub, Many ClientsThe solution is a hub-and-spoke proxy. One Drupal site (the hub) owns the Solr core and exposes it to other sites over authenticated HTTP. Every other site (the clients) routes its search queries through the hub instead of connecting to Solr directly.
From Pantheon's perspective, only the hub ever touches Solr. The constraint is satisfied. From Search API's perspective, every client is talking to a Solr instance in the normal way. The architecture sits between those two layers.
Four contributed modules make this work:
ModuleInstalled onRolesearch_api_pantheonHubConnects to Pantheon Solr via env vars and mTLSpantheon_solr_apiHubExposes Solr to authenticated clients via HTTP proxysearch_api_solr_proxyEach clientAbstract proxy base; no direct configurationsearch_api_solr_proxy_pantheon_connectorEach clientRoutes queries through hub; manages API key via Key moduleWhat Each Module DoesHub: search_api_pantheonThis is the only module in the stack that speaks directly to Pantheon's Solr. It extends Search API Solr's standard connector and replaces the typical admin configuration form with auto-discovered values from Pantheon's environment variables (PANTHEON_INDEX_HOST, PANTHEON_INDEX_PORT, PANTHEON_INDEX_CORE, and others). On Pantheon environments, those fields are disabled in the UI; the platform owns them.
For transport, it swaps in a custom cURL adapter that uses the mTLS certificate Pantheon provisions at ~/certs/binding.pem. Schema uploads and core reloads go through Pantheon's proprietary endpoints rather than the standard Solr APIs.
Hub: pantheon_solr_apiThis module is what actually opens the hub's Solr to the outside world. It exposes a set of Drupal routes at /solr-proxy/{action} that authenticated client sites can POST and GET against, and a standalone PHP file at /pantheon-solr-proxy.php for high-performance SELECT queries (more on that below).
Every request is validated against a shared API key before it reaches Solr. The key is read from a configured Key module entity (backed by a Pantheon Secret) and compared using hash_equals(), a timing-safe comparison that prevents key enumeration attacks. Only a hardcoded allowlist of Solr actions (select, update, update/json, admin/ping, admin/luke, config, and a handful of others) will be forwarded. Anything outside that list returns a 403.
Client registrations are tracked in Drupal config, keyed by the combination of each site's Search API site hash and index ID, the same namespace Search API Solr uses internally to scope documents.
Client: search_api_solr_proxy + search_api_solr_proxy_pantheon_connectorsearch_api_solr_proxy is a framework-only module. It provides the abstract SolrProxyConnectorBase class but is not useful on its own. search_api_solr_proxy_pantheon_connector is the Pantheon-specific implementation.
On each client site, the connector replaces the standard Search API server configuration (host, port, path, core) with a single hub_url field. A Guzzle middleware stack handles two things:
- Auth injection: every outbound request gets an X-Pantheon-Solr-Key header carrying the API key from the Key module entity.
- URL rewriting: SELECT queries are redirected to /pantheon-solr-proxy.php on the hub; everything else routes to /solr-proxy/{action} through Drupal.
Because client sites never manage the Solr schema directly, skip_schema_check is permanently enabled. The connector also auto-detects the Solr version by querying the hub's admin/system endpoint, falling back to 8.11.4 (Pantheon's current managed version) if the endpoint is unreachable.
How a Search Query Actually TravelsHere is the path of a typical user search on a client site:
- Search API builds a Solr SELECT query.
- The connector's Guzzle middleware intercepts it, adds the X-Pantheon-Solr-Key header, and rewrites the URL to https://hub.example.com/pantheon-solr-proxy.php?....
- The request arrives at the hub's web root. pantheon-solr-proxy.php runs as a standalone PHP script with no Drupal bootstrap. It validates the API key, constructs the Solr URL from Pantheon environment variables, and forwards the request using the mTLS certificate.
- Solr responds. The script returns the raw JSON response directly.
- Search API processes the results on the client site.
SELECT queries bypass Drupal's bootstrap entirely. On a warm server, the round trip through the proxy adds approximately 5ms of overhead. Writes, admin actions, and schema operations go through the Drupal controller instead, which adds around 150ms. That's acceptable for infrequent operations.
Getting It Set UpOn the hub sitecomposer require drupal/search_api_pantheon drupal/pantheon_solr_api drush en search_api_pantheon pantheon_solr_apiNavigate to Administration > Configuration > Search and metadata > Pantheon Solr API. Select or create a Key entity pointing to the PANTHEON_SOLR_API_KEY Pantheon Secret. This is the shared key your client sites will use to authenticate.
Copy pantheon-solr-proxy.php (provided by pantheon_solr_api) to your hub site's web root. This is the fast-path script for SELECT queries.
On each client sitecomposer require drupal/search_api drupal/search_api_solr drupal/search_api_solr_proxy drush en search_api search_api_solr search_api_solr_proxy_pantheon_connectorCreate a Search API server using the Pantheon Solr Proxy connector. Set the Hub URL to your hub site's base URL. Configure the Key entity to use the same PANTHEON_SOLR_API_KEY secret.
Create your Search API index on that server as you normally would, with any entity types, fields, and processors you need.
Then run the registration command:
drush pantheon-solr-proxy:registerThis command auto-discovers your Search API server and index, reads the site hash and index ID that Search API Solr uses to namespace your documents, and POSTs that registration to the hub. Back on the hub, run:
drush pantheon-solr-api:update-indexRepeat the client-side steps for each site in your network.
A Few Things Worth KnowingSchema management stays on the hub. Only the hub ever uploads schema files to Pantheon. Client sites have skip_schema_check forced on. If your search requirements across sites are different enough to require separate schemas, this architecture assumes you can reconcile them into a single configset. In practice, the search_api_solr jump-start configset handles most requirements.
Document namespacing is automatic. Search API Solr already scopes every indexed document with a per-site hash and index ID prefix. Each client site's documents live in separate namespaces within the same Solr core. Cross-site queries need to either search all namespaces or be scoped deliberately; your Views or custom query code controls this.
The API key is a Pantheon Secret, not a config value. Keys stored in pantheon_solr_api.settings Drupal config hold a reference to a Key module entity, not the raw key. The actual secret is resolved at runtime from PANTHEON_SOLR_API_KEY. This keeps credentials out of your config exports and codebase.
Building Across Site BoundariesUnified search across a multi-site Drupal architecture is one of those problems that looks straightforward until you try to implement it on a managed platform. Pantheon's security model solves a lot of problems, but it introduces constraints that require a deliberate architectural response.
The hub-and-spoke proxy described here is that response. It works within the platform's model, keeps credentials out of the codebase, and adds minimal latency to the critical read path.
If you're building a multi-site Drupal ecosystem and working through the hard architectural questions around search, shared data, and cross-site workflows, get in touch with the Aten team. This is the kind of problem we solve.
Joel SteidlCentarro: The Difference Between B2B and B2C eCommerce
B2C eCommerce usually gets all the attention, because that’s what most people engage with. They buy stuff from Amazon, Etsy, or a Shopify store without thinking too much about it. The customer comes to the website and makes a purchase. Usually, there is a portal to track the order and some transactional emails for updates, and finally, the package is delivered to their door. If they bought from a company that has its act together, they might spend the next 3-6 months being remarketed to because the company really wants to make this customer a repeat customer.
But this B2C eCommerce experience, while ubiquitous and recognizable to most, is only scratching the surface.
The scale of B2B commerce is actually much larger than its B2C cousin. The global B2B eCommerce market is expected to reach roughly $37 trillion in 2026, approximately six times the size of the global B2C market. Yet despite that enormous footprint, B2B digital commerce remains far less mature than its B2C counterpart. Software that serves the latter doesn’t work for the former. The differences between B2B and B2C commerce run deep, from how deals get made to how orders get shipped to how platforms are architected. Different customers. Different requirements. Different expectations. To add further complications, businesses increasingly need to operate in both worlds simultaneously.
Read moreDrupal AI Initiative: Drupal AI 1.4.0: Unveiling Extensibility, Enterprise Resilience, and Advanced Guardrails
Just two months after the milestone release of Drupal AI 1.3.0, we are thrilled to announce that Drupal AI 1.4.0 is officially here!
With the 1.x branch reaching a high level of maturity and stability, we are excited to transition into a more predictable, bi-monthly minor release cadence. Moving forward, the Drupal community can look forward to a steady, reliable stream of improvements, new integrations, and expanded platform capabilities.
Drupal AI 1.4.0 represents a major evolutionary step, focusing heavily on extensibility, scalability, normalization, and preparing the broader ecosystem for the next generation of AI-powered digital experiences.
Let's dive into what's new in this release.
1. A Highly Extensible AI Ecosystem for DevelopersOne of our primary themes for 1.4.0 is giving contributed module developers the tools they need to extend and enrich Drupal AI. We want to make extending this module as seamless as writing a simple prompt.
Markdown Editor ExtensibilityContrib modules can now extend the markdown editor experience directly. The newly available Document Loader integration, for example, allows content creators to load content from virtually any document type directly into their editor workflow.
This architectural improvement opens the door for the community to build richer editor experiences and provider-specific tooling without requiring any modifications to Drupal AI core.
New "Skills" and Drush Generate CommandsTo radically accelerate development speed and reduce boilerplate code, we are introducing both AI "skills" and drush generate commands that allow developers to rapidly generate:
- AI Providers
- AI Automator Types and Rules
- AI Guardrails
- Field Widget Actions
- Operation Types
- AI API Explorers
- Function Calls
- Function Groups
For teams utilizing coding agents or AI-assisted development workflows, these new skills can automatically generate integrations that strictly follow Drupal AI best practices—saving hours of development time.
2. Chat Normalization Across Processors
Image showcasing Slack Chat Processor together with the Webform Agent.
One of the most significant architectural milestones in 1.4.0 is the introduction of normalization for chat systems - an abstraction layer that decouples chat interfaces from their underlying AI processors, so integrations are no longer tightly bound to specific implementations.
This opens the door to immediate, practical use cases: the newly introduced Slack Chat processor lets team members communicate with Drupal AI agents directly through Slack.
More broadly, it lays the groundwork for the upcoming AI Agents processor release and makes it significantly easier to build, package, and reuse conversational, multi-channel AI experiences across providers and platforms.
3. AI Automators + Views Bulk OperationsHandling content at scale is one of Drupal's core strengths, and in 1.4.0 we are supercharging this capability. AI Automators can now execute any configured rule or AI type directly as a Views Bulk Operation (VBO).
This integration unleashes massive efficiency gains for content editors and site administrators. Instead of running AI operations page-by-page, teams can trigger complex, AI-driven workflows across hundreds or thousands of entities simultaneously.
Site builders can now configure Views to bulk-execute tasks such as:
- Automated Image Alt Text Generation for media libraries.
- Bulk Summarization of newly migrated archival content.
- Large-scale Classification and Tagging for taxonomies.
- Batch Translation of product descriptions or documentation.
- Custom AI-powered Editorial Workflows tailored to your specific business logic.
This is a massive usability win for teams responsible for maintaining and optimizing large, enterprise-scale content repositories.
4. Strengthening Drupal AI for Enterprise ReliabilityEnterprise-grade operations demand high availability. Drupal AI 1.4.0 lays the crucial architectural groundwork for robust failover and redundancy support across your entire AI stack.
The module's architecture is now fully equipped to handle advanced failover processes. In the near future, site builders will be able to use powerful tools like ECA (Events, Conditions, Actions) to configure custom AI routing logic, unlocking enterprise-ready scenarios, such as:
- Automatic Failover: Instantly routing requests to a backup provider if your primary provider experiences an outage.
- Smart Routing: Directing AI queries based on real-time cost or latency metrics.
- Content-Type Routing: Using different LLM providers depending on the complexity of the content type.
- Custom Pipelines: Applying specialized response-handling pipelines to clean or format data on the fly.
This represents a significant step toward securing permanent, enterprise-grade reliability for AI in Drupal.
5. Advanced Guardrails and Real-Time SecurityThe guardrails feature introduced in 1.3.0 has received a massive upgrade in this release, making Drupal AI safer and more production-ready for large-scale, public-facing deployments.
In 1.4.0, guardrails can now:
- Be Configured Globally: Apply safety and policy checks automatically across all outgoing and incoming requests.
- Protect Real-Time Streaming: Enforce guardrails on streaming responses in real time, preventing unsafe content from reaching the user mid-generation.
- Limit Input Length: Enforce strict prompt length limitations.
The input length limit is a vital security layer designed to prevent "denial-of-wallet" attacks, where malicious actors attempt to spike your API costs by sending exceptionally large, resource-intensive prompts to your providers.
Furthermore, our new real-time streaming guardrails represent a unique solution that very few AI frameworks—and virtually no other CMS platforms—can offer out of the box.
Ultimately, Drupal AI 1.4.0 is less about flashy UI features and more about strengthening our platform's foundational architecture for the future.
With normalized chat interfaces, failover-ready systems, hardened security guardrails, deep VBO integrations, and stateful provider capabilities, this release solidifies Drupal AI as a more reliable, more extensible, and more enterprise-ready platform — built for the open web.
Update your modules, explore the new Drush generators, test out the Slack integrations, and let us know what you build!
- Visit the Drupal AI project to download 1.4.0 today.
- Watch a full video highlighting the main features of Drupal AI 1.4.0.
For details on the roadmap or to get involved in the initiative, visit our project page on Drupal.org.
Salsa Digital: One year of the Drupal AI Initiative: open, governed AI at scale
The Drop Times: Jorge Tutor’s CKEditor5 Markdown Module Gives Drupal Editors a Controlled Paste Path
Webpro Company blog: Drupal admin interface as an editorial workbench
Webpro Company blog: Drupal CMS 1 to Drupal CMS 2 upgrade
Webpro Company blog: Drupal CMS 2.0 and Canvas in a client project
DrupalCon News & Updates: Why DrupalCon Rotterdam Is Worth Attending
DrupalCon Rotterdam is one of those events that naturally attracts attention across the Drupal ecosystem. Not only because it brings the community together, but because it creates a space where technology, strategy, contribution and real-world digital projects meet.
For anyone working with Drupal, open source or digital experience platforms, the question is not just “what happens at DrupalCon?”, but it might be: “If you have never been before, why should this be the year to go?”
Image
Photo by Joris Vercammen
Why Rotterdam?
Rotterdam feels like a strong fit for an event like DrupalCon. It is a city known for innovation, architecture, international connections and a forward-looking mindset — qualities that align naturally with the spirit of the Drupal community.
Bringing DrupalCon to Rotterdam creates an opportunity to connect the European Drupal community in a dynamic and accessible setting. It also gives professionals from different markets the chance to meet, exchange perspectives and discuss how Drupal continues to evolve in a fast-changing digital landscape.
Learning from real experience
One of the strongest reasons to attend DrupalCon is the quality of the knowledge shared by the community.
This is not only about product updates or technical presentations, It is about learning from people who are building, maintaining and improving digital platforms in real contexts, often with complex requirements, long-term governance needs and ambitious user experience goals.
From technical sessions to strategic case studies, DrupalCon gives attendees access to practical insight that is difficult to get from documentation alone.
Meeting the community behind Drupal
Drupal has always been more than a content management system; It is an open-source project supported by a global network of contributors, companies and professionals.
For someone who has never attended before, this is one of the most compelling reasons to go: Online discussions, issue queues and documentation are valuable, but meeting people face to face adds a different layer to the experience.
Conversations during sessions, between talks or at community events can lead to new ideas, partnerships and a better understanding of how others approach similar challenges.
Image
Photo by Matthew Saunders
Inspiration beyond the technical track
DrupalCon is also a place to see what organisations are doing with Drupal today.
Real-world examples often show the platform’s value more clearly than feature lists. They reveal how Drupal is being used to support public sector platforms, media websites, higher education, enterprise ecosystems, multilingual content, accessibility requirements and complex editorial workflows.
That is why DrupalCon is relevant beyond development, project managers, designers, UX professionals, marketers, content teams and business leaders can all find useful perspectives on delivery, governance, accessibility, platform strategy and the role of open source in long-term digital transformation.
Why attend for the first time?
Attending DrupalCon for the first time is a way to move from observing the community to being part of it.
It is an opportunity to learn from experienced professionals, understand the direction of the platform, discover practical use cases and build connections that can continue long after the event ends.
DrupalCon Rotterdam represents more than another event in the digital calendar, It is a chance to understand Drupal through the people and projects that keep it moving forward.
For a first-time attendee, that may be the strongest reason to go.
Because sometimes the best way to understand the value of a community is not to read about it from the outside. It is to be in the room where that community comes together.
See you there?
Register now!
- Article by Daniela Moreira
Security advisories: Drupal core - Moderately critical - Improper validation - SA-CORE-2026-009
The JSON:API and REST modules allow you to upload image files to image fields.
The validation rules check the file extension of the uploaded file but not the file MIME type. This may allow a malicious user to upload a file that is not an image.
Certain web-server configurations may serve the uploaded file with its actual MIME type rather than an image type. This may lead to cross-site scripting (XSS) or other unexpected behavior.
Solution:Install the latest version:
Drupal 11
- If you use Drupal 11.3.x, update to Drupal 11.3.12.
- If you use Drupal 11.2.x, update to Drupal 11.2.14.
Drupal 10
- If you use Drupal 10.6.x, update to Drupal 10.6.11.
- If you use Drupal 10.5.x, update to Drupal 10.5.12.
Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.)
Reported By: Fixed By:- Björn Brala (bbrala)
- Kim Pepper (kim.pepper)
- Lee Rowlands (larowlan) of the Drupal Security Team
- Damien McKenna (damienmckenna) of the Drupal Security Team
- Greg Knaddison (greggles) of the Drupal Security Team
- Lee Rowlands (larowlan) of the Drupal Security Team
- Dave Long (longwave) of the Drupal Security Team
- Juraj Nemec (poker10) of the Drupal Security Team
- Jess (xjm) of the Drupal Security Team
Security advisories: Drupal core - Moderately critical - Server-side request forgery - SA-CORE-2026-008
The Media module comes with support for oEmbed. The oEmbed specification contains two discovery mechanisms, via providers.json and via URL discovery.
The URL discovery code could be leveraged to trick Drupal into making server-side requests to any URL.
Solution:Install the latest version:
Drupal 11
- If you use Drupal 11.3.x, update to Drupal 11.3.12.
- If you use Drupal 11.2.x, update to Drupal 11.2.14.
Drupal 10
- If you use Drupal 10.6.x, update to Drupal 10.6.11.
- If you use Drupal 10.5.x, update to Drupal 10.5.12.
Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.)
Required site changes for URL discoveryMost users of the oEmbed functionality in Drupal likely use providers.json to define known providers (such as YouTube and Vimeo) for embedding content.
If you are using URL discovery, you now need to set a list of trusted oEmbed discovery hosts in settings.php.
This is an array containing a series of regular expressions for matching host names for discovery. It follows the same pattern as the existing trusted hosts settings.
Example:
// Only allow URL discovery from example.com. $settings['media_oembed_discovery_trusted_host_patterns'] = [ '^example\.com$', ]; Reported By:- Hamed Kohi (0xhamy)
- assaf alassaf (ama62)
- Albert Skibinski (askibinski)
- Jon Minder (ayalon)
- Lautaro Casanova (betah4k)
- Gabe Sullice (gabesullice)
- John Morahan (john morahan)
- Michael Winser (michaelwinser)
- nbanderson
- offensive-ai
- Francesco Placella (plach)
- quynh ho (qquynh)
- Himanshu Anand (unknownhad)
- Lee Rowlands (larowlan) of the Drupal Security Team
- Dave Long (longwave) of the Drupal Security Team
- Drew Webber (mcdruid) of the Drupal Security Team
- Adam G-H (phenaproxima)
- Sean Blommaert (seanb)
- Benji Fisher (benjifisher) of the Drupal Security Team
- cilefen (cilefen) of the Drupal Security Team
- Damien McKenna (damienmckenna) of the Drupal Security Team
- Mori Sugimoto (dokumori) of the Drupal Security Team
- Greg Knaddison (greggles) of the Drupal Security Team
- Lee Rowlands (larowlan) of the Drupal Security Team
- Dave Long (longwave) of the Drupal Security Team
- Drew Webber (mcdruid) of the Drupal Security Team
- James Gilliland (neclimdul) of the Drupal Security Team
- Juraj Nemec (poker10) of the Drupal Security Team
- Jess (xjm) of the Drupal Security Team
Security advisories: Drupal core - Less critical - Cache poisoning and open redirect - SA-CORE-2026-007
Drupal core ships a rebuild.php front controller that can be used to rebuild Drupal (clearing the caches and rebuilding the container) when the site is in an unexpected condition.
This script doesn't correctly check the Host header against the list of trusted host patterns. This could result in cache poisoning or a redirect to an attacker-controlled domain.
Solution:Install the latest version:
Drupal 11
- If you use Drupal 11.3.x, update to Drupal 11.3.12.
- If you use Drupal 11.2.x, update to Drupal 11.2.14.
Drupal 10
- If you use Drupal 10.6.x, update to Drupal 10.6.11.
- If you use Drupal 10.5.x, update to Drupal 10.5.12.
Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.)
Reported By: Fixed By:- Lee Rowlands (larowlan) of the Drupal Security Team
- catch (catch) of the Drupal Security Team
- cilefen (cilefen) of the Drupal Security Team
- Greg Knaddison (greggles) of the Drupal Security Team
- Lee Rowlands (larowlan) of the Drupal Security Team
- Dave Long (longwave) of the Drupal Security Team
- James Gilliland (neclimdul) of the Drupal Security Team
- Juraj Nemec (poker10) of the Drupal Security Team
- Jess (xjm) of the Drupal Security Team
Security advisories: Drupal core - Moderately critical - Gadget chain - SA-CORE-2026-006
Drupal core contains a chain of methods that could be exploitable when an insecure deserialization vulnerability exists on the site. This so-called "gadget chain" presents no direct threat, but is a vector that can be used to achieve remote code execution or SQL injection if the application deserializes untrusted data due to another vulnerability.
This issue is not directly exploitable.
This issue is mitigated by the fact that in order for it to be exploitable, a separate vulnerability must be present to allow an attacker to pass unsafe input to unserialize().
Solution:Install the latest version:
Drupal 11
- If you use Drupal 11.3.x, update to Drupal 11.3.12.
- If you use Drupal 11.2.x, update to Drupal 11.2.14.
Drupal 10
- If you use Drupal 10.6.x, update to Drupal 10.6.11.
- If you use Drupal 10.5.x, update to Drupal 10.5.12.
Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.)
Reported By: Fixed By:- Lee Rowlands (larowlan) of the Drupal Security Team
- Drew Webber (mcdruid) of the Drupal Security Team
- Mohit Aghera (mohit_aghera)
- Anna Kalata (akalata) of the Drupal Security Team
- Benji Fisher (benjifisher) of the Drupal Security Team
- cilefen (cilefen) of the Drupal Security Team
- Greg Knaddison (greggles) of the Drupal Security Team
- Lee Rowlands (larowlan) of the Drupal Security Team
- Dave Long (longwave) of the Drupal Security Team
- Drew Webber (mcdruid) of the Drupal Security Team
- Juraj Nemec (poker10) of the Drupal Security Team
- Jess (xjm) of the Drupal Security Team
Security advisories: Drupal core - Critical - PHP object injection - SA-CORE-2026-005
SA-CORE-2019-003 added protection for fields that store serialized data to disallow direct writes via web services.
The above fix did not cover all potential attack vectors for JSON:API. An attacker with appropriate JSON:API write permission could potentially inject a malicious payload in certain rare circumstances, potentially resulting in PHP Object Injection.
This vulnerability is mitigated by the fact that in order to be exploitable:
- A site must use an entity reference field type that stores a serialized property.
- An attacker must have permission to write to the entity via JSON:API.
No field type shipped with Drupal core meets these criteria, and contributed or user-created field types that do appear to be extremely unusual. This update protects all such fields; no changes are required in contributed modules.
JSON:API is read-only by default, so sites are only affected if they have enabled write access (either through administrator configuration or the installation of a contributed or custom module that enables write access).
Drupal Steward protection:This issue is being protected by Drupal Steward. In this instance, we believe that the WAF rule will provide mitigation for the common/obvious vulnerability paths, but may not be able to cover all cases or work for all hosting providers. Additionally, several other core security advisories released today are not mitigated by Drupal Steward. Therefore, our recommended action is still to plan an actual Drupal update within 24 hours of this release.
Solution:Install the latest version:
Drupal 11
- If you use Drupal 11.3.x, update to Drupal 11.3.12.
- If you use Drupal 11.2.x, update to Drupal 11.2.14.
Drupal 10
- If you use Drupal 10.6.x, update to Drupal 10.6.11.
- If you use Drupal 10.5.x, update to Drupal 10.5.12.
Drupal 11.1.x, Drupal 11.0.x, Drupal 10.4.x, and below are end-of-life and do not receive security coverage. (Drupal 8 and Drupal 9 have both reached end-of-life.)
Reported By: Fixed By:- Björn Brala (bbrala)
- Sascha Grossenbacher (berdir)
- Lee Rowlands (larowlan) of the Drupal Security Team
- Dave Long (longwave) of the Drupal Security Team
- Drew Webber (mcdruid) of the Drupal Security Team
- Anna Kalata (akalata) of the Drupal Security Team
- Benji Fisher (benjifisher) of the Drupal Security Team
- Damien McKenna (damienmckenna) of the Drupal Security Team
- David Strauss (david strauss) of the Drupal Security Team
- Neil Drumm (drumm) of the Drupal Security Team
- Greg Knaddison (greggles) of the Drupal Security Team
- Tim Hestenes Lehnen (hestenet)
- Lee Rowlands (larowlan) of the Drupal Security Team
- Dave Long (longwave) of the Drupal Security Team
- Drew Webber (mcdruid) of the Drupal Security Team
- Juraj Nemec (poker10) of the Drupal Security Team
- Ra Mänd (ram4nd) provisional member of the Drupal Security Team
- Jess (xjm) of the Drupal Security Team