22 Oct 2026

feedDrupal.org aggregator

Drupal Association blog: After the PHP security release: auditing your Drupal sites

First things first: if you have not yet updated PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your host's or distribution's patched build), do that right away. See PSA-2026-10-20 from the Drupal Security Team and the PHP project's security advisory. Updating is the only complete fix for CVE-2026-109618 and CVE-2026-109619, and a configuration change or web application firewall rule does not replace it.

It feels like the whole internet has come together to address this PHP vulnerability. It is rare to see that much coordinated effort, and that much care and collaboration.

This post is about what comes after the update. On 21 October, Amazon Threat Intelligence reported that its honeypots recorded an exploitation attempt on 17 October, four days before the vulnerabilities were public, and further attempts in the hours before the fix was released. Amazon does not know whether those early attempts would have worked against real systems. But it means a site that updated promptly on 21 October was still exposed for several days beforehand, and a site that updated later was exposed for longer. Patching closes the door; it does not tell you whether anyone came through it first.

These vulnerabilities are in PHP itself, not in Drupal, so there is no Drupal-specific signature to look for, and no single checklist that fits every site.

Here is how the Drupal Association is handling it for Drupal.org: we updated, and we are now auditing our own infrastructure for signs that anything reached us before the update. In doing that research we have assembled the checks below, the help from an LLM. Not every one of them applies to every site, and which ones should be run depends on the host, but this is what our reading of the advisories and the published threat intelligence leads us to believe site owners should consider, whether they manage their own servers or want to ask their host the right questions. None of these findings is proof of compromise on its own. What you are looking for is several of them clustering around the same time or the same visitor.

Keep the evidence before you look

The audit window starts on 17 October 2026. Before you redeploy or rebuild a server you want to examine, copy its web server, PHP-FPM and system logs somewhere safe. If you run in containers, a redeploy discards everything inside the old container, so capture it first (docker diff or docker commit on the running container) and only then roll the new image.

Where to look

Web server and proxy logs

Start with the simplest check. Amazon published six source addresses in its report:

  • 103.216.220.92 (seen 17 October)
  • 31.223.184.166 (seen 21 October)
  • 37.19.200.5 (seen 21 October)
  • 134.209.159.64 (seen 21 October)
  • 103.114.163.188 (seen 21 October)
  • 95.217.98.37 (seen 21 October)

Search your access logs from 17 October onward for any POST, PUT or PATCH request from those addresses. They belong to shared anonymisation services, so a match is a reason to look harder at that server rather than proof of anything, and no match proves nothing either; a honeypot sees a sample of attackers, not all of them.

Then look at request shape. One of the two bugs is reached through multipart form uploads, so what you are looking for is a run of multipart POST requests from a single visitor to a page that does not normally receive uploads: the front page, a node, a JSON:API route. Browsers do not send multipart bodies on PUT or PATCH, so any of those are worth a look on their own. The other bug is reached by pushing PHP out of memory, which from the outside looks like bursts of large or oddly shaped requests from one client, often paired with a cluster of 500, 502 or 503 responses on a URL that otherwise returns 200. A quick first pass on an Apache or nginx access log is to count POST, PUT and PATCH requests by client address and then read the top few clients' requests in full.

PHP and web server error logs

A failed attempt at a memory-corruption bug tends to leave a trail that a successful one may not, so this is often the richest source. Look for clusters of Allowed memory size of N bytes exhausted, Out of memory, Maximum execution time exceeded, and PHP fatal errors that name no script. In the PHP-FPM log, look for worker crashes: child N exited on signal 11 (SIGSEGV) or signal 6 (SIGABRT); in Apache, exit signal Segmentation fault. A few of these scattered across weeks is normal for a busy Drupal site. Dozens within minutes, or any at all from a single client, is not.



grep -hE 'exited on signal|Segmentation fault|memory size of|Maximum execution time' \ /var/log/php*-fpm.log /var/log/apache2/error.log /var/log/nginx/error.log 2>/dev/null \ | cut -c1-120 | sort | uniq -c | sort -rn | head -20

PHP's own session store

This applies to Drupal sites too, not only to other PHP applications sharing the server, and it surprises people. Drupal stores its sessions in the database, but it registers that handler during bootstrap, and the PHP feature involved in one of these bugs (session upload progress) runs earlier than that, while PHP is still parsing the request body and before a single line of Drupal has executed. At that point PHP knows only its own native session handler, so the write lands in the directory named by session.save_path, typically /var/lib/php/sessions. On a Drupal site that directory should be nearly empty and nearly static, which makes anything in it from the past week worth a look. Look for files created around a suspicious burst, session IDs that are not the usual 26 to 32 alphanumeric characters, and any file containing a PHP open tag or an upload_progress_ key.



ls -lat --time-style=full-iso /var/lib/php/sessions | head -40 grep -l '<?' /var/lib/php/sessions/sess_* 2>/dev/null grep -l 'upload_progress_' /var/lib/php/sessions/sess_* 2>/dev/null

The filesystem

List files created or changed since 17 October in places a deployment does not touch: the public and private files directories, the temporary directory, PHP's upload directory, and anywhere else the web server user can write. A .php, .phtml or .phar file in a files directory, a changed .htaccess there, or a new hidden file is the classic web shell pattern. Timestamps can be faked, so also compare the deployed code against its source of truth: git status on a git-deployed site, or a diff of vendor/ and core/ against a clean composer install from the same composer.lock.



find /var/www -newermt '2026-10-17' -type f \ -not -path '*/vendor/*' -not -path '*/node_modules/*' -not -path '*/.git/*' \ -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' | sort | tail -100 find /var/www -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \) -path '*files*'

Processes, connections and persistence

The web server user (www-data, apache, nginx) should own PHP and web server processes and nothing else. A shell, curl, wget, python, perl, nc or anything running from /tmp or /dev/shm under that user is a finding. So are outbound connections from a web server to addresses that are not your database, cache, mail relay or known APIs. Then check the places a compromise of the web user can reach to survive a reboot: crontab -u www-data -l, new entries under /etc/cron.d, new systemd units or timers, changed ~/.ssh/authorized_keys files, and new local accounts.

