CL.0 desync in www.microsoft.com

[shed riot <shed.riot () gmail com>]

# Summary

I reported the issue to the Microsoft Security Response Center twice:

* VULN-165381, MSRC case 102964
* VULN-165876, MSRC case 103259

In both cases, they do not appear to have even looked at the PoCs, and so
have failed to adequately investigate before reaching a decision.


# Vulnerability

CWE-444: HTTP Request/Response Smuggling

The observed behaviour was consistent with CL.0 HTTP desync within the
request-processing chain.


# Impact

HTTP desync can cause attacker-controlled bytes to be interpreted as
the beginning of another request on a shared back-end connection.

Depending on routing and connection reuse, this vulnerability class
can potentially be used to:

* alter or prefix another user's request;
* redirect users to attacker-controlled content;
* deliver reflected or stored client-side payloads;
* poison application or intermediary responses; or
* disclose information associated with another request or user.

I deliberately limited testing to a non-destructive proof of concept.
I did not attempt to deliver an active payload to unrelated Microsoft
users or extract their data.

Testing a desync issue against production infrastructure can affect
third-party requests. A fully weaponised test would therefore have
created an unacceptable risk to legitimate users.


# Proof of concept

The supplied proof of concept used two independent clients.

The attacker client submitted a crafted request containing bytes
after the declared request body.

The victim client then made an ordinary request.

The attacker-controlled content was subsequently observed in the
victim-side transaction.

The result demonstrated cross-request interference, rather than an
unusual response confined to the attacker's own connection.

The second submission also included screenshots, as MSRC couldn't
be arsed to run the PoCs themselves.


# Timeline

26 October 2025

I submitted the initial report as VULN-165381 and uploaded separate
exploit and victim scripts.

27 October 2025

MSRC opened case 102964.

29 October 2025

MSRC requested a video and asked which internal component was
affected.

30 October 2025

I explained that a video would only show the supplied scripts running.
Microsoft would need to trace the crafted request through its own
application stack to identify where it was split.

I also asked whether MSRC had run the scripts.

31 October 2025

MSRC closed the case as "not a vulnerability".

4 November 2025

I submitted the issue again as VULN-165876, including the scripts and
screenshots showing the attacker, victim and successful result.

5 November 2025

MSRC opened case 103259.

10 November 2025

MSRC stated that it required a proof of concept "demonstrating an
exploit", despite the scripts already having been supplied. The
responses indicate that the proof of concept had not been run.

18 November 2025

I asked whether MSRC had run and validated the proof of concept.

19 November 2025

Microsoft closed the second case, stating:

"You have not submitted sufficient evidence of HTTP desync. You have
only provided 2 shell scripts and no other information confirming that
the exploit works."

The second submission also contained screenshots demonstrating the
attacker, victim and successful result.

20 November 2025

I challenged the assessment and pointed out that the proof of concept
displayed the issue clearly, and that both reports appeared to have
been closed without MSRC running the PoC.

MSRC maintained its position and requested a copy of the disclosure
draft for technical review.


# Resolution

Microsoft closed both reports and stated that it would not track the
issue further. At no point do they appear to have run any of the
supplied PoC scripts.

The vuln still exists, and isn't difficult to find for someone
willing to scan the site. Fill your boots!


# References

* MSRC submission VULN-165381, case 102964
* MSRC submission VULN-165876, case 103259
* CWE-444: HTTP Request/Response Smuggling
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/