by David Snopek on April 25, 2018 - 11:53am

Today, there is a Critical security release for Drupal core to fix a Remote Code Execution (RCE) vulnerability. You can learn more in the security advisory:

Drupal core - Critical - Remote Code Execution - SA-CORE-2018-004

This issue also affects Drupal 6 (although, less severely than Drupal 7 or 8). So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core and the Filefield module.

Drupal 6 core security update

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

This fix is both for Drupal 6 core and the Filefield module. This is because the Drupal 7 & 8 fixes include changes to the core 'file' module, which isn't in Drupal 6 core, but an equivalent fix applies to the Filefield module.

Here you can download:

If you have a Drupal 6 site, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install security updates for contrib modules (even though they won't necessarily have a release on

Want to read more articles like this?


Subscribe to the blog and recieve e-mail updates when new articles are published!


Just to say thanks for this.

I have spent several days cleaning some Drpual sites including a D6 site which were horribly defaced (and crypto miner dropped on the server) because a colleague delayed the last security update. Any owner of a D6 site should be in doubt that updating is as critical as everyone says it is. Your Drupal 6 updates are invaluable. For anyone still running it, I note that the git repo for Pressflow 6 is also getting updates.

If we missed the release to SA-CORE-2018-003, should we find that patch first, apply it, then apply this one?

Are you sure you mean SA-CORE-2018-003?

SA-CORE-2018-003 doesn't directly apply to Drupal 6. If you're using a vulnerable version of CKEditor on your Drupal 6 site you should definitely up date that! But it won't require any changes to Drupal 6 core.

However, if you meant SA-CORE-2018-002, that does apply to Drupal 6 and is very important to get fixed! If you're updating Drupal 6 via the patches rather than the releases, you should apply the patch for 002 and then 004.

I hope that helps!

I forgot to say thanks for this clarification. I'm having trouble keeping up with all of the moving pieces of the puzzle.

I am running a site on Drupal 6.27. I cannot run the SA-CORE-2018-004 patch as my version of is way behind. I am migrating the site to a different platform but I still want to patch it in the meantime. Any chance you have a version of this patch that would work for me? That would be highly appreciated.

It's probably possible to create a patch for Drupal 6.27 that would fix this issue, however, you'd be missing quite a few other security updates that were made between 6.27 and 6.44! I'd highly recommend just updating all the way so you know you're completely protected from all known security vulnerabilities in Drupal 6 core. I'd be wary of making a 6.27 patch to make it seem like we're encouraging using it.

I totally understand David. I need the 6.27 patch just for a couple more weeks as I am transitioning the application out of Drupal. Could you please give me some guidelines on how to make a patch for the 6.27?

Unfortunately, no. You'll need to look at how the patch works on the latest Drupal 6 and find a way to do the same on 6.27. It's the kind of thing that I could probably do, but not really explain how to do :-)

Is Version updating possible with just the patch? After applying the SA-CORE-2018-004 patch to a site that's on 6.43, the admin/reports/status page still reports the site is on 6.43, but shouldn't it report 6.44? It would help satisfying the site owner that wants assurance that a patch has been applied.

Using just the patches won't update the version number (to do so would require making a patch that knew what version it was being applied to, ie. we'd need to make a "6.43 to 6.44 patch" and a "6.42 to 6.44 patch" and so on). If you want the version number to change you need to use the full releases, which I'd personally recommend, because that makes it easier to verify which security fixes a particular site has. I hope that helps!

Hi David,

Thanks for your fast response. I would recommend the full releases as well, but I think it's a pain to go through the switch as there is moving around of files and resetting of symbolic links. I can script some of it, but there's a lot of manual stuff, so I was hoping to do just a patch. Is there a way to add details to the status window indicating which patches I've applied?

You could download a clean copy of the current version you're on and the full release, make a full patch between them and then apply that? That's a bunch of work, but it would more practical than us trying to create a patch for every possible version someone could be coming from, which I think would be very confusing to explain (and wouldn't even necessarily work if you've applied any other patches).

Is there a way to add details to the status window indicating which patches I've applied?

Not without some refactoring of core to allow that. Really the problem is that for a patch to change some value, it has to either subtract that exact value, or know the lines that come before or after it. That makes it super hard to put in version markers especially if you've already applied some patches. Maybe if core looked at the contents of a directory and used that to say what patches there were, then the patch could put a file in that directory. But there isn't any functionality like that currently in core.

Actually, I wasn't thinking of passing this burden on to you, but more looking for advice. The idea I had was possibly to run a drush vset to set a variable indicating which security patch/patches has/have been applied, then a form or page alter or preprocessor to get this value and display it in the status page. I realize it's a custom solution but will keep the auditing wolves at bay if we can report this in the status page.

I always upgrade with a script that diffs the two official versions and applies the diff. Then it diffs the result and the new official version. Unless you made changes to the old code, the patches apply perfectly and there are no results in the final diff. If you made any changes of your own to the earlier version, you see them in the final diff. I sometimes change official code for trivialities like fixing what I consider a misleading message etc. Unless you are very unlucky, the diffs apply perfectly. When doing this to core, you must remember (or put it in your script) to add write permission to settings.php. or else the patch fails half way through. Then remove it afterwards, of course. Run your script once in dry run mode before doing the real run. The use drush to run any db updates.