Aureus ERP EUVD-2026-82606

Requires an authenticated account with the payment-term create permission (create_account_payment::term) able to POST to the payment-terms/store endpoint of the Accounting (webkul/accounts) plugin - so it is not exploitable by anonymous or unprivileged users. The malicious note only fires when another user opens the affected Payment Term infolist view (UI:P/required interaction by a victim), because PaymentTermInfolist.php wraps the note in new HtmlString($state) without sanitization. Applies to Aureus ERP through 1.6.0 with the Accounting plugin enabled; limiting factors are the required create privilege and the need for a victim to view the specific record.

This is a genuine but low-to-moderate priority stored XSS. The vendor CVSS 4.0 base score is 5.1 (Medium), consistent with the vector AV:N/AC:L/AT:N/PR:L/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N: network-reachable and low-complexity, but gated by PR:L (the attacker needs an authenticated account holding payment-term create permission) and UI:P (a victim must view the poisoned Payment Term record). Impact is limited to Low confidentiality/integrity on both the vulnerable and a subsequent system (the victim's browser session), with no availability impact. No EPSS score was provided, the CVE is not in CISA KEV, and there is no vendor claim of active exploitation, so this is not confirmed actively exploited. A public technical write-up with the payload exists (hackmd.io/@leediay), so treat it as publicly available exploit code. The realistic risk is a privileged-insider or compromised-low-privilege-account scenario escalating within the app (session/action theft against other users, including admins, who open the record) rather than mass or unauthenticated exploitation. Net: patch in normal cadence; it is not a drop-everything emergency, and the raw 'network vector' should not be read as unauthenticated internet-wide risk given PR:L and UI:P.

An authenticated user with payment-term create permission submits a Payment Term whose note field contains '<p>Pay in 30 days</p><script>...</script>'; the unsanitized note is persisted and later rendered as raw HTML via HtmlString in PaymentTermInfolist. When any other user - potentially an accounting admin - opens that Payment Term record, the injected JavaScript executes in their authenticated session. A public write-up demonstrating the payload exists, so a working PoC is available.