by David Snopek on February 21, 2018 - 12:37pm

Today, there is a Critical security release for Drupal core to fix multiple vulnerabilities. You can learn more in the security advisory:

Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2018-001

What makes this release special, is that some of these issues also affect Drupal 6! So, we're also making a Drupal 6 Long-Term Support (D6LTS) release of Drupal core.

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!

The following vulnerabilities mentioned in the security advisory affect Drupal 6:

  • JavaScript cross-site scripting prevention is incomplete - Critical

  • jQuery vulnerability with untrusted domains - Moderately Critical

  • External link injection on 404 pages when linking to the current page - Less Critical

Here you can download the Drupal 6 patch to fix, or a full release ZIP or TAR.GZ.

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 them (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!



the standalone patch lacks the update on the core version ( is this on purpose?

Yes, sort of.

The patches that we commit to the 'd6lts' repo are the common patches shared by all the D6LTS vendors, so those are just the pure security fixes. The special releases that we make (like Drupal 6.41) are for use with the 'mydropwizard' module, which is free and Open Source, of course, but the other D6LTS vendors can make their own releases and versions. I know that Tag1 makes their own releases - I think Acquia uses ours (some of their folks have commented on ours or opened issues for the 'mydropwizard' module) but I don't know for certain.

In any case, we could certainly start making mydropwizard-specific patches! For the modules, I think most people use the full releases, but core might be a little a different.

Here's a new patch that includes the version number change. However, I just realized this is a little unsustainable. This patch goes from 6.38 (the last non-LTS release) to 6.41. However, when the next patch comes out, do we give a patch from 6.38 and 6.41? Also, I think this patch won't apply on Pressflow, whereas the other one would. (We also have an open PR to Pressflow, so hopefully that'll just get merged upstream.)

But if that turns out to be popular, I'm sure we can come up with something. :-)

I see, having the version change into the standalone patch makes a stronger assumption on what codebase it is going to be applied.

I guess it's OK to leave it out then, users with a mixed environment (standalone patch + 'mydropwizard' module) can always patch in the version themselves to make the 'mydropwizard' module happy. That's what I did.

On the other hand if standalone patches are going to be created always against the latest official version (6.38), having a version reference somewhere (even just in the filename) would communicate that better. Something like "d6_6.38-d6lts_6.41-SA-CORE-2018-001.patch".


Just want to say, many, many thanks for providing this support. I have one or two old 6 sites that haven't been replaced yet, and I'd be lost without you.