Drupal itself

Finally, the application layer. Look for user accounts created or changed since 17 October, and for anyone newly holding the administrator role. Run drush config:status against your exported configuration and look for drift, especially newly enabled modules. Check drush watchdog:show --severity=Error for the same fatal errors and memory exhaustion you looked for in the PHP log. Diff settings.php, settings.local.php and services.yml against your deployment source; they hold the database credentials and hash salt an attacker would want.

If you find something

Take the server off the internet, but leave it running if you can; a powered-off machine loses the evidence in memory. Preserve the logs and, if possible, a disk image. Rotate every secret the web server user could have read: database credentials, the Drupal hash salt, API keys, SMTP credentials, and any private keys on the host. Treat other servers that share those secrets or a session store as suspect too. Rebuild from a known-good image or checkout onto patched PHP rather than trying to clean the compromised host in place; it is faster and you will trust the result.

Because these are PHP vulnerabilities rather than Drupal ones, a compromise through them is not a Drupal security issue to report to the Drupal Security Team. It belongs with your own incident process, your host, and, where you have obligations to them, your customers and users.

Hardening worth keeping

Two of the interim settings the PHP project recommended are worth leaving in place after the update. session.upload_progress.enabled = 0 turns off a feature Drupal does not use; the PHP advisory suggests keeping it off if you do not need it. session.use_strict_mode = 1 is long-standing hardening that stops PHP accepting session identifiers it did not issue. Set both in your php.ini or PHP-FPM pool configuration rather than with ini_set(), and restart PHP afterwards. If you temporarily removed PHP's memory limit or set pm.max_requests = 1 during the exposure window, put those back to normal now; they were stopgaps with real costs.

Next steps

Update PHP if you have not. Then spend an hour with the logs, starting from 17 October, before you let the new deployment overwrite them. If your site is hosted for you, ask your host whether they have done the same, and whether their session.upload_progress setting is off. If you have questions or findings that would help other site owners, the #security-discussion channel on Drupal Slack is the place to raise them; please do not post exploit details or anything that identifies a specific compromised site.

Our thanks to the PHP security team for the coordinated release, and to the hosting partners and community members who shared their own validation results with us this week.

22 Oct 2026 9:54pm GMT

Talking Drupal: Talking Drupal #575 - The Drupal Advocacy Program

Today we are talking about Drupal Advocacy, Non-Code Contribution, and the future with guest Tiffany Farriss. We'll also cover Better Social Sharing Buttons as our module of the week.

For show notes visit: https://www.talkingDrupal.com/575

Topics

Resources

Guests

Tiffany Farriss - association.drupal.org farriss

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Tim Sharp - tea-sharp

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

22 Oct 2026 6:00pm GMT

Drupal AI Initiative: Vibe Coding Drupal: The Pragmatic Middle Path

Author: Martin Anderson-Clutz (mandclu)
Republished with permission from Acquia

Vibe coding or AI rejection? Learn the pragmatic middle path for Drupal teams: what to delegate to AI, when, and how to verify it.

At the Dev AI Summit at DrupalCon Rotterdam, I opened my session with a show of hands. Who has used AI to assist their Drupal development? Nearly every hand in the room went up. Who has used it for other parts of their job? Most hands stayed up. Then I asked who had fully delegated code creation to AI, and the room got a lot quieter.

That gap between "I use AI" and "I trust AI to do the work" is where most Drupal teams live today. It is also where the most important decisions about AI-assisted development get made, often without anyone making them on purpose.

In Part 3 of this series, I introduced the idea of the Code Director: a developer who provides direction to an AI agent, or even a swarm of agents, to make sure the right thing takes shape in the right way. In Part 5, I described the Code Director as the essential human layer for security, compliance, and maintainability, and argued that AI is most valuable as a reasoning partner. This post builds on both. It makes the case that Code Direction is not a compromise between embracing AI and rejecting it. It is the pragmatic middle path, and it comes with a practical discipline: knowing what, when, and how to delegate.

Three ways to respond to AI

Most of the debate about AI in software development is framed as a binary: you either embrace it or you resist it. In practice, I see more of a sprectrum of adoption among the developers I talk to. There are three specific adoption patterns I'd like to call out, however.

Code Direction as the pragmatic middle path

A diagram that shows the spectrum of AI adoption, from outright rejection to adopting the output without critical examination of the code. A Code Direction sits between these two extremes.

AI Rejection: "I will do it myself." Some developers keep AI out of their workflow entirely. Their concerns are often well founded: hallucinated APIs, insecure code, licensing questions, and a reasonable suspicion of hype. But rejection has a cost of its own. The developer who refuses to delegate anything will increasingly be outpaced by peers who delegate well, and will miss out on AI as a research and reasoning partner.

Vibe Coding: "I will offload it." At the other end, some developers hand over the whole task. They describe what they want, accept what comes back, and move on when it appears to work. For a weekend prototype, that can be fine. For a production Drupal site that handles customer data, it is a liability that grows with every commit.

Code Direction: "I will delegate it." In the middle sits the Code Director. The Code Director uses AI aggressively, but deliberately. They choose which tasks to hand off, define those tasks precisely, watch the work as it happens, and remain accountable for every line that ships.

The difference between offloading and delegating is the heart of this post. When you offload a task, you stop thinking about it. When you delegate a task, you stay responsible for the outcome, which means you need to understand it, verify it, and be able to fix it.

Why the extremes fail: the debts you cannot see

Every Drupal developer understands technical debt. Margaret-Anne Storey, a professor of computer science at the University of Victoria and co-author of the SPACE framework, argues that AI forces us to track two more. Her Triple Debt Model, published in ACM Queue, separates what lives in the code from what lives in our heads and in our specifications.

