A SQL injection vulnerability exists in PHP Dashboards NEW 5.8, which allows an attacker to execute arbitrary SQL commands via the dashID parameter in the savedescriptions.php file.
MoneyFlux - Cashflow Management System 1.0 is vulnerable to SQL injection. An attacker can inject malicious SQL queries via the 'id' parameter in the 'framework-crud-updateaction' script. This can be exploited to read, modify or delete data from the database.
An attacker can inject malicious SQL queries into the 'id' parameter of the 'framework-crud-detailaction' script. This can be exploited to read, modify or delete data from the database.
Coman - Company Management System 1.0 is prone to a SQL injection vulnerability because it fails to sufficiently sanitize user-supplied data before using it in an SQL query. An attacker can exploit this vulnerability to manipulate the queries that are executed in the backend database, allowing the attacker to bypass authentication, access, modify and delete data within the database.
This exploit is related to a vulnerability in the Linux kernel which allows an attacker to leak the kernel stack offset. This vulnerability is caused by a lack of proper validation of user-supplied input when setting the timex structure in the adjtimex() system call. By setting the timex.modes field to 0x8000, an attacker can cause the kernel to leak the kernel stack offset in the timex.tai field. This can be used to calculate the kernel base address, which can then be used to gain arbitrary code execution in the kernel.
Kepler Wallpaper Script 1.1 is vulnerable to SQL Injection. An attacker can send a malicious HTTP request containing a crafted SQL statement to the vulnerable application. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code. This can be used to bypass authentication, access, modify and delete data within the database.
The JsBuiltInEngineInterfaceExtensionObject::InjectJsBuiltInLibraryCode method is used to execute JsBuiltIn.js which initializes some builtin objects. Because it's essentially written in JavaScript, it needs to clear the disable-implicit-call flag before calling the JavaScript code, otherwise it might not work properly. The problem is, it doesn't restore the prevous status of the flag after the call. As setting the flag can prevent stack-allocated objects from leaking, this clearing-the-flag bug can lead to a stack-based use-after-free. To exploit this bug, it's needed to build a chain that first clears the flag by calling the vulnerable method and then leaks the stack-allocated object. This is done with the Error.prototype.toString method (marked as having no side effects) which calls the "toString" method on the "name" property and the "message" property of the "this" object.
This exploit uses an InitClass instruction to reach the SetIsPrototype method. It creates an object with two properties, a and b, and passes it to the opt function. The opt function creates a class A that extends the c parameter, and sets the o.a property to the value parameter. After 2000 iterations, the o object is passed to the opt function again, this time with a cons parameter that has its prototype set to o. The o.a property is then set to 0x1234.
NewScObjectNoCtor and InitProto opcodes are treated as having no side effects, but actually they can have via the SetIsPrototype method of the type handler that can cause transition to a new type. This can lead to type confusion in the JITed code. In the PoC, it overwrites the pointer to property slots with 0x1000000001234.
In Chakra, if a numeric property is added to an object having inlined properties, it will start transition to a new type where the space for some of previously inlined properties become for the pointer to the property slots and the pointer to the object array which stores numeric properties. For this reason, when it optimizes an InlineArrayPush instruction which might start transition, it needs to kill corresponding type symbols to prevent type confusion. But it doesn't, so it can lead to type confusion.
Services By CQR