
19 Jun 2026
Drupal.org aggregator
The Drop Times: Robert Menetray Builds DruScan to Simplify Drupal Audits
Inherited Drupal sites often leave teams with scattered checks, uncertain configuration, and limited visibility beyond the repository. Robert Menetray Caballero built DruScan from freelance audit scripts into a contributed module and optional dashboard that reviews configuration, logs, module updates, code quality, security-related signals, and score history. The tool's privacy boundary is central: detailed reports remain inside the local Drupal environment, while DruScan receives only the data needed for cross-site monitoring, keeping it as an oversight aid rather than a replacement for Drupal judgement.
19 Jun 2026 1:01pm GMT
18 Jun 2026
Drupal.org aggregator
Aten Design Group: Search Across Multiple Drupal Sites with Pantheon SOLR
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 Around
Pantheon'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 Clients
The 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:
| Module | Installed on | Role |
|---|---|---|
search_api_pantheon |
Hub | Connects to Pantheon Solr via env vars and mTLS |
pantheon_solr_api |
Hub | Exposes Solr to authenticated clients via HTTP proxy |
search_api_solr_proxy |
Each client | Abstract proxy base; no direct configuration |
search_api_solr_proxy_pantheon_connector |
Each client | Routes queries through hub; manages API key via Key module |
What Each Module Does
Hub: search_api_pantheon
This 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_api
This 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_connector
search_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-Keyheader carrying the API key from the Key module entity. - URL rewriting: SELECT queries are redirected to
/pantheon-solr-proxy.phpon 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 Travels
Here 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-Keyheader, and rewrites the URL tohttps://hub.example.com/pantheon-solr-proxy.php?.... - The request arrives at the hub's web root.
pantheon-solr-proxy.phpruns 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 Up
On the hub site
composer require drupal/search_api_pantheon drupal/pantheon_solr_api drush en search_api_pantheon pantheon_solr_api
Navigate 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 site
composer 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_connector
Create 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:register
This 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-index
Repeat the client-side steps for each site in your network.
A Few Things Worth Knowing
Schema 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 Boundaries
Unified 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.

18 Jun 2026 7:34pm GMT
Centarro: 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.
18 Jun 2026 2:50pm GMT
Drupal 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 Developers
One 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 Extensibility
Contrib 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 Commands
To 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 Operations
Handling 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 Reliability
Enterprise-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 Security
The 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.
Get Started with 1.4.0 Today!
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.
18 Jun 2026 2:04pm GMT
The Drop Times: Jorge Tutor’s CKEditor5 Markdown Module Gives Drupal Editors a Controlled Paste Path
Markdown has become a practical drafting format for Drupal teams working across notes apps, code editors, documentation systems, and AI-assisted writing tools. Jorge Tutor's CKEditor5 Markdown module addresses the handoff into Drupal by converting pasted Markdown through an explicit editor dialog, then letting CKEditor5 enforce the active text format's HTML rules. In written responses to The DropTimes, Tutor framed the module as a narrow fix for teams that want Markdown during drafting but not as the stored or rendered content format.
18 Jun 2026 6:27am GMT
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?"

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.

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
18 Jun 2026 5:32am GMT
17 Jun 2026
Drupal.org aggregator
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.
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.)
- 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
17 Jun 2026 6:58pm GMT
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.
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 discovery
Most 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$',
];
- 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
17 Jun 2026 6:57pm GMT
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.
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.)
- 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
17 Jun 2026 6:57pm GMT
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().
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.)
- 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
17 Jun 2026 6:57pm GMT
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.
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.)
- 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
17 Jun 2026 6:56pm GMT
The Drop Times: QED42 Opens EventHorizon Waitlist After Releasing Open-Source Drupal CLI
QED42 has opened a waitlist for EventHorizon, a Drupal-focused code-intelligence suite built on the scanning engine behind its open-source EventHorizon CLI. The CLI runs static analysis locally without AI, cloud upload, or telemetry, addressing audit environments where client code is covered by NDAs, data residency clauses, and security review. The broader suite adds visual dependency maps, code health views, and optional AI through user-controlled provider keys.
17 Jun 2026 1:07pm GMT
Morpht: Secure and quality content - Automating moderation tests with Cypress
Cypress is ideal for testing Drupal content moderation, but the learning curve is rather steep. Well, with the cypress-json-tests package, you can be done within a couple of hours.
17 Jun 2026 12:00pm GMT
Morpht: Delivering Convivial for Gov to the Drupal Marketplace
The Drupal marketplace is driving a shift toward high-quality, accessible, and easily maintainable templates tailored for specific industry verticals (like government, healthcare, and education).
17 Jun 2026 9:30am GMT
DrupalCon News & Updates: International Splash Awards 2026: Submission deadline extended to 16 July
Good news for everyone still polishing their entry, we've extended the submission deadline for the International Splash Awards 2026 by four weeks. You now have until 16 July 2026 to submit your project.
As part of our commitment to a fair process, we want to give every Drupal community and agency ample time to put their best work forward. So we're opening the doors wider rather than closing them.
The Splash Awards celebrate the very best Drupal projects from around the world, with winners announced at DrupalCon Rotterdam 2026 (28 September - 1 October). Submitters will be notified of their status in early August.
Learn more & submit your project
Questions? Email drupal@kuonitumlare.com or reach us in #drupalcon_europe on Drupal Slack.