Debt type Where it lives What it is What AI does to it
Technical debt The code Poorly written code, weak modularity, and rigid dependencies AI can reduce it by automating refactoring and writing tests
Cognitive debt The team's minds The erosion of shared understanding: a gap between what the code does and what people comprehend AI accelerates it by writing code faster than humans can learn it
Intent debt The specifications The loss of the why: missing goals, constraints, and recorded decisions AI makes it worse by confidently inventing intent when humans do not write it down

This is why vibe coding is so seductive and so dangerous. It can make your technical debt look better while your cognitive and intent debt quietly pile up. The symptoms show up later: a "safe" change that breaks something unexpected, onboarding that takes far too long, or an agent that builds an elegant architecture for a goal nobody actually had.

The research on individual developers points in the same direction. In a randomized controlled trial published by Anthropic, developers who learned a new Python library with AI assistance scored 50% on a follow-up comprehension quiz, compared to 67% for those who coded by hand. The biggest gap was in debugging. Researchers at Wharton have a name for the underlying behavior: cognitive surrender. In their experiments, roughly 80% of participants accepted AI advice even when it was wrong.

In my talk, I described four skills that are most at risk when developers lean on AI without a plan:

  • Algorithmic decomposition: Breaking vague business requirements into clean, modular logic without first prompting an AI for a blueprint.

  • Mental code execution: Dry-running code in your head to spot race conditions, off-by-one errors, or memory leaks.

  • Syntax and API fluency: Knowing Drupal's APIs and PHP's idioms well enough to work without leaning on autocomplete.

  • First-principles debugging: Isolating root causes with a debugger, logs, and a methodical approach, instead of pasting raw errors into a chat window and hoping for a fix.

Rejection does not solve these problems either. A developer who avoids AI keeps their skills, but often has less time to apply them where they matter most. The answer is not to choose a side. It is to manage the trade-off on purpose.

What a Code Director actually does

In Part 3, I compared the Code Director to an Art Director, who guides designers toward a vision rather than producing every asset personally. That analogy still holds, but Rotterdam pushed me to be more specific about the job. A Code Director:

  1. Makes sure the right context is available, and ensures that each task is well defined and tightly scoped.

  2. Provides relevant examples wherever they exist, such as an existing service, a similar plugin, or a pattern from core.

  3. Watches what the agent is doing, and is ready to stop and redirect it.

  4. Tests the result thoroughly, and asks for tweaks or makes simple ones directly.

  5. Understands the code, and asks for an explanation where necessary.

  6. Validates that the code meets every standard: Drupal coding standards, static analysis, and automated tests.

Notice that none of these steps is "write a clever prompt." As I wrote in Part 5, if your only contribution is the prompt, your value will fade quickly as models improve. The Code Director's value lies in judgment: what to ask for, how to tell whether it is right, and when to step in.

Delegation is a management skill, with a twist

If the Code Director's job is to delegate, then decades of management advice about delegation should apply. Some of it does. Some of it is turned on its head. And some of it is entirely new.

What still holds

  • Define explicit outcomes and acceptance criteria. With human teams, vague goals lead to confusion. With AI, vague prompts lead to hallucinated solutions. Specify constraints, output formats, and edge cases up front: the PHP version, the Drupal core version you are targeting, and which APIs or libraries are off limits.

  • Match the task to capability. Good managers do not hand complex strategy to an intern. LLMs excel at scaffolding boilerplate, converting layouts, generating unit tests, and writing regular expressions. They struggle with novel architecture, complex state, and business logic that cuts across the system. Where you use AI matters too: a conversational app and an agent inside your IDE are suited to different work. And of course, choosing the right model and "effort" (medium, high, etc) will ensure you get reliable output without burning tokens unnecessarily.

  • Provide full context and material. A developer cannot build a feature without user stories and API documentation. For AI, that means managing the context window: relevant schemas, existing codebase patterns, rulesets and style guides, and active dependencies. Exposing context in a granular way reduces the risk of filling the buffer and triggering hallucinations. Also be intentional about what skills you want to be available. There are a number available that can dramatically improve your results, but too many eat up you context window, or even cause hallucinations, if you're using skills with contradictory instructions.

  • Establish strict review and verification loops. "Trust, but verify" applies directly. Pair every delegation with immediate verification: linters, test suites, type checks, and a manual review before you commit. Write those expectations into an AGENTS.md file so every agent session starts with them.

What is inverted

  • Autonomy. With people, you say what to do and leave the how to them, because it fosters ownership. With AI, too much implementation freedom produces architectural drift, dead code, and unvetted third-party dependencies. Effective AI delegation means micromanaging the how: "Use the existing service. Do not add a new HTTP library. Use Drupal's built-in HTTP client."

  • Ownership and accountability. With people, you hand over ownership of the outcome. AI has no accountability at all. You retain 100% ownership of every line you ship, and "the AI generated it" is not an acceptable explanation for a production bug or a security breach.

  • Trust and psychological safety. With people, trust is built over time so they feel safe taking risks. AI has no ego or fear of failure, and "trusting" a model leads straight to confirmation bias and rubber-stamping. Replace trust with automated test gates.

  • Delegating for growth. With people, you assign stretch tasks so juniors can grow. You do not delegate to train the AI. You delegate to save time. If you delegate work in domains you do not understand, you risk your own skills, accept code you cannot debug, and add to your cognitive debt.

What is new

  • The verifiability rule. Only delegate implementation tasks that can be verified quickly, through automated tests, static typing, or visual rendering. If a task takes longer to verify than to write from scratch, write it yourself.

  • Test-first delegation. Write a failing test or a typed interface first, then ask the AI to make it pass. The test becomes your acceptance criteria, in a form the agent cannot misread.

  • From workhorse to toolsmith. Instead of asking AI to perform a repetitive task again and again, ask it to build a script or CLI utility that does the job deterministically. This is the approach I described in Part 3 with the ddev-module-developer add-on: AI helped create the tool, and the tool now runs the same checks the same way every time.

Deciding what to delegate

The simplest test I know fits on one line:

Delegate when the time to complete a task manually is much greater than the time to verify the AI's version.

