{"id":"CVE-2023-40583","aliases":["EUVD-2023-2291","GHSA-gcq9-qqwx-rgj3","GO-2023-2024"],"status":"published","title":"libp2p nodes vulnerable to OOM attack","description":"libp2p is a networking stack and library modularized out of The IPFS Project, and bundled separately for other tools to use. In go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash. If users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack i.e. the attacker could bring down nodes over a period of time (how long depends on the node resources i.e. a go-libp2p node on a virtual server with 4 gb of memory takes about 90 sec to bring down; on a larger server, it might take a bit longer.) This issue was patched in version 0.27.4.","severity":{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00952,"percentile":0.61767,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-400"],"published":"2023-08-24T22:22:59Z","modified":"2026-10-28T02:31:07Z","fixes":[{"ecosystem":"Go","package":"github.com/libp2p/go-libp2p","fixed_in":["0.27.4"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/libp2p/go-libp2p","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.27.3"},{"fixed":"0.27.4"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/libp2p/go-libp2p","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.27.4"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/libp2p/go-libp2p","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.27.4"}]}]}],"products":[{"vendor":"libp2p","product":"go-libp2p"},{"vendor":"protocol","product":"libp2p"}],"references":[{"url":"https://github.com/libp2p/go-libp2p/security/advisories/GHSA-gcq9-qqwx-rgj3","tags":["x_refsource_CONFIRM","x_transferred","Vendor Advisory","advisory","web"]},{"url":"https://github.com/libp2p/go-libp2p/commit/45d3c6fff662ddd6938982e7e9309ad5fa2ad8dd","tags":["x_refsource_MISC","x_transferred","Patch","fix","web"]},{"url":"https://github.com/libp2p/go-libp2p/releases/tag/v0.27.4","tags":["x_refsource_MISC","x_transferred","Release Notes","web"]},{"url":"https://github.com/libp2p/go-libp2p/releases/tag/v0.27.7","tags":["x_refsource_MISC","x_transferred","Release Notes","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-40583","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-gcq9-qqwx-rgj3"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/40xxx/CVE-2023-40583.json","tags":["advisory"]},{"url":"https://github.com/libp2p/go-libp2p","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2023-40583","title":"libp2p nodes vulnerable to OOM attack","description":"libp2p is a networking stack and library modularized out of The IPFS Project, and bundled separately for other tools to use. In go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash. If users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack i.e. the attacker could bring down nodes over a period of time (how long depends on the node resources i.e. a go-libp2p node on a virtual server with 4 gb of memory takes about 90 sec to bring down; on a larger server, it might take a bit longer.) This issue was patched in version 0.27.4.","status":"published","published":"2023-08-25T20:25:28.297Z","modified":"2024-10-02T14:45:16.702Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T14:35:21.971258Z"}],"euvd":[{"id":"EUVD-2023-2291","description":"libp2p is a networking stack and library modularized out of The IPFS Project, and bundled separately for other tools to use. In go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash. If users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack i.e. the attacker could bring down nodes over a period of time (how long depends on the node resources i.e. a go-libp2p node on a virtual server with 4 gb of memory takes about 90 sec to bring down; on a larger server, it might take a bit longer.) This issue was patched in version 0.27.4.","status":"published","published":"2023-08-25T20:25:28Z","modified":"2024-10-02T14:45:16Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-03T00:27:58.959241Z"}],"ghsa":[{"id":"GHSA-gcq9-qqwx-rgj3","title":"libp2p nodes vulnerable to OOM attack","description":"### Summary\nIn go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash.\n\nIt is feasible to do this at scale. An attacker would have to transfer ~1/2 as much memory it wants to occupy (2x amplification factor).\n\nThe attacker can perform this attack over time as the target node’s memory will not be garbage collected.\n\nThis can occur because when a signed peer record is received, only the signature validity check is performed but the sender signature is not checked. Signed peer records from randomly generated peers can be sent by a malicious actor. A target node will accept the peer record as long as the signature is valid, and then stored in the peer store.\n\nThere is cleanup logic in the peer store that cleans up data when a peer disconnects, but this cleanup is never triggered for the fake peer (from which signed peer records were accepted) because it was never “connected”.\n\n### Impact\nIf users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack i.e. the attacker could bring down nodes over a period of time (how long depends on the node resources i.e. a go-libp2p node on a virtual server with 4 gb of memory takes about 90 sec to bring down; on a larger server, it might take a bit longer.)\n\n### Patches\nUpdate your go-libp2p dependency to the latest release, v0.30.0 at the time of writing.\n\nIf you'd like to stay on the 0.27.x release, we strongly recommend users to update to go-libp2p [0.27.7](https://github.com/libp2p/go-libp2p/releases/tag/v0.27.7). Though this OOM issue was fixed in 0.27.4, there were subsequent patch releases afterwards (important fixes for other issues unrelated to the OOM).\n\n### Workarounds\nNone","status":"published","published":"2023-08-24T22:22:59Z","modified":"2023-11-05T05:01:40Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T14:37:13.301199Z"}],"nvd":[{"id":"CVE-2023-40583","description":"libp2p is a networking stack and library modularized out of The IPFS Project, and bundled separately for other tools to use. In go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash. If users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack i.e. the attacker could bring down nodes over a period of time (how long depends on the node resources i.e. a go-libp2p node on a virtual server with 4 gb of memory takes about 90 sec to bring down; on a larger server, it might take a bit longer.) This issue was patched in version 0.27.4.","status":"published","published":"2023-08-25T21:15:09Z","modified":"2026-06-17T06:18:34.563Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"secondary"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T14:08:25.025396Z"}],"osv":[{"id":"CVE-2023-40583","title":"libp2p nodes vulnerable to OOM attack","description":"libp2p is a networking stack and library modularized out of The IPFS Project, and bundled separately for other tools to use. In go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash. If users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack i.e. the attacker could bring down nodes over a period of time (how long depends on the node resources i.e. a go-libp2p node on a virtual server with 4 gb of memory takes about 90 sec to bring down; on a larger server, it might take a bit longer.) This issue was patched in version 0.27.4.","status":"published","published":"2023-08-25T20:25:28.297Z","modified":"2026-10-28T02:31:07.453775516Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T15:44:33.244128Z"},{"id":"GHSA-gcq9-qqwx-rgj3","title":"libp2p nodes vulnerable to OOM attack","description":"### Summary\nIn go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash.\n\nIt is feasible to do this at scale. An attacker would have to transfer ~1/2 as much memory it wants to occupy (2x amplification factor).\n\nThe attacker can perform this attack over time as the target node’s memory will not be garbage collected.\n\nThis can occur because when a signed peer record is received, only the signature validity check is performed but the sender signature is not checked. Signed peer records from randomly generated peers can be sent by a malicious actor. A target node will accept the peer record as long as the signature is valid, and then stored in the peer store.\n\nThere is cleanup logic in the peer store that cleans up data when a peer disconnects, but this cleanup is never triggered for the fake peer (from which signed peer records were accepted) because it was never “connected”.\n\n### Impact\nIf users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack i.e. the attacker could bring down nodes over a period of time (how long depends on the node resources i.e. a go-libp2p node on a virtual server with 4 gb of memory takes about 90 sec to bring down; on a larger server, it might take a bit longer.)\n\n### Patches\nUpdate your go-libp2p dependency to the latest release, v0.30.0 at the time of writing.\n\nIf you'd like to stay on the 0.27.x release, we strongly recommend users to update to go-libp2p [0.27.7](https://github.com/libp2p/go-libp2p/releases/tag/v0.27.7). Though this OOM issue was fixed in 0.27.4, there were subsequent patch releases afterwards (important fixes for other issues unrelated to the OOM).\n\n### Workarounds\nNone","status":"published","published":"2023-08-24T22:22:59Z","modified":"2023-11-17T22:07:30Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T15:46:47.822182Z"},{"id":"GO-2023-2024","title":"Out-of-memory vulnerability in github.com/libp2p/go-libp2p","description":"A malicious actor can store an arbitrary amount of data in the memory of a remote node by sending the node a message with a signed peer record. Signed peer records from randomly generated peers can be sent by a malicious actor. This memory does not get garbage collected and so the remote node can run out of memory (OOM).","status":"published","published":"2023-09-13T16:37:01Z","modified":"2024-05-20T16:03:47Z","updated_at":"2026-11-02T15:47:01.185262Z"}]}}