The Drupal Webform Module Reported 22 Vulnerabilities. We Made Sure Drupal 7 is Covered.

Where the 22 Webform advisories came from

Webform 6.2.12 and 6.3.1 shipped with 22 security fixes. They cover submission access, remote post handlers, exports, uploaded-file delivery, template rendering, and a few other areas. The 6.2.12 and 6.3.1 release notes list them all. If you run Webform on Drupal 10 or 11, update now.

Twenty-two is a lot for one module in one day. Jacob Rockowitz, who created Webform and still maintains it, explains how it happened in Vibing Drupal: Using AI to hammer at the Webform module's security issues. He had a backlog of reported security issues, the oldest from 2022. Over a few months he built a webform-security skill so his AI assistant could keep track of every open issue. From there he had it reproduce each bug and write a regression test before the fix. I also helped him juggle more than 20 merge requests across two release branches in the Security Team's private repository. In his words, AI "made a task that felt impossible possible."

Read his post if you haven't. He doesn't pretend the AI was brilliant. He's blunt about the slop and hallucinations he ran into, and clear that the direction and review came from him. He also sees where this leads: "with AI, we have to assume malicious actors will use it to find new ones."

I wrote about how AI broke open source security and why end-of-life software is the most exposed in June 2026. AI speeds up finding bugs, exploiting them, and fixing them. A project with an active maintainer gets all three, and Jacob's release is a good example of what that looks like. A project past end-of-life only gets the first two, because there's no upstream maintainer to ship the fix. The Drupal 7 branch of Webform is one of those projects.

Which Webform advisories affect Drupal 7?

SA-CONTRIB-2026-172 (CVE-2026-96357) is a cross-site scripting issue. Some uploaded file types weren't forced to download, so a browser could render them inline on the site's own origin.

SA-CONTRIB-2026-169 (CVE-2026-96366) is an access bypass. A submitter could change the file ID a form sends back so it pointed at a file they never uploaded.

Both advisories list everything before 6.2.12 as affected, and neither mentions Drupal 7. That's expected. Drupal 7 reached end-of-life on January 5, 2025, and the Security Team only covers supported branches. A volunteer team has to draw that line somewhere.

This time we had something to start from. As part of the coordinated release, the Security Team shared patches with Drupal 7 fixes for both issues with HeroDevs. Drupal 7 is outside their scope, so that was a generous thing to do, and it saved us real time. They described the patches as best-effort fixes rather than strict backports of the modern fix, which told us where to look first. From there we did what we do with every fix we ship upstream on our own, and reviewed it against the modern code before it went anywhere near a customer.

How we reviewed the patches

We applied each supplied patch as its own commit, so anyone reading the history can tell what came from upstream and what we added.

Then we compared them with the modern fix. The Webform 6.2.12 commits are public, so we put the Drupal 7 and Drupal 10/11 changes side by side and tested to make sure each Drupal 7 patch closed the same holes. Most of what we found came out of this step.

The supplied patches included tests, and we kept them. We wrote more tests for everything we changed, then ran the whole thing through our Drupal 7 CI matrix on PHP 5.6, 7.4, 8.2, and 8.3, since customers run all four.

Last, a second HeroDevs engineer reviewed the pull request independently. They found one of the same problems we had, which I'll come back to.

The access bypass fix held up

The Drupal 7 patch for SA-CONTRIB-2026-169 rejects a submitted file ID unless the current user has a legitimate claim to that file. We traced every accepted case back to data the module had already validated. It behaves a little differently from the modern fix, but the security result is the same. We shipped it unchanged.

The Drupal 7 XSS fix had two gaps

This is where the side-by-side comparison paid off.

The first gap is that the patch only fixed the links. The modern fix works on the server response: when Webform serves a risky file type, it tells the browser to download the file and not display it. The Drupal 7 patch added the HTML5 download attribute to Webform's own links to those files. That's an improvement, but it does nothing if someone opens the file URL directly, and an attacker has no reason to use Webform's link. They can upload an HTML file with their own submission and send the URL to an administrator. Drupal controls the response for privately stored files, so we added a Content-Disposition: attachment header there, which is what the modern fix does.

The second gap is SVG. The modern fix keeps a list of risky MIME types and also treats any type ending in +xml as risky. That suffix rule is what catches SVG, which can carry script and is a file type lots of sites allow. The Drupal 7 patch copied the list but not the rule, so SVG and a few other XML-based types slipped through. This is the one our second reviewer caught on their own. We added the +xml rule, and we listed image/svg+xml explicitly as well, so the most common case doesn't depend on a suffix check.

The Drupal 7 patch still did real work. It protected Webform's own links, and it shipped with tests. Its authors were also clear from the start that it was best-effort. Drupal 7 and modern Webform split apart years ago. Closing the last few gaps across that distance is the part our customers count on us for.

What NEW for Drupal 7 customers get

The Drupal 7 Webform module release for NEW customers includes:

• The supplied access bypass fix, unchanged, with its tests
• The supplied XSS fix, with forced downloads for private files, the +xml rule, and SVG on the default list added on top.
• Tests for everything we added, passing on every PHP version we support.
• A changelog that separates what came from upstream from what we added.

One limitation applies to the modern fix too. Public files are served straight from the web server without going through Drupal, so nothing in PHP can control how a browser handles them. That's why Webform defaults new file components to private storage when a private file system is configured. If you have a public upload field that accepts HTML, SVG, or XML, change it, whatever Drupal version you're on.

Backports are rarely mechanical

A lot of people picture a backport as taking the patch, fixing the syntax, and shipping it. Sometimes that's all it is. Often it isn't.

An upstream fix is written for the code upstream supports. If your code split off years ago, you have to work the fix out again for the code you actually have. You need to understand what the modern fix defends against, and the diff alone won't tell you that. You look for spots where the old architecture has openings, the new one closed, and you write tests for the behavior you want. Then someone else checks your reasoning, because you'll miss things too.

None of that has to be slow. Everything in this post, from applying the supplied patches to the second review, happened in about a day.

I think this gets harder from here. Jacob showed what one maintainer with good AI tools can clear in a few months, and anyone poking at code nobody maintains has the same tools. Each of those 22 advisories deserves the kind of review described above, and most future ones won't arrive with a Drupal 7 patch attached.

If you're on EOL Drupal 7

If you're an NEW customer, the updated Webform release is already available through the usual channel, and all you need to do is apply it. If you want the review notes behind our two additions, ask and we'll send them.

If you're running Drupal 7 Webform without support, both advisories apply to you and there's no public fix for your branch. You can read the modern patches and write your own. This post is a fair picture of what that involves.

If you'd rather hand that work to someone else, we're happy to talk.