Time to verify is not just a quick glance. It includes testing the result, reviewing it line by line, and remediating whatever is wrong. When verification is cheap, delegation is a clear win. When it is expensive, the speed of generation is an illusion.

Good candidates for delegation

  • Boilerplate and scaffolding: Module skeletons, routing and controller stubs, build scripts, and configuration files.

  • Test stubs and synthetic data: Verbose test assertions, edge-case arrays, and realistic mock payloads.

  • Syntax translation: Converting familiar logic between languages, or transforming legacy data formats, for example during a migration.

  • Documentation and summaries: Docblocks, API documentation, and a quick high-level summary of a large, unfamiliar repository.

Keep these in your own hands

  • Core business logic: Writing the fundamental domain rules yourself keeps your understanding of how the software works deep and intuitive.

  • System architecture and trade-offs: Content models, entity relationships, caching strategy, and non-functional requirements like security and performance require human judgment.

  • Root-cause debugging: Stepping through stack traces, setting breakpoints, and profiling problems yourself. Offloading debugging entirely degrades your mental model of how the system behaves at runtime.

  • Learning new paradigms: When you pick up a new language, framework, or pattern, write it by hand for the first few weeks to build real understanding before you delegate the syntax.

The four filters

For everything in between, I use four filters. A task that clears all four is a strong candidate for delegation. A task that fails any one of them deserves a closer look before you hand it off.

Filter The question to ask Delegate when Write it yourself when
Verifiability Can the correctness of the result be confirmed quickly and objectively? Pass or fail outcomes governed by types, unit tests, linters, or schema validators Correctness is open-ended: subtle concurrency, algorithm design, or API ergonomics
Stakes How large is the blast radius if a subtle defect slips through? Non-critical tooling, prototype spikes, isolated build scripts, and test mocks Authentication flows, security perimeters, data privacy controls, and financial transactions
Complexity Is the problem self-contained, or does it cross system boundaries? Modular, isolated transformations with bounded context and explicit inputs and outputs Broad system interactions, global state changes, or distributed consistency
Familiarity Do you already have a deep mental model of this problem space? Familiar frameworks and established patterns, where you can spot anti-patterns instantly Unfamiliar paradigms or domain rules, where you lack the judgment to supervise

The familiarity filter is the one most often skipped, and it is the one that protects you from cognitive debt. If you could not review the output with confidence, you are not delegating. You are abdicating, and in danger of becoming a meat proxy.

What this looks like in practice

Here is the approach I use for most non-trivial Drupal work, including the projects I described in Part 5:

  1. Research (optional). For a new problem space, I start with a deep research report on existing solutions and possible approaches. In the Drupal world, the answer could easily be one or more contributed modules that already exist.

  2. Discuss the problem. I keep this stage conversational, typically in Claude Cowork or Google Gemini. I ask the AI to poke holes in my ideas and to anticipate problems before any code exists.

  3. Write a detailed plan. I capture a step-by-step implementation plan in a document such as PROJECT-PLAN.md, broken into phases if the work is substantial. This is where intent debt gets paid down before it accrues.

  4. Implement, and watch. I start the implementation and keep an eye on the approach. If the agent heads in the wrong direction, I interrupt, give feedback, and iterate.

  5. Capture what was learned. I generate an AGENTS.md file so that the standards, conventions, and decisions from this project carry forward into every future session.

  6. Work methodically. Particarly when the work is substantial enough to have phases, I work on them one at a time. Before I move on, I test the work, review the code, ask for changes (or explanations, when needed), and run tests and static analysis myself. When I'm comfortable the changes are up to standard, I put them into a commit, even if I only keep it locally. Then I make sure the phase has been marked as done in the plan (the agent often confidently does this itself), and start the next phase of work in a new conversation.

For team leaders

If you lead a Drupal team or agency, the same principles scale up:

  • Make intent explicit. Plans, decision records, and AGENTS.md files are not paperwork. They are how you keep AI from inventing intent on your team's behalf.

  • Gate on automation, not trust. Coding standards checks, static analysis, and automated tests in CI turn "trust, but verify" into a process that does not depend on anyone's attention span.

  • Protect skill development. Give junior developers room to learn new areas by hand before they delegate them. The time saved today is not worth a team that cannot debug its own code tomorrow.

  • Keep ownership human. Make it clear that whoever opens the merge request owns the code, regardless of who, or what, typed it.

Step into the role

The pragmatic middle is not a fence to sit on. It asks more of you than either extreme. To work as a Code Director:

  • Be mindful of what and when you delegate. Keep your critical skills fresh, train up on new domains by hand, and use AI only where it saves real time and effort.

  • Monitor and redirect. Watch the work as it happens, and keep a critical eye on everything that is generated.

  • Own what you ship. Maintain responsibility for, and understanding of, every line of code you deliver. Do not become a "meat proxy" who simply passes AI output from the chat window to the repository.

  • Treat AI as a thinking partner. Its greatest value is helping you reason through a problem, not replacing the reasoning.

Drupal is well positioned for this moment. A mature API, strict coding standards, a culture of automated testing, and a community that cares about doing things the right way give Code Directors exactly the guardrails they need. AI and Drupal can be very good friends. It's up to us to direct the relationship.

File attachments:
code-director-spectrum.png

22 Oct 2026 4:01pm GMT

The Drop Times: Drupal 12 Upgrade Guide: Release Date, Requirements and Removed Modules

Drupal 12.0.0 is scheduled for the week of 7 December 2026, the same week Drupal 10 reaches end of life, and requires PHP 8.5 and at least Drupal 11.3.

22 Oct 2026 3:34pm GMT

Gábor Hojtsy: Who would have thought the Drupal plural translation experience can be this much better?

Who would have thought the Drupal plural translation experience can be this much better?

Did you know that Drupal only learns how many plural variants a language has from imported .po files? It has a very fast lookup table to pick the right variant each time, but there is no UI to set or fix the rules. Get them wrong and your carefully translated strings fall back to the wrong form. Export your translations and the right plural rules don't come along either. I had a small module that provided a little bit of the solution since 2010 but recently decided to think bigger.

Gábor Hojtsy

