How severe is GHSA-mfg7-5gfp-c4w3?

GHSA-mfg7-5gfp-c4w3 has a CVSS score of 5.3/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-mfg7-5gfp-c4w3?

GHSA-mfg7-5gfp-c4w3 affects the following packages: io.netty:netty-codec-dns (Maven), io.netty:netty-codec-dns (Maven). Ecosystems affected: Maven.

How do I fix GHSA-mfg7-5gfp-c4w3?

Update io.netty:netty-codec-dns to 4.2.16.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mfg7-5gfp-c4w3 is resolved across your whole dependency graph.

How do I detect GHSA-mfg7-5gfp-c4w3 in my Maven dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-codec-dns. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-mfg7-5gfp-c4w3 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-mfg7-5gfp-c4w3?

O3 pinpoints whether GHSA-mfg7-5gfp-c4w3 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-mfg7-5gfp-c4w3 actively exploited in the wild?

No public exploit code has been indexed for GHSA-mfg7-5gfp-c4w3 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-mfg7-5gfp-c4w3 published, and has it been updated?

GHSA-mfg7-5gfp-c4w3 was published on July 24, 2026 and was last updated on July 24, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

☕ Maven

GHSA-mfg7-5gfp-c4w3

MEDIUM

Netty: Memory Leak in DNS Record Decoder via Malformed Domain Names

Published

Jul 24, 2026

Updated

Jul 24, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

Blast Radius

2 pkgs affected

☕io.netty:netty-codec-dns☕io.netty:netty-codec-dns

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

Summary

A memory leak can be caused in Netty's DNS codec by sending malicious DNS packets containing invalid domain names. Because the leak occurs incrementally per packet, sustained malicious requests will cause a gradual Denial of Service.

Details

Inside io.netty.handler.codec.dns.AbstractDnsRecord, the parsed domain name string is passed to IDN.toASCII(name). If the domain name contains characters that violate IDNA rules, IDN.toASCII throws an IllegalArgumentException.

Because this exception occurs inside the constructor before the DnsRecord instance can assign the buffer to its content field for later release, the ByteBuf whose reference count was incremented (or newly allocated) is never released, resulting in a direct memory leak.

There are several places where variants of this leak happen:

io.netty.handler.codec.dns.DefaultDnsRecordDecoder#decodeRecord(java.lang.String, io.netty.handler.codec.dns.DnsRecordType, int, long, io.netty.buffer.ByteBuf, int, int) invokes in.retainedDuplicate() or creates a new buffer out when constructing DefaultDnsRawRecord
io.netty.handler.codec.dns.DnsCodecUtil#decompressDomainName allocates a new ByteBuf and passes it to encodeDomainName(). If the decompressed domain name contains a null byte (\0), encodeDomainName() throws an IllegalArgumentException, leaking the newly allocated buffer.

Impact

Resource Exhaustion. Any application utilizing Netty's DnsRecordDecoder (such as DnsNameResolver or custom DNS servers) is vulnerable.

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
☕Maven	`io.netty:netty-codec-dns`	≥ 4.2.0.Final&&< 4.2.16.Final	4.2.16.Final
☕Maven	`io.netty:netty-codec-dns`	all versions	4.1.136.Final

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-codec-dns. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update io.netty:netty-codec-dns to 4.2.16.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mfg7-5gfp-c4w3 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-mfg7-5gfp-c4w3 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-mfg7-5gfp-c4w3. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary A memory leak can be caused in Netty's DNS codec by sending malicious DNS packets containing invalid domain names. Because the leak occurs incrementally per packet, sustained malicious requests will cause a gradual Denial of Service. ### Details Inside `io.netty.handler.codec.dns.AbstractDnsRecord`, the parsed domain name string is passed to `IDN.toASCII(name)`. If the domain name contains characters that violate IDNA rules, `IDN.toASCII` throws an `IllegalArgumentException`. Because this exception occurs inside the constructor before the `DnsRecord` instance can assign the buffe

O3 Security · Impact-Aware SCA

Is GHSA-mfg7-5gfp-c4w3 in your dependencies?

O3 detects GHSA-mfg7-5gfp-c4w3 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works