Repository navigation
chore(deps): bump github.com/projectdiscovery/utils@v0.11.6 - #7766
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review. WalkthroughThe go.mod file changes dependency declarations: hdm/jarm-go is declared directly, projectdiscovery/utils is updated, and projectdiscovery/jarm-go is added indirectly. ChangesModule dependency declarations
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~5 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to This dependency-only change brings in the reported zstd fix, with matching checksum updates. No actionable merge risk is apparent from the reviewed changes. Architecture SummaryArchitecture risk: 🔵 Low · up to The change affects 1 system. Changed systems: Architecture concerns Review detailsSystems and components
Before / after behavior
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
A rabbit checks the module list, Comment |
Neo - PR Security ReviewThis incremental delta promotes utils from its pseudo-version to the now-tagged v0.11.6 release and records the corresponding go.sum checksums — no nuclei source code was modified and no exploitable vulnerabilities were introduced. What Neo reviewed
Comment |
ea3e658 to
6910eb7
Compare
http.NewResponseChain() decompresses Content-Encoding: zstd responses through utils's wrapDecodeReader(), which builds a *zstd.Decoder and wraps it in io.NopCloser. The decoder is never closed, and klauspost's zstd decoder keeps background worker goroutines alive until Close() is called. When a response's decompressed size exceeds MaxBodyRead, the LimitReader stops before EOF, the decoder's workers block permanently, and the goroutines plus their window buffers leak for the life of the process (projectdiscovery#7749). gzip/deflate/brotli don't spawn goroutines, so only zstd is affected. The fix (github.com/projectdiscovery/utils@27864e5, PR projectdiscovery#783) already landed on utils's main branch, but no tagged release contains it yet (latest is v0.11.5), so go.mod still points at v0.11.4. Bump to a pseudo-version pinned at that commit as the interim step the issue calls for, to be replaced by a tagged version once utils cuts one. Verified with the deterministic reproducer from the issue report (NewResponseChain + Fill against a >cap zstd body, 50 iterations): goroutine count returns to baseline (delta=0) instead of leaking ~1 goroutine per response.
6910eb7 to
0b404b6
Compare
Signed-off-by: Dwi Siswanto <git@dw1.io>
7c7d6d2 to
ddc104f
Compare
Closes #7749.
Root cause is in the pinned
github.com/projectdiscovery/utilsdependency,http/normalization.go, exactly as the issue describes: zstd responses are decompressed through a*zstd.Decoderwrapped inio.NopCloser, so the decoder's background worker goroutines never get released. When a response's decompressed size exceedsMaxBodyRead,LimitReaderstops before EOF, the workers block permanently, and each such response leaks goroutines plus their window buffers until the process gets OOM-killed. gzip/deflate/brotli don't spawn goroutines, so this is zstd-only.The fix already landed upstream —
github.com/projectdiscovery/utils@27864e5(utils PR #783, merged 2026-09-21) forces synchronous decode viazstd.WithDecoderConcurrency(1). But no tagged utils release contains that commit yet (latest tag is v0.11.5, which doesn't include it), and dev is pinned to v0.11.4, which has the bug. This PR bumpsgo.modto a pseudo-version at that commit — the interim step the issue itself calls for — so nuclei picks up the fix now instead of waiting on a release. Happy to switch this to a tagged version once one ships.Verification: ran the deterministic reproducer from the issue report (
NewResponseChain+Fillagainst a >cap zstd body, 50 iterations, with a gzip control) against the bumped dependency:The issue's own numbers on the buggy version showed delta=+57 for the same scenario.
go build ./...,go vet ./pkg/protocols/http/..., andgo test ./pkg/protocols/http/httpclientpool/...all pass.Summary by CodeRabbit