22 Oct 2026 1:20pm GMT

Gspikes: Nonprofit Website Design: Lessons From 84 Nonprofit Drupal Projects

What 84 nonprofit Drupal projects prioritised, the eight homepage elements that turn visitors into supporters, how to design the donation path, and which platform fits your nonprofit.

22 Oct 2026 7:00am GMT

The Drop Times: DrupalCamp Italy 2026 Speakers Preview AI Migrations, Civic Platforms and Enterprise Security

Behind some of Drupal's most demanding projects are difficult decisions about scale, security and legacy systems. Six speakers reveal what they have learnt, what surprised them and what they will bring to the stage in Bologna.

22 Oct 2026 6:28am GMT

PreviousNext: How we secured our clients’ Drupal sites with critical PHP security updates

On Tuesday 20 October (Wednesday morning in Australia), the PHP Foundation announced the pending release of fixes for two critical security vulnerabilities in PHP, the language Drupal is written in.

The release was scheduled for 14:00 UTC, which would be 1am for us. This post details how our team prepared and handled the rollout of this release to our clients' sites.

Lurking in plain sight

The PHP security release was for bugs that had sat unnoticed for more than a decade before security researchers found them with the help of AI. The exploit needed multiple steps to reproduce, which previously made it very difficult to detect. AI makes that much easier.

This reflects a bigger shift in cybersecurity. AI is now being pointed at decades of existing code and turning up serious flaws faster than open source security teams have had to deal with before. While the headlines have been about PHP this week, other open source projects are experiencing a similar increase in security reports.

PHP's maintainers were following established security practices and had planned a coordinated release with the researchers who found the flaws. They were forced to bring the release date forward by a day when it was undermined by someone leaking details during the embargo period. The PHP Foundation has been candid about how it unfolded, and it's a reminder that how quickly you respond now matters as much as the code you run.

The day before the update

Our team learned of the PHP critical security release about 17 hours before the planned release. We immediately formed a war room to plan our approach and start communicating with our clients.

That made this the highest priority for PreviousNext. Every site we build runs on PHP, as does every site on Skpr, our managed Drupal hosting platform. We worked together to come up with a planned approach to the deployment including:

  • Identifying if we could block exploits using web application firewall (WAF) rules

  • Planning how to update PHP in application containers without rebuilding them from scratch

  • Planning for what would happen if build and deployment services like GitHub Actions or CircleCI weren't available due to increased load

  • Preparing to block all traffic to the origin (PHP servers) at the content delivery network (CDN) layer while the updates were being built and deployed - following advice from CERT-EU and cyber.gov.au.

We drafted tailored communications to our clients and then our delivery team worked to get each client's approval in advance to deploy the update overnight, and permission to block traffic while the updates were being built and deployed. Clients hosted on their own providers received a message specific to their setup, and what we'd need to coordinate with their host. Every client also had access to immediate updates via our ticketing system as the situation developed.

We weren't working in isolation. Members of our team sit on the global Drupal Security Team, the group that coordinates security for the entire Drupal project, which gave us a direct line into how the best Drupal teams in the world were handling the same problem. We were also in conversation with team members at GovCMS sharing updates as we saw them.

As a Top Tier Drupal Certified Partner, and with Skpr a hosting partner in Drupal Steward, the Drupal project's security program for hosting platforms, we were in close contact with the Drupal Association throughout the incident. With plenty of patchy information doing the rounds on social media, having a direct line to accurate information was vital.

While our delivery managers were communicating with clients, our Platform team was preparing for the release. Our Platform Lead, Nick Schuch, built a tool to scan every container on every hosting cluster and report the PHP version. He also built a tool to apply the PHP update without needing a complete rebuild of the container.

At the same time, our Platform Engineer, Nathan ter Bogt, confirmed that protections baked into Skpr, such as read-only file systems, designed to prevent writing to running containers and execution of PHP by malicious actors. Nathan also prepared the firewall rules and holding page we'd use if we had to block traffic.

At release time

The PHP release was made 20 minutes earlier than scheduled, at 12:40am, likely because there were reports of exploits already being used. Our team was already online and it was all hands on deck, with the team working through the plan we'd mapped out the previous afternoon.

Several things happened at once: Nick started building new PHP packages from the official release while Nathan checked whether firewall rules or a PHP configuration change could block the attack. The two PHP advisories (CVE-2026-109618, CVE-2026-109619) made it clear that patching was the only effective mitigation, so we decided to block all traffic and display planned maintenance pages. Our delivery team stayed in contact with our clients' internal teams to let them know we were taking this step.

Once the new packages were built, Nick used our custom tooling to rebuild the application images for each client site and deployed them. Then we started manually checking each site to make sure it was working as intended.

In practice the process was more complex than we'd anticipated. With thousands of developers deploying fixes at the same time, GitHub slowed right down, which was one of the scenarios we'd planned for.

Real incidents rarely run to the minute, and the team saw it through to the end. By 3:54am the process was complete and every site was secure.

Wrapping up

For our clients, the most important part of Wednesday wasn't the technical work. It was knowing what was happening at every step, from the moment the vulnerabilities were announced to the confirmation that their site was patched. Nobody woke up on Thursday to find their site had gone dark without warning, and nobody had to chase us for an update. That only works when the communication plan is treated as seriously as the technical one.

Preparation and tooling are what make a 1am response calm rather than chaotic. A team that already knows exactly what's running on every server, and has the tools to patch all of it at once, can spend the night making good decisions instead of scrambling. That comes from a senior team with decades of combined Drupal experience, and from running our own hosting platform where we control every layer of the stack. A smaller organisation relying on shared hosting, or an agency without its own platform, faced a much harder night.

While this was a genuinely critical threat, it doesn't change our view that PHP and Drupal are a secure and stable choice. No technology is immune to what happened this week, and the next headline could just as easily be about Java, Python or JavaScript. What protects an organisation is the team behind its platform and how quickly they can act. With AI now writing code and helping attackers find holes in it, having experts on call 24/7 is fast becoming a basic requirement for anyone running a critical website.

