Ilevia EVE X1 Server firmware versions ≤ 4.7.18.0.eden contain an OS command injection vulnerability in mbus_build_from_csv.php that allows an unauthenticated attacker to execute arbitrary code. Ilevia has declined to service this vulnerability, and recommends that customers not expose port 8080 to the internet.
Ilevia EVE X1 Server firmware versions ≤ 4.7.18.0.eden contain authenticated OS command injection vulnerabilities in multiple web-accessible PHP scripts that call exec() and allow an authenticated attacker to execute arbitrary commands. Ilevia has declined to service this vulnerability, and recommends that customers not expose port 8080 to the internet.
Ilevia EVE X1 Server firmware versions ≤ 4.7.18.0.eden contain an execution with unnecessary privileges vulnerability in sync_project.sh that allows an attacker to escalate privileges to root. Ilevia has declined to service this vulnerability, and recommends that customers not expose port 8080 to the internet.
IBM MQ 9.1, 9.2, 9.3, 9.4 LTS and 9.3, 9.4 CD is vulnerable to a denial of service, caused by improper enforcement of the timeout on individual read operations. By conducting slowloris-type attacks, a remote attacker could exploit this vulnerability to cause a denial of service.
An integer overflow vulnerability exists in the QuickJS regular expression engine (libregexp) due to an inconsistent representation of the bytecode buffer size.
* The regular expression bytecode is stored in a DynBuf structure, which correctly uses a $\text{size}\_\text{t}$ (an unsigned type, typically 64-bit) for its size member.
* However, several functions, such as re_emit_op_u32 and other internal parsing routines, incorrectly cast or store this DynBuf $\text{size}\_\text{t}$ value into a signed int (typically 32-bit).
* When a large or complex regular expression (such as those generated by a recursive pattern in a Proof-of-Concept) causes the bytecode size to exceed $2^{31}$ bytes (the maximum positive value for a signed 32-bit integer), the size value wraps around, resulting in a negative integer when stored in the int variable (Integer Overflow).
* This negative value is subsequently used in offset calculations. For example, within functions like re_parse_disjunction, the negative size is used to compute an offset (pos) for patching a jump instruction.
* This negative offset is then incorrectly added to the buffer pointer (s->byte\_code.buf + pos), leading to an out-of-bounds write on the first line of the snippet below:
put_u32(s->byte_code.buf + pos, len);
A vulnerability exists in the QuickJS engine's BigInt string parsing logic (js_bigint_from_string) when attempting to create a BigInt from a string with an excessively large number of digits.
The function calculates the necessary number of bits (n_bits) required to store the BigInt using the formula:
$$\text{n\_bits} = (\text{n\_digits} \times 27 + 7) / 8 \quad (\text{for radix 10})$$
* For large input strings (e.g., $79,536,432$ digits or more for base 10), the intermediate calculation $(\text{n\_digits} \times 27 + 7)$ exceeds the maximum value of a standard signed 32-bit integer, resulting in an Integer Overflow.
* The resulting n_bits value becomes unexpectedly small or even negative due to this wrap-around.
* This flawed n_bits is then used to compute n_limbs, the number of memory "limbs" needed for the BigInt object. Since n_bits is too small, the calculated n_limbs is also significantly underestimated.
* The function proceeds to allocate a JSBigInt object using this underestimated n_limbs.
* When the function later attempts to write the actual BigInt data into the allocated object, the small buffer size is quickly exceeded, leading to a Heap Out-of-Bounds Write as data is written past the end of the allocated r->tab array.
Pega Platform versions 8.7.5 to Infinity 24.2.2 are affected by a Insecure Direct Object Reference issue in a user interface component that can only be used to read data.
In quickjs, in js_print_object, when printing an array, the function first fetches the array length and then loops over it. The issue is, printing a value is not side-effect free. An attacker-defined callback could run during js_print_value, during which the array could get resized and len1 become out of bounds. This results in a use-after-free.A second instance occurs in the same function during printing of a map or set objects. The code iterates over ms->records list, but once again, elements could be removed from the list during js_print_value call.
A Use-After-Free (UAF) vulnerability exists in the QuickJS engine's standard library when iterating over the global list of unhandled rejected promises (ts->rejected_promise_list).
* The function js_std_promise_rejection_check attempts to iterate over the rejected_promise_list to report unhandled rejections using a standard list loop.
* The reason for a promise rejection is processed inside the loop, including calling js_std_dump_error1(ctx, rp->reason).
* If the promise rejection reason is an Error object that defines a custom property getter (e.g., via Object.defineProperty), this getter is executed during the error dumping process.
* The malicious custom getter can execute JavaScript code that calls catch() on the same rejected promise being processed.
* Calling catch() internally triggers js_std_promise_rejection_tracker, which then removes and frees the current promise entry (JSRejectedPromiseEntry) from the rejected_promise_list.
* Since the list iteration continues using the now-freed memory pointer (el), the subsequent loop access results in a Use-After-Free condition.
A vulnerability stemming from floating-point arithmetic precision errors exists in the QuickJS engine's implementation of TypedArray.prototype.indexOf() when a negative fromIndex argument is supplied.
* The fromIndex argument (read as a double variable, $d$) is used to calculate the starting position for the search.
* If d is negative, the index is calculated relative to the end of the array by adding the array's length (len) to d:
$$d_{new} = d + \text{len}$$
* Due to the inherent limitations of floating-point arithmetic, if the negative value $d$ is extremely small (e.g., $-1 \times 10^{-20}$), the addition $d + \text{len}$ can result in a loss of precision, yielding an outcome that is exactly equal to $\text{len}$.
* The result is then converted to an integer index $k$: $k = \text{len}$.
* The search function proceeds to read array elements starting from index $k$. Since valid indices are $0$ to $\text{len}-1$, starting the read at index $\text{len}$ is one element past the end of the array.
This allows an attacker to cause an Out-of-Bounds Read of one element immediately following the buffer. While the scope of this read is small (one element), it can potentially lead to Information Disclosure of adjacent memory contents, depending on the execution environment.