docs(sentinel): remove false urllib SSRF record - #1633
Conversation
|
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| ## 2026-09-01 - Prevent SSRF in urllib by raising HTTPError on redirects | ||
| **Vulnerability:** Subclassing `urllib.request.HTTPRedirectHandler` and returning `None` to disable redirects leaves the handler vulnerable, as `None` simply passes the request back up the fallback chain, potentially resulting in returning a 301/302 response to the caller rather than preventing execution. | ||
| **Learning:** Returning `None` from `redirect_request` relies on default behavior to handle the response, not raising a true failure condition which is expected to halt SSRF bypasses via 301/302. | ||
| **Prevention:** To securely prevent redirects in `urllib` and avoid SSRF vulnerabilities, explicitly raise an `urllib.error.HTTPError` inside `redirect_request` instead of returning `None`. |
There was a problem hiding this comment.
📝 Info: Deleted redirect claim was false
build_opener(NoRedirectHandler()) replaced the default redirect handler, so returning None did not enable fallback redirect following. Explicit rejection and valid prevention guidance remain.
Was this helpful? React with 👍 or 👎 to provide feedback.
Preserve the current protected-main explicit urllib redirect hardening and its corrected Sentinel record while retaining #1628's workflow-backed Pages reconciliation, fail-before-write, stale-run cancellation, and documentation changes. This is a normal two-parent non-force reconciliation.
1 participant
Outcome
Remove the stale Sentinel entry introduced by #1631 that still described
HTTPRedirectHandler.redirect_request(...)->Noneas an active SSRF vulnerability after #1631's own corrected RCA established that the original opener composition already blocked redirects.Why
The merged #1631 source hardening remains valid: explicitly raising
HTTPErrorstates the no-redirect invariant without relying on handler composition. The Sentinel record, however, contradicted the corrected review and incorrectly preserved a HIGH-vulnerability narrative that #1631's PR body explicitly disclaimed.This PR restores documentation/evidence consistency only. It does not revert the explicit
HTTPErrorhardening, change URL validation, scanner thresholds, permissions, or branch protection.Exact head:
79bfcd8e764d44597fbe15e39b0d8f69863c2c1b.