We unfortunately expect more nights to come like Wednesday, but our team will be equally ready for them. If you're responsible for a critical website, it's worth asking your current provider a few questions. When did they first contact you about this vulnerability? What was their plan if attackers moved before the fix? And what time was your site patched? If their answers are anything less than confident, feel free to have a chat with us.

22 Oct 2026 5:06am GMT

Dynamosys Insights: PHP2Shell: Updating Drupal Won’t Fix These Critical PHP Flaws

A PHP hosting server stands beside a shield with a checkmark and the Drupal logo, alongside the words “Patch PHP. Protect Drupal.”

Drupal has issued a security alert following the discovery of two critical PHP vulnerabilities. Patches are now available, and site owners should confirm that their hosting environment has received both fixes, even if Drupal itself is fully updated.

22 Oct 2026 4:44am GMT

21 Oct 2026

feedDrupal.org aggregator

Drupal Association blog: Contribution credit updates: higher weights for core and core security work

We've changed how contribution credit is weighted on Drupal.org, and the changes are now live. If you watch the Drupal Marketplace you may have noticed some organizations shift position as a result; this post explains what changed and why, and what's still coming.

Two weights went up. Everything else stayed the same.

  • Core issues are now worth a baseline of 15 credits each (previously 10). We're delighted at how strongly organizations have rallied behind strategic initiatives like Drupal CMS, Drupal Canvas, and Drupal AI. That's exactly what the credit system is meant to encourage. Those initiatives all stand on Drupal core, though, and we want to make sure the core team gets the fundamental care and feeding it deserves alongside them.
  • Core security advisories now carry a 10x multiplier on top of that baseline, so a single core security issue is worth 150 credits (previously 50). The Security Team and core release managers are handling a growing volume of AI-generated reports, and we want organizations to have a strong reason to support, or join, that work.
  • Unchanged: the minimum credit value is 1; credit scales with project usage (a project used on 300,000 sites earns 3 credits per issue); strategic initiative issues are worth 10 credits; and contrib security advisories remain at 5x the project's normal weight.

We've also expanded the core sponsorship table, which gives sponsors a guaranteed monthly base credit for supporting key roles whose most important work doesn't always happen in an issue. It now covers active Security Team Members, Subsystem Maintainers, and Topic Maintainers in addition to the core leadership roles already listed.

Next, we'll publish a companion table naming core contributors who are currently seeking sponsorship, so an organization that wants to fund core work can see exactly who to talk to. We'll post again when it's ready.

A note for Drupal Certified Partners: We check quarterly for partners who have qualified for the next tier and will upgrade you then, or upon request if you've seen yourself reach the next level in between our updates. We also don't downgrade partners until the end of their current term, so there's always time to shore up credit if needed. If you have questions about how these changes affect your organization's standing, get in touch with the Drupal Association.

21 Oct 2026 9:36pm GMT

Omega8.cc: The Ninety-Minute Recall

On Tuesday PHP's security team gave notice of two critical bugs, both scored 9.2, with the fixes due on Wednesday at 14:00 UTC. By Wednesday morning every BOA server, PHP 5.6 to 8.6, had switched off one setting which neither Drupal nor Backdrop uses, session upload progress, and a new PHP security floor was waiting, empty. PHP published at 13:34 UTC, and ninety-odd minutes later 8.2.35, 8.3.36, 8.4.27 and 8.5.12 and the floor were on all three BOA trees, so every box below the floor starts its own system pass within half an hour of seeing it, automatic updates switched off or not. By the evening the fixed 8.6 candidate and PHP's own backports for 7.4, 8.0 and 8.1 had gone the same road, leaving 5.6 and 7.0 to 7.3 on BOA's settings, with no patch. BOA's defaults, PHP-FPM alone behind Nginx with no per-request PHP settings, had shut most of the described routes before anyone outside PHP's security team knew of the bugs, though not the out-of-memory bug, which only the fix closes.

21 Oct 2026 7:04pm GMT

Darren Oh: Bring hands-on demos to your content with Drupal Forge

Bring hands-on demos to your content with Drupal Forge

Drupal CMS launcher illustration with a Drupal logo, a “Math question (2 + 0 =)” prompt, an “Express Launch” button, and “Powered by DevPanel.”

Marketing and training often ask people to imagine what a product or process can do. A screenshot, video, or live presentation helps. But there is a real difference between seeing a demonstration and trying it yourself. A hands-on demo makes marketing more effective: instead of only describing a product, you invite someone to try it. And it makes training more practical: a learner can move from reading instructions to exploring a practice environment.

Darren Oh

Tags

21 Oct 2026 7:03pm GMT

Centarro: A Shared Cart Across Brands Is Only Half a Feature

When a company sells under several brands, someone eventually asks the obvious question: why can't customers put products from every brand into one cart and check out once?

It sounds like a small improvement to the shopping experience, but it isn't a small feature. A shared cart between brands, on Drupal Commerce at least, is relatively easy, assuming each brand runs from the same Drupal installation.

But that's only half of the story. What happens after the order is placed? The hard part of a shared cart experience is everything after checkout, especially fulfillment.

How the cart works by default

In a multi-brand Drupal Commerce setup, each brand gets its own store entity. A store holds a brand's commerce settings:

Once something like Commerce Store Domain is installed and configured, a shopper's cart belongs to the store of the brand they're browsing.

Read more

21 Oct 2026 6:31pm GMT

Gspikes: HIPAA-Compliant Website on Drupal: What It Actually Takes

What makes a healthcare website HIPAA compliant on Drupal: the three places patient data gets in, the BAA question, the tracking-pixel rules after AHA v. Becerra, the module stack, and what 46 healthcare Drupal projects actually prioritise.

21 Oct 2026 3:05pm GMT

Nuvole: PHP-first AI agents for Drupal, built on Neuron AI

We're introducing AI Neuron, a module that bridges Drupal with Neuron AI, a PHP framework for building agents, tools and multi-step workflows.

