Base de CVEs

MISP contains an insecure direct object reference vulnerability in the processModuleResultsData method of the Event model. When processing module results, the code iterates over EventReport entries supplied in the resolved data and saves each one. Unlike the adjacent attribute and object processing loops, the report loop did not unset the client-supplied 'id' field before calling save(). Because the MISP EventReport model's create() method does not strip the id field, an authenticated user with permission to submit module results could include an 'id' value referencing an existing report belonging to a different event. Upon save(), the ORM would update that existing row rather than insert a new one, allowing the attacker to   - read the content of another event's report by reparenting it into their own event  - overwrite the report's fields with attacker-controlled data  - change the report's event_id to redirect ownership.  This constitutes an authorization bypass through a user-controlled key, enabling cross-event data disclosure and integrity compromise. The vulnerability requires an authenticated session with the ability to invoke module result processing on an event. Version affected: <2.5.47

Joomla Extension - j2commerce.com - Any order can be marked Failed by anyone in J2Store 1.0.0-3.3.2, 4.0.0-4.0.22, 4.1.0-4.1.7 - Unauthenticated denial-of-service against the order pipeline: mass-failing pending orders to disrupt revenue and force manual reprocessing, or flipping already-fulfilled orders back to `FAILED` to cause operational confusion (unwarranted refunds/cancellations, customer-support load). Unlike the earlier confirmation-fraud issue, this required no correct payment amount or transaction data at all.

Joomla Extension - j2commerce.com - Unauthenticated PayPal callback forgery leading to order confirmation fraud in J2Store 1.0.0-3.3.21, 4.0.0-4.0.21, 4.1.0-4.1.6 - The PayPal IPN listener's signature check (`_validateIPN()`) accepted `UNVERIFIED` and any non-`INVALID` response as valid, made its verification request with `CURLOPT_SSL_VERIFYPEER` disabled, and stored its verdict in a field nothing downstream ever checked — so processing continued regardless of the outcome. Separately, the paid-amount comparison only ran when `mc_gross` was a positive number; omitting the field from the POST body (`floatval(null) == 0`) skipped the check entirely. Combined with a merchant-configured `receiver_email` and a sequential, enumerable order id read from the `custom` field, an anonymous POST was enough to move a pending order straight to `CONFIRMED` with no payment, or force another customer's pending order to `FAILED`. `paypalv2.php` performed no amount check under any circumstances.

Joomla Extension - balbooa.com - Pre-auth Payment Amount Tampering in Balbooa Forms < 2.4.3.2 - The stripeCharges and payAuthorize endpoints accept the charge total from a client-controlled request parameter and forward it to the payment gateway without recomputing it from the form's configured product prices. Neither endpoint enforces authentication or CSRF checks. An unauthenticated attacker can purchase any priced item for an arbitrary amount (e.g., $0.01), and can additionally forge line items, quantities, and shipping.

The WPC Name Your Price for WooCommerce WordPress plugin before 2.2.5 does not enforce its server-side price allowlist for products configured in "Select" price mode, allowing an unauthenticated visitor to add such a product to the cart at an arbitrary value below the merchant-defined allowed prices and commit a real order at that price (revenue loss / underpriced orders). This is a distinct, unfixed vector from CVE-2025-12115, whose 2.2.0 fix only addressed applying a custom price to products where Name Your Price is disabled and left the Select-mode allowlist unenforced through 2.2.4.

The CoCart WordPress plugin before 4.9.0 does not validate a user-supplied price value against the actual product price when items are added to the cart through one of its public REST API endpoints, allowing unauthenticated users to set arbitrary product prices and complete WooCommerce orders at manipulated totals.

Ninja Forms WordPress plugin version 3.14.8 and prior contains an improper input validation vulnerability that allows unauthenticated attackers to inject arbitrary numeric values into form calculations and payment totals by submitting values that do not match any configured option in ListSelect or ListRadio fields. Attackers can tamper with form submission payloads to the ajax submit endpoint, causing the get_calc_value() method to fail open and return attacker-controlled values, enabling manipulation of payment amounts to zero or arbitrary figures and bypassing admin-configured pricing logic.