17 Jun 2026 8:52am GMT
Mario Hernandez: Don't let AI have the last word
What an exciting time to be a developer. Over the past year, I've gradually begun adopting a number of AI tools to improve the quality of my work, be more efficient, and even dive into areas of development I had never been strong in.
The days of reading blog posts and tutorials or trying code challenges are over. Or are they?
I subscribe to a handful of technical newsletters which arrive in my inbox every week. I always look forward to learning about the new stuff, improvements to old stuff, or the exciting features or tools coming down the development pipeline. I read each one of them in their entirety and if I am too busy, I keep them in my inbox until I have the time to go through them. Sometimes this means I have two issues to read through because I have not been able to get the previous one. I never delete them until I am done with them.
Why waste my time when I can easily ask AI for help? The learning process is exciting for me, it always has been. In the AI era it might even be more important because what if AI is wrong? How do I know the code snippet I am provided is correct or won't cause regressions in my project? Maybe this is the reason I don't use front-end frameworks like Bootstrap or Tailwind in my projects. I have used them for prototyping, but never to dictate the direction or coding conventions in my project.
Let's take a look at a basic example that may seem trivial but could lead to major issues if not understood. Then we will dive into the real reason I decided to write this post.
HTML/CSS Block-level element vs. Inline-level element
If you know CSS really well you can skip these examples, but if you don't know what block-level and inline-level elements are in the context of HTML/CSS, you may run into issues with your code you'd think is not working when in fact it might be working as intended.
.block {
display: block; /* 1 */
margin: 24px; /* 2 */
padding: 24px; /* 3 */
width: 100px; /* 4 */
}
display:block:
- every side affects the layout.
- all 4 sides push surrounding boxes.
- all 4 sides expand the box.
- width/height are honored.
- breaks content flow by creating a line break (i.e.
<p>,<div>,<h2>)
.inline {
display: inline; /* 1 */
margin: 24px; /* 2 */
padding: 24px; /* 3 */
width: 100px; /* 4 */
}
display:inline:
- only the horizontal axis affects layout.
- left/right push adjacent inline content; top/bottom are IGNORED entirely.
- left/right push adjacent content; top/bottom are PAINTED but reserve NO space - they don't push the lines above/below apart.
- width / height have NO EFFECT.
- does not break content flow (i.e.
<a>,<span>,<img>)
.inline-block {
display: inline-block; /* 1 */
margin: 24px; /* 2 */
padding: 24px; /* 3 */
width: 100px; /* 4 */
}
display:inline-block:
- best of both worlds, inline element with block characteristics.
- all 4 sides reserve space.
- all 4 sides reserve space.
- width / height honored again.
- it does not break content flow (i.e. any element with
display: inline-block;) - because the element is inline, a whitespace of typically ~4px is rendered in your HTML. That's why a row of inline-block boxes set to width: 25% won't fit four-across.
Did you know all those specifics about the display CSS property? What if I didn't understand them and wondered why my layout is broken? What if I want to turn an inline-level element into a block-level element and vice versa? What would that do to my layout or spacing around elements?
The real example that validated my learning thirst
Here is when it became clear to me that you don't need to be an expert, but at the very least understanding your code can provide you with the ability to question AI's decisions and even push back on its recommendations.
The code challenge was relatively simple because I have done this many times, but this time it was at the end of my day and I was exhausted. So I figured I'd make use of AI to help me complete this task.
Build a Card component with SDC in Storybook
I'll focus on only the one piece AI and I had a disagreement on and had to have a heart-to-heart talk about; The card's cta link.
- As any typical card, I needed a title, image, label, and a link/cta field.
- The link needed a label (i.e. "Read the full article"), url, and an icon (svg).
AI built the component for me using Single Directory Component (SDC) conventions along with my custom Storybook's workflow and it worked as expected in Drupal and Storybook, but since this was one of the first components I was building in this new project, I decided that for the link's icon, I wanted to extract the inline SVG from the link.twig template and instead create an <svg>...</svg> asset out of it so I could re-use it in other components.
Originally, AI had opted to use Twig's source() function which is a valid and proper approach for inlining SVGs into components or Twig templates, however, I like to use {% include %} as it provides better cache management especially if I plan to use many icons on my site.
Here's the verbatim conversation about this "simple" change:
Me:
can we extract the icon's svg tag and create a file for it inside src/assets/images/? then twig include it in link.twig? this way we can reuse it in other components
Simple enough, except my project's workflow is unique in that SDC and Storybook share assets (twig, yml, css, js, images), to ensure there is a single source of truth. However, since this was a new project, I had not registered all the required namespaces for Drupal and Storybook to share assets.
AI:
Good call - {% include %} sidesteps source() entirely and avoids the namespace registration work in both Drupal and Storybook.
At this point AI proposed to write a theme hook to register a new Twig namespace Drupal could use to access assets directory.
The proposal of a theme hook to register a new Twig namespace was a NO NO for me because I knew it was not necessary. This takes me back to my original point of being able to understand the code to challenge AI proposed solutions that may not be necessary or an alternative/twig-friendly approach may do just fine.
I immediately questioned the proposal and provided a recommendation.
Me
how about adding a new namespace for drupal that points to src/assets so both storybook and drupal use the same path for assets?
AI
That's the cleanest approach. A single @assets namespace registered in both Storybook and Drupal means the same {% include '@assets/images/icon-arrow.svg' %} line works identically in both environments - no <theme-name>.theme hook needed at all
Needless to say, this was the right call and the final result was summarized by AI as:
AI
- vite.config.js - assets namespace added (Drupal)
- .storybook/main.js - assets namespace added (Storybook)
- components/link/link.twig - inline SVG replaced with
{% include '@assets/images/icon-arrow.svg' %}
For me the main learning lesson of these simple yet real examples is that in the past, "knowing how to code" mostly meant knowing the syntax, semantics and understanding what you were writing. That part is becoming less critical with AI. But the more important skill, "knowing what not to write", hasn't changed. Avoiding poor tradeoffs, recognizing over-engineered or fragile solutions, those still require judgment. That judgment hasn't gone away; it's just being applied later in the process.
In closing
These are interesting times for developers. We don't yet know what this shift means for how we consume knowledge, but I do hope I never lose the desire to read, watch, and try new learning materials, and to still feel excited about them.
Happy learning! 📚
17 Jun 2026 12:00am GMT