When you're building AI features in Drupal, the AI module is the obvious place to start. It gives the whole site one place to configure providers and keys, and a default model for each kind of call.

Building an agentic solution means sequencing those calls into something that plans, decides what to do with a tool's result, and calls another tool in response. The Drupal ecosystem already offers modules for that: AI Agents, ECA, the Tool API. Each gets you part of the way, but what's left for the developer is gluing them together into one coherent solution. And that's the hard part: each piece lives in its own module, configured on its own screen, in its own way, which makes iterating on the result, adjusting it, and evaluating it, slow.

What we wanted was one place to drive that development end to end, from a developer's point of view: write the agent in PHP, iterate on its configuration quickly, and get real observability and evaluation, without ever leaving code to go configure something on a Drupal settings page.

Enter Neuron AI

Neuron AI is a PHP framework for building agents, tools and multi-step workflows. It handles the provider calls, the conversation memory, and the observability a run needs, so what's left to write is the part specific to what your agent actually does.

Under the hood, five concepts drive it:

Introducing the AI Neuron module

Reading the overview above, the shape of the integration seems obvious: translate each Drupal AI object into its Neuron equivalent, one for one. For providers, that's exactly what happens. A Drupal AI provider becomes a native Neuron provider, and the site's keys, default models and caching apply unchanged.

For tools and agents, we built something different. Neuron is a full framework in its own right, with its own tool-calling loop, its own memory, its own way of streaming and evaluating a run. Translating a Drupal tool or a Drupal agent into its Neuron equivalent would mean keeping two shapes in sync, and whatever came out the other end would still carry Drupal's own assumptions into an object Neuron has to treat as entirely its own.

So instead, developers write Neuron objects directly, as Drupal plugins, with no translation step in between. A plugin is a factory for the agent, the tool or the workflow it declares, built fresh each time one is asked for: it reaches into Drupal, its service container, its permissions, whatever the site has configured, and uses all of that to build a native Neuron object.

What comes out is exactly what Neuron itself would build from its own API, with no Drupal shape to it, which is the point: Neuron can test it against its own fake providers and evaluate it with its own harness, with no idea Drupal was ever involved.

That division pays off later, too. When the AI module's own tools and agents get bridged in, they'll be built the same way: plugins that manufacture the native Neuron object itself.

What you don't have to build: data persistence and logging

Every agent and workflow a plugin manager builds also gets storage, persistence and logging for free, on top of the provider bridge above.

That's the original promise kept: iterate on the agent, while the storage, persistence, logging and provider connection around it stay fixed.

Manufacturing native Neuron objects

With the ai_neuron module, Neuron's three building blocks, agent, tool and workflow, become Drupal plugins.

As outlined above, a plugin is a factory for native Neuron objects: ask the related plugin manager for one by its id and get back a native Neuron object.

Here's an example of a Drupal plugin that builds the matching Neuron object. Extend the base class and fill in the same methods you'd write against Neuron directly:

#[NeuronAgent(
  id: 'reporter',
  label: new TranslatableMarkup('Reporter'),
)]
final class ReporterNeuronAgent extends NeuronAgentPluginBase {

  protected function instructions(): string {
    return 'Summarize the content that changed.';
  }

}

A tool is a plugin too. Declare its properties, then put the tool's logic in __invoke():

#[NeuronTool(
  id: 'count_posts',
  description: 'Count the published posts of a content type.',
)]
final class CountPostsNeuronTool extends NeuronToolPluginBase {

  protected function properties(): array {
    return [new ToolProperty('type', PropertyType::STRING, 'The content type.', TRUE)];
  }

  public function __invoke(string $type): string {
    // Count them and say so.
  }

}

A workflow is declared the same way: list the nodes it's made of, and Neuron takes care of the rest:

#[NeuronWorkflow(
  id: 'edit_post',
  label: new TranslatableMarkup('Edit a post'),
)]
final class EditPostNeuronWorkflow extends NeuronWorkflowPluginBase {

  protected function nodes(): array {
    return [
      new LoadPostNode($this->entityTypeManager),
      new ReviseNode($this->agents),
      new SavePostNode($this->entityTypeManager),
    ];
  }

}

Each node declares, in its own method signature, the one event it accepts, but it can fire any event back. That's the whole wiring: whichever node listens for the fired event starts next, with nothing left to configure by hand.

It also means a node can fire a different event depending on what it finds, starting a different node in response, which is what lets developers build workflows that branch and loop, as complex as they need.

Declaring these as Drupal plugins buys the usual things for free. The site discovers them with no manual registration, from any module that declares one, and a constructor asking for EntityTypeManagerInterface, or any other Drupal service, gets it through dependency injection like any other plugin.

Fetching and using one goes through its manager, which hands back a native Neuron object each time, a new one, because an agent carries the conversation it's having:

$agent = \Drupal::service(NeuronAgentManagerInterface::class)->createAgent('reporter');
$agent->chat($message);

From there it goes anywhere Neuron takes it, straight through Neuron's own API: chat(), stream(), tools, middleware, chat history.

getNeuron() is the factory method behind all of this: it builds the native object, wiring in the provider, the tools, the error handler, whatever the plugin declared.

Overriding getNeuron() is the escape hatch, and it goes both ways. Drop in a hand-written Neuron agent, tool or workflow wholesale, and the base class configures nothing on top of it. That's also the door for anything built outside Drupal entirely: NeuronHub, Neuron's own package registry, publishes ready-made agents, workflows and toolkits, and any of them plugs into a site the same way, through the same override.

Try it

The easiest way to try it is to clone the repo and follow the instructions in its README.md: they set up a working site with the example module already enabled.

The ai_neuron_example submodule is a working agent you can talk to from the terminal: a Ghostwriter that writes blog posts for you. It ships a minimal Blog content type, three tools that create, list and edit posts, and an editing workflow of three nodes that the agent reaches through a tool, so one command exercises all three plugin types, plus structured output for the node that rewrites a post:

ddev drush ghost

