Please, tell me to delete the POC video before validation, Thanks ( Or maybe invalidation :) )

The Fix can is this :

don't redirect sensitive Headers in redirection to another host.

Hey Graham, Can I delete the video POC if it is possible?

@grahamcampbell - our system has automatically assigned a CVE for this report. Would you like us to keep/remove this? Furthermore, for future reports, what would you/your team prefer?

No, we don't need CVEs from huntr.dev. We will have them issued by GitHub.

A fix is prepared for this vulnerability and another that I have discovered, looking over this code. We are going to get a review from a 3rd party, and then release the fixes along with 2 CVEs.

@grahamcampbell - no worries, I have removed the automatic CVE from this report, and all future approved reports.

Any reason you would prefer issuing them via GitHub instead of us taking care of it for you?

Regarding the fix, once you are ready, feel free to confirm the fix for both reports, and let me know what the CVE IDs are, and I can attach them to each relevant report for you 👍

We have been allocated CVE-2022-31042. This NOT yet public, at this time.

Please find below the draft description (@amammad and @jamieslome - please review this):

Impact

Cookie headers on requests are sensitive information. On making a request using the https scheme to a server which responds with a redirect to a URI with the http scheme, or on making a request to a server which responds with a redirect to a a URI to a different host, we should not forward the Cookie header on. Prior to this fix, only cookies that were managed by our cookie middleware would be safely removed, and any Cookie header manually added to the initial request would not be stripped. We now always strip it, and allow the cookie middleware to re-add any cookies that it deems should be there.

Patches

Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4.

Workarounds

An alternative approach would be to use your own retry middleware, rather than ours, if you are unable to upgrade.

References

RFC9110 Section 15.4

For more information

If you have any questions or comments about this advisory, please get in touch with us in #guzzle on the PHP HTTP Slack. Do not report additional security advisories in that public channel, however - please follow our vulnerability reporting process.

Hey Graham, I think we are on the same page! Cheers!

@grahamcampbell - LGTM 👍

Are we able to add the huntr.dev report URL as a reference?

@admin @maintainer I submiited same report 4 months ago but maintainer rejected it https://huntr.dev/bounties/b8379541-566c-4cf2-bf81-633bde3de3da/ Can you plz check it

No, this is not the same issue. Your issue refers to a change in host, but this issue refers to a change in scheme.

Change in host has more severity than change in scheme. Because When change in host happen then cookie is sent to totally different host. But when change in scheme happen then cookie is sent to same host but different scheme.

@maintainer I see you already admitted in your previous comment that cookie should not be send to third party different host as cookie is sensitive information.

Cookie headers on requests are sensitive information. On making a request using the https scheme to a server which responds with a redirect to a URI with the http scheme, or on making a request to a server which responds with a redirect to a a URI to a different host, we should not forward the Cookie header on

@mainatiner After reading this report carefully I see this report is exactly same as mine

Bug reporter send this report as thirdparty host cookie leak and also maintioned two report url is mine . I see no difference between my original report this report

Reporter submiited this bug here as change in host. And my report was same. Change in host has more severity than change in scheme here