CVE-2022-0577:scrapy: Exposure of sensitive information across domains on redirect
A reconstruction of the flaw, and the evidence path Lachesis follows to make it visible.
User cookies set on a Request survive a cross-domain redirect and are re-sent to the new domain -- a cookie leak.
That is the shape of the failure. The rest of this case file follows the evidence behind it.
What was known.
What Lachesis established.
Known before Lachesis ran
The CVE and vulnerable release were selected from public history. We are not claiming novel discovery.
- CVE
- CVE-2022-0577
- Vulnerable target
- 2.5.1 (affected: >= 2.0.0, < 2.6.0; and < 1.8.2 for the 1.x line) · vulnerable
- Prior knowledge
- CVE-2022-0577 · 2.5.1 (affected: >= 2.0.0, < 2.6.0; and < 1.8.2 for the 1.x line) is vulnerable
Independent re-detection
The experiment graph was built around the Scrapy library tree at the vulnerable release (scrapy-2.5.1, in the affected range >=2.0.0 <2.6.0), rather than starting from arbitrary source. We did not point the tool at the CVE. Enumeration ran over the whole candidate registry (31 constructors, every family) with the pass-3 ranker ordering leads; 935 candidates were enumerated and the navigation.fetch.destination (request forgery & redirection) family surfaced on its own -- 200 observations, of which the top-ranked selected candidate is open(self.statefn, 'rb') in the SpiderState extension. Every field under sast_output is the enumerator's own emission (candidate capsule plus sources_of value-flow cone); everything under adjudication is my reading of the source and the advisory and is labelled as such. Note the honesty caveat below: the flagged sink is a local state-file read that the Atropos model mislabels as a URL-open/SSRF sink; it is not the redirect cookie-leak that is the CVE, and the CVE's own class (cross-domain sensitive-info exposure on redirect, CWE-200/863) has no sink family in the catalog.
- Seeded inputs
- None
- Run timestamp
- 2026-09-02T14:18:03Z
- Evidence artifact
- scrapy_2.5.1.kuzu
The commands and outputs below come from this recorded Lachesis run.
What Lachesis reconstructed.
One historical repository. Four captured queries. A complete source-to-sink argument.
Lachesis follows the same evidence path through unfamiliar repositories.
Here is how the path becomes visible.
These are the recorded questions Lachesis asked of the historical vulnerable code, followed by the raw result and source location each query returned.
Captured runThis is a real replay of Lachesis over the graph we built for this case (scrapy-2.5.1, scrapy/ tree, 45505 nodes / 129092 edges). Every command below was run against that graph and every result is captured output; the run took 38.2s. We did not point the tool at a file or a family. The hunt enumerated the whole taxonomy (935 candidates) and the navigation family came out of that ordering. No request or payload was seeded; the finding was discovered from graph structure, so the mode is independent-redetection. The honest limitation -- that the top navigation candidate is a mislabeled local file open rather than the redirect cookie-leak, and that the CVE's class has no catalog family -- is recorded above and adjudicated below.
Load the graph and list every bug family
First we load the graph and ask the tool to list every bug family it knows, with nothing chosen ahead of time. It reports all 8 domains and 31 constructors and enumerates 935 candidates. navigation.fetch.destination (request forgery & redirection) is one family among many, not a target we selected.
[lachesis-mcp] loaded the graph (published 45505 nodes and 129092 edges, cpython-ast frontend)
CANDIDATE_CENSUS
taxonomy (8): lifecycle, memory, injection, navigation, object-integrity, filesystem, crypto-config, resource
constructors (31): complete_for_observable_graph=True
935 candidates enumerated; families_that_fired includes navigation.fetch.destination=200A small line with a large consequence.
the redirected request preserves cookies and the Cookie header with no comparison of the source and redirect domains, so cross-domain redirects leak cookies to an unintended domain.
request.replace(url=redirected_url) # no source-vs-redirect host check; cookies re-sent
// always reset cookies (cookies=None) and drop a manually-set Cookie header when the redirect target's netloc differs from the source's -- fixed in 2.6.0 (commit 8ce01b3b) via _build_redirect_request; backported to 1.8.2.
The original record.
Read the historical advisory and vulnerability record behind this reconstruction.