It asks for a title and a body, and only invents them when you tell it to ("you decide", "don't ask, just create it"), in which case it writes whatever's missing and creates the post in the same reply. Every event a run emits prints to the terminal as it happens, tool calls and workflow nodes included, so you watch a run happen live. The command also names the conversation it reopens, so you can leave it and pick it back up later, which is the conversation store's work made visible.

What's next

Five things are planned, in no particular order:

Tags: Drupal Planet, AI

21 Oct 2026 1:30pm GMT

Aten Design Group: Mercury Editor 3: A Better Visual Editing Experience for Drupal

Mercury Editor 3: A Better Visual Editing Experience for Drupal

Mercury Editor 3.0 announcement graphic

Justin Toupin Drupal Mercury Editor

Last week, I pushed a stable release for Mercury Editor 3. It's been a long time coming, and I'm excited to share a number of new features that make it easier than ever to create and edit structured content in Drupal.

Mercury Editor has always been about making Drupal's powerful content architecture more approachable for editors. Version 3 takes a big step forward, with automatic saving, undo and redo, improved component navigation, and a more refined editing experience.

What's New in Mercury Editor 3

Auto-Save

As you type, add or remove media, reorder fields, and make other changes, Mercury Editor automatically saves your work and updates the live preview. No need to constantly switch between editing, saving, and previewing.

Undo and Redo

Experiment with confidence. Mercury Editor now supports undo and redo, making it easy to try different content arrangements and quickly reverse changes without starting over.

Component Tree View

A new component tree provides an outline of layout sections and components, making it easier to navigate complex pages. Quickly find and select components, even when they're nested several levels deep.

A Refined Editing Experience

We've updated and refined the entire interface to make editing more intuitive. Editors can navigate layouts, mix and match components, and experiment with content, all while working within the design system and editorial guidelines established for their website.

How Mercury Editor Works

At its core, Mercury Editor provides a live visual preview for editing structured content in Drupal.

Rather than replacing Drupal's content architecture, Mercury Editor builds on it. It works with familiar Drupal entities, including nodes and taxonomy terms, and uses the same fields and forms your site already relies on.

The difference is the editing experience.

Mercury Editor moves the traditional content edit form into a collapsible sidebar alongside a live preview of the content. As editors make changes, the preview updates automatically, showing them what their content will look like without having to save and reload the page.

This makes a huge difference when editing complicated content. Editors can immediately see how their changes affect the page, without having to guess where a field appears or what the finished result will look like.

Even Better with Paragraphs and Layout Paragraphs

Mercury Editor really shines on websites using Paragraphs and Layout Paragraphs.

With Layout Paragraphs, content components become interactive elements in the live preview. Editors can click directly on components to edit them, drag and drop to rearrange content, add new components, and remove existing ones.

Everything happens in context, with the preview updating as changes are made.

No more wondering which field controls a particular piece of content, whether an image will fit, or how to find that nested component several layers deep.

Editors can build expressive, flexible pages using reusable components while staying within the design and brand guidelines established by their site builders and developers.

It's an intuitive editing experience built on Drupal's existing strengths.

Mercury Editor and Drupal Canvas

With all the excitement around Drupal Canvas, it's worth explaining how Mercury Editor fits into the picture.

At first glance, there are obvious similarities. Both provide visual, interactive experiences for working with components in Drupal. Both make it possible to build sophisticated pages without writing code.

But they take fundamentally different architectural approaches and have different primary goals.

Drupal Canvas: Visual Site Building and Theming

Drupal Canvas is quickly gaining momentum as a new approach to browser-based site building and theming in Drupal.

It provides tools for creating, styling, and assembling components, building pages, and defining the visual structure of a website. It gives site builders greater control over the design and presentation of content directly in the browser.

Canvas represents an exciting direction for Drupal, particularly for teams looking to make site building and theming more accessible.

Mercury Editor: Visual Editing for Structured Content

Mercury Editor has a different focus.

It's not a site building or theming tool. It doesn't provide an interface for creating components or defining the templates used by entire content types.

Instead, Mercury Editor focuses on the experience of editing content within Drupal's existing entity and field architecture.

Think of a university website with content types for Faculty, Programs, and News. Developers and site builders establish the fields, components, layouts, and templates used by those content types. Mercury Editor gives content editors a visual, interactive interface for working with the content itself.

For sites using Layout Paragraphs, that includes building flexible page layouts from reusable components. But those components are still part of Drupal's structured content model, using familiar fields, entity references, and other Drupal functionality.

Mercury Editor is fundamentally about making structured content easier to edit, not changing how that content is modeled or rendered.

And that's an important distinction.

Drupal's entity and field architecture remains one of its greatest strengths, particularly for organizations managing complex, structured content across large websites.

Mercury Editor makes that architecture more accessible to the people responsible for maintaining content every day.

Canvas and Mercury Editor are different approaches, but I think both have an important role to play in Drupal's future.

Give Mercury Editor a Try

The fastest way to experience Mercury Editor is with the Mercury Editor Demo Recipe.

The recipe installs and configures Mercury Editor along with a demo content type, reusable paragraph components, layouts, and sample content.

Note: The demo recipe creates new content types, paragraph types, and sample content on your website, so I recommend trying it in a development environment.

From your Drupal project root, run:

composer require 'drupal/mercury_editor_demo_recipe:^3.0'

Then, from your Drupal document root (typically web/), apply the recipe:

drush recipe ../recipes/mercury_editor_demo_recipe

The recipe installs Mercury Editor and its required dependencies automatically.

Alternatively, you can install Mercury Editor directly:

composer require 'drupal/mercury_editor:^3.0'
drush en mercury_editor

Then enable Mercury Editor for the desired entity types under Administration → Configuration → Mercury Editor settings.

Mercury Editor is open source and completely free to use.

More importantly, it's a community project, and we'd love your help making it better.

Give it a try, share your feedback, submit feature requests, or report bugs in the Mercury Editor issue queue.

I'm excited about how far Mercury Editor has come, and even more excited about what's next.

Mercury Editor 3.0 announcement graphic

Justin Toupin

21 Oct 2026 1:29pm GMT