Defend against \GuzzleHttp\Cookie\FileCookieJar gadget chain

In the meantime I've submitted a PR to guzzle with a fairly crude way of minimising the impact of the Gadget Chain:

https://github.com/guzzle/guzzle/pull/3286

We'll see how that goes, but I don't think it's a reason to stop looking at dropping the class from Drupal.

The issue and linked PR are going nowhere fast.

I think we should consider replacing the class in Drupal core (per #3), removing it via composer, or removing it from the autoloader if that's feasible.

The issue I filed with Guzzle has been deleted. The PR hasn't, but it was marked as stale.

I am going to take that as a subtle hint that this is not going to be addressed upstream any time soon.

Using the BackwardsCompatibilityClassLoader seems a really good suggestion.

However, unless I'm missing something it won't work for this in isolation.

It looks like if the old file is still there, that's what will be autoloaded.

I added this to core/core.services.yml under core.moved_classes:

       change_record: https://www.drupal.org/node/3551049
+    'GuzzleHttp\Cookie\FileCookieJar':
+      class: 'Drupal\Component\Cookie\FileCookieJar'
   session.storage.options:

...and put an empty class in place:

$cat core/lib/Drupal/Component/Cookie/FileCookieJar.php 

<?php

namespace Drupal\Component\Cookie;

class FileCookieJar {}

If we then unserialize a bare FileCookieJar, we still get the old class:

$ ddev drush php
Psy Shell v0.12.18 (PHP 8.3.27 — cli) by Justin Hileman

> var_dump(unserialize('O:31:"GuzzleHttp\Cookie\FileCookieJar":0:{}'));
object(GuzzleHttp\Cookie\FileCookieJar)#14083 (4) {
  ["cookies":"GuzzleHttp\Cookie\CookieJar":private]=>
  array(0) {

...snip...

Whereas if I remove the old file, the alias kicks in:

> var_dump(unserialize('O:31:"GuzzleHttp\Cookie\FileCookieJar":0:{}'));
object(Drupal\Component\Cookie\FileCookieJar)#7067 (0) {
}
= null

I'm not sure if that's known / intentional behaviour (happy to file a followup if not) but I'm guessing it's not a problem for the main use of the BackwardsCompatibilityClassLoader.

We could perhaps combine the moved class with one of the earlier suggestions of getting composer to delete the file from vendor on install.

There is one module that uses it: tmgmt_smartling

Thanks. Yes it also looks like some tests use it - it looks like perhaps an old core test did so, and a handful of projects have copies of that old test:

https://git.drupalcode.org/project/drupalladder/-/blob/8.x-1.x/docroot/c...

These all look pretty old, but I've not done a thorough audit of whether any are still in active use.

I still think we could probably remove it by default and provide a way for projects that need it to get it back.. but it's not so clear that "nobody uses this at all".

In the new MR I'm trying to use the VendorHardening plugin to remove the file.

We could then provide our own copy somewhere else and alias it.

However, I'm not desperate to fork the file and have to try to keep it in sync with upstream.

We could think about patching it with https://github.com/guzzle/guzzle/pull/3286/changes (which doesn't look like it'll be merged any time soon) instead?

1) No I didn't contact the guzzle maintainers before filing a public issue / PR, as the details of the gadget chain have been public in the PHPGGC repo for 8+ years.

2) Agree that we cannot conclude that "nobody is using this" on the basis that we don't find (m)any usages in published contrib modules. I think the usage (or lack thereof) of the class is a relevant metric here though.

3) My current thinking on this is that I'd like to look at whether we can patch the class rather than remove it / make it unavailable.

Thanks for pointing out the new PR ( https://github.com/guzzle/guzzle/pull/3326 ). I'll take a look at that and maybe link back to the one I submitted ( https://github.com/guzzle/guzzle/pull/3286 ).

If the guzzle maintainers are happy to make a change that defends against the gadget chain, that'd be great.. and Drupal wouldn't need to do anything else.

If they don't, then I'd like to consider applying our own patch perhaps as part of the composer build; I've not had a chance to dig into the details of how that'd work yet.

Apparently the issue I filed for guzzle may have been auto-closed by a bot that tries to catch security issues being reported in public; I shouldn't have assumed that this had been done intentionally.

The good news is that the guzzle maintainers are working on what looks to me like a pretty decent protection against the Gadget Chain:

https://github.com/guzzle/guzzle/pull/3334

Bad news is that it'll be targetted for the next major release.

We could look at a backport patch that we could apply to earlier versions of guzzle (along the lines of my previous comment); the changes are fairly simple.

We should wait until the maintainers commit their fix upstream and then we can decide whether we want to just wait for that to land in Drupal or look at a backport patch.

I'll change this issue to "Postponed" on that basis.

Looks like the hardening was merged and should be in guzzle 8.0

https://github.com/guzzle/guzzle/pull/3334

So Drupal will benefit from that in the long run.

In the meantime, we could look at a backport patch which we'd apply via composer (IIUC).

New MR based on the suggestions in #17 / #18

I used Claude to help put this together, and I've not yet read through it all carefully - I will do before suggesting it's ready to merge.

I wanted to push this first draft and get the tests to run though.

Tests are passing - I'll check through everything a bit more thoroughly before marking this as Needs Review.

I've hopefully removed most of the LLMisms but the test assertions may still be a bit more verbose than needed.

I think this is ready for review.

Thanks, rebase was a little bit fiddly.

As this is putting a shim into composer.(json|lock) I think it's going to keep hitting the same problem.

The MR's failing because core main (12.x-dev) upgraded to Guzzle 8 on 2026-07-24 (#3612544: Update to Guzzle 8).

So that's great - only remaining question is whether we want to apply this shim to 11.x branches / releases.

MR is passing again on 11.x - back to RTBC based on where we were in #26.