What is GHSA-v74w-7mr3-4qg3?

### Summary An attacker can cause Denial of Service by sending a specially crafted malicious XML payload (e.g., repeated ` `. Because the parser state is not saved between `decode()` invocations, an attacker can trickle-feed a payload of `<

How severe is GHSA-v74w-7mr3-4qg3?

GHSA-v74w-7mr3-4qg3 has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-v74w-7mr3-4qg3?

GHSA-v74w-7mr3-4qg3 affects the following packages: io.netty:netty-codec-xml (Maven), io.netty:netty-codec-xml (Maven). Ecosystems affected: Maven.

How do I fix GHSA-v74w-7mr3-4qg3?

Update io.netty:netty-codec-xml to 4.2.16.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v74w-7mr3-4qg3 is resolved across your whole dependency graph.

How do I detect GHSA-v74w-7mr3-4qg3 in my Maven dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-codec-xml. 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-v74w-7mr3-4qg3 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-v74w-7mr3-4qg3?

O3 pinpoints whether GHSA-v74w-7mr3-4qg3 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-v74w-7mr3-4qg3 actively exploited in the wild?

No public exploit code has been indexed for GHSA-v74w-7mr3-4qg3 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-v74w-7mr3-4qg3 published, and has it been updated?

GHSA-v74w-7mr3-4qg3 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-v74w-7mr3-4qg3

HIGH

Netty: Denial of Service in XmlFrameDecoder via CPU Exhaustion

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-xml☕io.netty:netty-codec-xml

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

An attacker can cause Denial of Service by sending a specially crafted malicious XML payload (e.g., repeated </ characters) to a Netty server utilizing XmlFrameDecoder, causing the server's EventLoop thread to exhaust CPU resources and become unresponsive.

Details

io.netty.handler.codec.xml.XmlFrameDecoder suffers from a vulnerability resulting in CPU exhaustion. When < followed by / is encountered, the decoder scans the remaining buffer for a closing >. Because the parser state is not saved between decode() invocations, an attacker can trickle-feed a payload of </ characters. This forces the decoder to repeatedly rescan the entire accumulated buffer. A 1MB maxFrameLength is enough to completely hang a server's thread while it loops endlessly.

Impact

Denial of Service via CPU Exhaustion. Any application utilizing Netty's XmlFrameDecoder is impacted. An unauthenticated remote attacker can exploit this flaw by sending a modest amount of malformed XML data to an exposed port.

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
☕Maven	`io.netty:netty-codec-xml`	≥ 4.2.0.Final&&< 4.2.16.Final	4.2.16.Final
☕Maven	`io.netty:netty-codec-xml`	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-xml. 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-xml to 4.2.16.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v74w-7mr3-4qg3 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-v74w-7mr3-4qg3 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-v74w-7mr3-4qg3. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary An attacker can cause Denial of Service by sending a specially crafted malicious XML payload (e.g., repeated `</` characters) to a Netty server utilizing XmlFrameDecoder, causing the server's EventLoop thread to exhaust CPU resources and become unresponsive. ### Details `io.netty.handler.codec.xml.XmlFrameDecoder` suffers from a vulnerability resulting in CPU exhaustion. When `<` followed by `/` is encountered, the decoder scans the remaining buffer for a closing `>`. Because the parser state is not saved between `decode()` invocations, an attacker can trickle-feed a payload of `<

O3 Security · Impact-Aware SCA

Is GHSA-v74w-7mr3-4qg3 in your dependencies?

O3 detects GHSA-v74w-7mr3-4qg3 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