fix(deps): update dependency io.netty:netty-codec-http to v4.1.133.final [security]#234
Merged
magisk317 merged 1 commit intoMay 6, 2026
Conversation
评审者指南(在小型 PR 上折叠)评审者指南在 Gradle 构建配置中将强制依赖 依赖更新前后 Netty 处理 HTTP 请求的时序图sequenceDiagram
participant ClientCode
participant DefaultHttpRequest
participant HttpUtil
participant HttpRequestEncoder
participant DownstreamServer
rect rgb(255,230,230)
note over ClientCode,DownstreamServer: Vulnerable_version netty_codec_http 4_1_132_Final
ClientCode->>DefaultHttpRequest: new DefaultHttpRequest(method, safeUri)
DefaultHttpRequest->>HttpUtil: validateRequestLineTokens(method, safeUri)
HttpUtil-->>DefaultHttpRequest: OK
ClientCode->>DefaultHttpRequest: setUri(attackerControlledUriWithCRLF)
DefaultHttpRequest-->>ClientCode: uri set without revalidation
ClientCode->>HttpRequestEncoder: writeOutbound(request)
HttpRequestEncoder-->>DownstreamServer: encoded_request_with_smuggled_start_lines
DownstreamServer-->>DownstreamServer: parses_multiple_requests
end
rect rgb(230,255,230)
note over ClientCode,DownstreamServer: Patched_version netty_codec_http 4_1_133_Final
ClientCode->>DefaultHttpRequest: new DefaultHttpRequest(method, safeUri)
DefaultHttpRequest->>HttpUtil: validateRequestLineTokens(method, safeUri)
HttpUtil-->>DefaultHttpRequest: OK
ClientCode->>DefaultHttpRequest: setUri(attackerControlledUriWithCRLF)
DefaultHttpRequest->>HttpUtil: validateRequestLineTokens(method, newUri)
HttpUtil-->>DefaultHttpRequest: reject_invalid_uri
DefaultHttpRequest-->>ClientCode: throws_exception_or_error
ClientCode--X HttpRequestEncoder: request_not_encoded
DownstreamServer-->>DownstreamServer: no_request_smuggling
end
文件级变更
可能关联的问题
提示与命令与 Sourcery 交互
自定义你的使用体验访问你的 dashboard 以:
获取帮助Original review guide in EnglishReviewer's guide (collapsed on small PRs)Reviewer's GuideUpdates the forced io.netty:netty-codec-http dependency version to 4.1.133.Final in Gradle build configuration to pick up a security fix (CVE-2026-41417) related to HTTP/RTSP request smuggling via DefaultHttpRequest.setUri(). Sequence diagram for Netty HTTP request handling before and after dependency updatesequenceDiagram
participant ClientCode
participant DefaultHttpRequest
participant HttpUtil
participant HttpRequestEncoder
participant DownstreamServer
rect rgb(255,230,230)
note over ClientCode,DownstreamServer: Vulnerable_version netty_codec_http 4_1_132_Final
ClientCode->>DefaultHttpRequest: new DefaultHttpRequest(method, safeUri)
DefaultHttpRequest->>HttpUtil: validateRequestLineTokens(method, safeUri)
HttpUtil-->>DefaultHttpRequest: OK
ClientCode->>DefaultHttpRequest: setUri(attackerControlledUriWithCRLF)
DefaultHttpRequest-->>ClientCode: uri set without revalidation
ClientCode->>HttpRequestEncoder: writeOutbound(request)
HttpRequestEncoder-->>DownstreamServer: encoded_request_with_smuggled_start_lines
DownstreamServer-->>DownstreamServer: parses_multiple_requests
end
rect rgb(230,255,230)
note over ClientCode,DownstreamServer: Patched_version netty_codec_http 4_1_133_Final
ClientCode->>DefaultHttpRequest: new DefaultHttpRequest(method, safeUri)
DefaultHttpRequest->>HttpUtil: validateRequestLineTokens(method, safeUri)
HttpUtil-->>DefaultHttpRequest: OK
ClientCode->>DefaultHttpRequest: setUri(attackerControlledUriWithCRLF)
DefaultHttpRequest->>HttpUtil: validateRequestLineTokens(method, newUri)
HttpUtil-->>DefaultHttpRequest: reject_invalid_uri
DefaultHttpRequest-->>ClientCode: throws_exception_or_error
ClientCode--X HttpRequestEncoder: request_not_encoded
DownstreamServer-->>DownstreamServer: no_request_smuggling
end
File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
4.1.132.Final→4.1.133.FinalNetty: Start-Line Injection in DefaultHttpRequest.setUri() Allows HTTP Request Smuggling and RTSP Request Injection
CVE-2026-41417 / GHSA-v8h7-rr48-vmmv
More information
Details
Summary
Netty allows request-line validation to be bypassed when a
DefaultHttpRequestorDefaultFullHttpRequestis created first and its URI is later changed viasetUri().The constructors reject CRLF and whitespace characters that would break the start-line, but
setUri()does not apply the same validation.HttpRequestEncoderandRtspEncoderthen write the URI into the request line verbatim. If attacker-controlled input reachessetUri(), this enables CRLF injection and insertion of additional HTTP or RTSP requests.In practice, this leads to HTTP request smuggling / desynchronization on the HTTP side and request injection on the RTSP side.
Details
The root issue is that URI validation exists only on the constructor path, but not on the public setter path.
io.netty.handler.codec.http.DefaultHttpRequestHttpUtil.validateRequestLineTokens(method, uri)setUri(String uri)only performscheckNotNulland does not validateio.netty.handler.codec.http.DefaultFullHttpRequestsetUri(String uri)delegates to the parent implementationio.netty.handler.codec.http.HttpRequestEncoderrequest.uri()directly into the request lineio.netty.handler.codec.rtsp.RtspEncoderrequest.uri()directly into the request lineThis creates the following bypass:
DefaultHttpRequestorDefaultFullHttpRequestwith a safe URIsetUri()HttpRequestEncoderorRtspEncoderencodes that value verbatimThis appears to be an incomplete fix pattern where start-line validation exists, but can still be bypassed through a mutable public API.
PoC (HTTP)
The following code first creates a normal request object and then injects a malicious request line using
setUri().When reproduced, the raw encoded request looks like this:
HttpServerCodecthen parses this as multiple HTTP messages rather than a single request:GET /s1POST /s2with bodyHello WorldGET /s1This confirms that the value supplied through
setUri()is interpreted on the wire as additional requests.PoC (RTSP)
The same root cause also affects
RtspEncoder. A minimal reproduction is shown below.When reproduced,
RtspEncodergenerates consecutive RTSP requests in a single encoded payload:RtspDecoderthen parses this as three separate RTSP requests:OPTIONS rtsp://cam/streamDESCRIBE rtsp://cam/secretOPTIONS rtsp://cam/finalThis confirms that the same setter bypass is exploitable for RTSP request injection as well.
Impact
The vulnerable conditions are:
DefaultHttpRequestorDefaultFullHttpRequestsetUri()setUri()is attacker-controlled or attacker-influencedHttpRequestEncoderorRtspEncoderUnder those conditions, an attacker may be able to:
The exact impact depends on how the application constructs URIs and how the upstream/downstream HTTP or RTSP components parse request boundaries, but the security impact is real and reproducible.
Root Cause
Validation is enforced only at object construction time, but not on the public mutation API that can break the same security invariant.
As a result, the constructors are safe while the public
setUri()path is not, and the encoders trust and serialize the mutated value without revalidation.Suggested Fix Direction
DefaultHttpRequest.setUri()and all delegating/inheriting paths should apply the same request-line token validation as the constructors.Recommended regression coverage:
setUri()rejects CRLF-containing input after object constructionDefaultFullHttpRequest.setUri()is blocked as well\r,\n, and request-smuggling payloads are rejectedHttpRequestEncoderandRtspEncoderare protected from setter-based bypassesAffected Area
netty-codec-httpio.netty.handler.codec.http.DefaultHttpRequestio.netty.handler.codec.http.DefaultFullHttpRequestio.netty.handler.codec.http.HttpRequestEncoderio.netty.handler.codec.rtsp.RtspEncoderSeverity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Netty: Start-Line Injection in DefaultHttpRequest.setUri() Allows HTTP Request Smuggling and RTSP Request Injection
CVE-2026-41417 / GHSA-v8h7-rr48-vmmv
More information
Details
Summary
Netty allows request-line validation to be bypassed when a
DefaultHttpRequestorDefaultFullHttpRequestis created first and its URI is later changed viasetUri().The constructors reject CRLF and whitespace characters that would break the start-line, but
setUri()does not apply the same validation.HttpRequestEncoderandRtspEncoderthen write the URI into the request line verbatim. If attacker-controlled input reachessetUri(), this enables CRLF injection and insertion of additional HTTP or RTSP requests.In practice, this leads to HTTP request smuggling / desynchronization on the HTTP side and request injection on the RTSP side.
Details
The root issue is that URI validation exists only on the constructor path, but not on the public setter path.
io.netty.handler.codec.http.DefaultHttpRequestHttpUtil.validateRequestLineTokens(method, uri)setUri(String uri)only performscheckNotNulland does not validateio.netty.handler.codec.http.DefaultFullHttpRequestsetUri(String uri)delegates to the parent implementationio.netty.handler.codec.http.HttpRequestEncoderrequest.uri()directly into the request lineio.netty.handler.codec.rtsp.RtspEncoderrequest.uri()directly into the request lineThis creates the following bypass:
DefaultHttpRequestorDefaultFullHttpRequestwith a safe URIsetUri()HttpRequestEncoderorRtspEncoderencodes that value verbatimThis appears to be an incomplete fix pattern where start-line validation exists, but can still be bypassed through a mutable public API.
PoC (HTTP)
The following code first creates a normal request object and then injects a malicious request line using
setUri().When reproduced, the raw encoded request looks like this:
HttpServerCodecthen parses this as multiple HTTP messages rather than a single request:GET /s1POST /s2with bodyHello WorldGET /s1This confirms that the value supplied through
setUri()is interpreted on the wire as additional requests.PoC (RTSP)
The same root cause also affects
RtspEncoder. A minimal reproduction is shown below.When reproduced,
RtspEncodergenerates consecutive RTSP requests in a single encoded payload:RtspDecoderthen parses this as three separate RTSP requests:OPTIONS rtsp://cam/streamDESCRIBE rtsp://cam/secretOPTIONS rtsp://cam/finalThis confirms that the same setter bypass is exploitable for RTSP request injection as well.
Impact
The vulnerable conditions are:
DefaultHttpRequestorDefaultFullHttpRequestsetUri()setUri()is attacker-controlled or attacker-influencedHttpRequestEncoderorRtspEncoderUnder those conditions, an attacker may be able to:
The exact impact depends on how the application constructs URIs and how the upstream/downstream HTTP or RTSP components parse request boundaries, but the security impact is real and reproducible.
Root Cause
Validation is enforced only at object construction time, but not on the public mutation API that can break the same security invariant.
As a result, the constructors are safe while the public
setUri()path is not, and the encoders trust and serialize the mutated value without revalidation.Suggested Fix Direction
DefaultHttpRequest.setUri()and all delegating/inheriting paths should apply the same request-line token validation as the constructors.Recommended regression coverage:
setUri()rejects CRLF-containing input after object constructionDefaultFullHttpRequest.setUri()is blocked as well\r,\n, and request-smuggling payloads are rejectedHttpRequestEncoderandRtspEncoderare protected from setter-based bypassesAffected Area
netty-codec-httpio.netty.handler.codec.http.DefaultHttpRequestio.netty.handler.codec.http.DefaultFullHttpRequestio.netty.handler.codec.http.HttpRequestEncoderio.netty.handler.codec.rtsp.RtspEncoderSeverity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate.
Summary by Sourcery
Build:
io.netty:netty-codec-http从4.1.132.Final升级到4.1.133.Final。Original summary in English
Summary by Sourcery
Build: