Patching Drupal without server access

If you don't have access to the file system on the server for a Drupal site, when a security issue like Drupalgeddon2 comes along, you are entitled to panic! Many sites are run by a combination of teams, so sometimes you really don't have control over the server... but that might even mean there is another way to apply fixes. If you've been tasked with updating such a site (I was!), it's worth checking if the server has been misconfigured in such a way to actually allow you to patch Drupal, via Drupal!

A heavy caveat first: we would never recommend servers to be set up like this, nor that you try this without extreme care!

Instead, you should do everything you can to get secure access to the server and communicate with those responsible for managing it. But I realise that sometimes you just have to be practical and improvise, building on many years of experience. For special occasions like this, I suggest making it very clear to anyone around you that you are now proceeding to do something very dodgy. Perhaps wear an enormous sombrero, or play overly dramatic music across the office?

So, assuming you can at least log in as an admin, first get the Devel module installed. It can slow site down, and may be a security risk in itself, so it shouldn't normally enabled on a production site, but it's common to at least be in the codebase, since it's so useful during development. If it's not listed on the modules page, maybe your site allows modules to be uploaded through the interface at /admin/modules/install ? (That functionality always scares me...) Anyway, get Devel installed if you can, and ensure you have 'Access developer information' and 'Execute PHP code' permissions.

That last bit hints at where we're going with this... head to /devel/php and you'll find you can run PHP code from a text box! Now, the next bit relies on a server misconfiguration. Web servers "should not have write permissions to the code in your Drupal directory" ... but maybe yours does. Find out by attempting to modify the code of one of Drupal's files. For Drupal 7, that means putting the following code into the box and submitting it. For Drupal 8, you can do something similar, but the text being replaced here will need to be something that else that does exist in a file.

// Load up Drupal's bootstrap file.
$file = DRUPAL_ROOT . '/includes/bootstrap.inc';
$content = file_get_contents($file);
// Add a comment to the end of one of the lines.
$hacked = str_replace('drupal_settings_initialize();', 'drupal_settings_initialize(); // james was here', $content);
// Replace the file.
file_put_contents($file, $hacked);

// Print the contents of the file.
dpm(file_get_contents($file));

If you see 'james was here' in the response, you will be able to hack a patch into Drupal a bit like this! If not, congratulations, your web server is correctly configured not to allow this!

I won't put the actual fix here, as you can probably figure it out from there - you'll probably want to use str_replace() similarly on the appropriate file(s) that needs patching, for example. (If you can't figure it out, then you probably shouldn't trust yourself with this level of 'hacking' a fix onto a site!)

To verify your fix, you can do the following:

1. Go to /devel/php?%23that=thing&other=this
2. Run dpm($_GET);
3. The resulting array should only have the 'q' and 'other' parts, as the '%23that=thing' part should have been stripped by the security fix.

If you really want, you can add $conf['sanitize_input_logging'] = TRUE; to your site's settings.php file (or $settings['sanitize_input_logging'] = TRUE; for Drupal 8) to log any unsafe inputs that get tried against your site (whether you've applied the fix the proper way or like this). That would show the '%23that=thing' up under /admin/reports/dblog , if you've got database logging enabled.