As we now know, this bug was two bugs really, where the first resulted by being case-sensitive while parsing HTTP headers when the specification says they are not.
This occurred in the implementation for the HTTP/3 stack only.
C.f. Mozilla Firefox bug database -
a server responded with "content-length:" instead of the ubiquitous
"Content-Length:" header
Here is the source code commit that fixed this (scroll to the bottom to see the fix).
The second bug was that there was no logic to continue implemented if the "Content-Length:" header could not be found in the response. So the continuation was to "look again for the header that could not be found" and "again" and "again" ... resulting in an endless loop.
You can see the discussion further down in the same entry of the Mozilla Firefox bug database.
The fix for this bug is seen here.
So these bugs were lurking for quite some time now - they just got triggered now.
It is assumed that a big cloud provider changed their load-balancing proxies to return lowercase headers at some point.
This would explain why there was no update of Firefox involved and it even happened to far older versions like 91.0.
Some said disabling telemetry fixed it for them, so it may be that just Firefox sending the open-tabs-count or the OS version to Mozilla's servers could have triggered this bug without any user-entered website being involved.