CVE-2026-44248
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedNetty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, the MQTT 5 header Properties section is parsed and buffered before any message size limit is applied. Specifically, in MqttDecoder, the decodeVariableHeader() method is called before the bytesRemainingBeforeVariableHeader > maxBytesInMessage check. The decodeVariableHeader() can call other methods which will call decodeProperties(). Effectively, Netty does not apply any limits to the size of the properties being decoded. Additionally, because MqttDecoder extends ReplayingDecoder, Netty will repeatedly re-parse the enormous Properties sections and buffer the bytes in memory, until the entire thing parses to completion. This can cause high resource usage in both CPU and memory. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceNetty's MQTT 5 decoder parses and buffers the Properties section before applying the maxBytesInMessage limit. Since decodeVariableHeader() is called before the size check, an attacker can send MQTT messages with excessively large Properties sections that bypass limits. The ReplayingDecoder behavior causes repeated re-parsing, leading to high CPU and memory consumption (DoS).
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data< 4.1.133>= 4.2.0, < 4.2.13CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify Netty version in useInspect your project's dependency management (Maven pom.xml, Gradle build.gradle, or JAR manifest) to find the netty version. Run 'mvn dependency:tree | grep netty' or check your build files for 'io.netty:netty-*' dependencies.Affected if The Netty version is less than 4.1.133, or is 4.2.0 through 4.2.12 (inclusive)
-
Verify MQTT protocol usageSearch your codebase for MQTT CONNECT, CONNACK, or other MQTT packet handling code. Look for imports of 'io.netty.handler.codec.mqtt.*' and identify if your application acts as an MQTT broker or client.Affected if Your application uses Netty to handle MQTT protocol traffic, particularly MQTT 5 messages containing Properties in the variable header
-
Confirm MqttDecoder is configuredExamine your Netty pipeline configuration (Bootstrap, ServerBootstrap, or ChannelInitializer code) for 'MqttDecoder' in the channel pipeline. Check if MqttMessageDecoder or MqttDecoder is being added with MqttVersion.MQTT_5.Affected if The MqttDecoder is added to the Netty channel pipeline and handles MQTT 5 connections
-
Check maxBytesInMessage configurationReview the MqttDecoder or MqttMessageDecoder constructor arguments in your pipeline setup. Look for any maxBytesInMessage parameter values being passed, or check if MqttDecoderConfiguration is used to set this property.Affected if maxBytesInMessage is either not set (defaults to unlimited) or is set to a very large value, allowing unbounded Properties buffer parsing before size limits apply
You are affected if your Netty version falls in the vulnerable range (below 4.1.133 or between 4.2.0 and 4.2.12), you use MqttDecoder for MQTT 5 traffic, and maxBytesInMessage is not properly limiting message size before properties parsing.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped4.1.1334.2.13
Upgrade Netty to version 4.2.13.Final or 4.1.133.Final which applies the message size limit before parsing properties.
4.1.133.Final or 4.2.13.Final
- Locate the Netty dependency configuration in the project's build file (e.g., pom.xml for Maven or build.gradle for Gradle).
- Update the Netty version to 4.1.133.Final if using 4.1.x, or to 4.2.13.Final if using 4.2.x.
- Verify the dependency update using the build tool (e.g., mvn dependency:tree or gradle dependencies).
- Compile and test the application to ensure compatibility with the updated Netty version.
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation2.0 h
- Implementation1.0 h
- Testing4.0 h
- Review / QA1.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,176.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-44248 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-44248 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data