eBA Plus CVE-2026-82969

Requires a low-privilege authenticated account on the eBA Plus Document and Workflow Management System (PR:L) able to submit data into a stored field (document, form, or workflow item) that is rendered without output neutralization. Exploitation is effectively limited by two factors the raw score omits: a separate victim must subsequently view the malicious stored content for the script to execute (real-world UI:R), and the attacker must first hold valid credentials, so this is not exploitable against an unauthenticated or default externally-anonymous configuration. Affected versions are from 6.7.141 up to but not including 10.0.11.

This is a moderate, authenticated stored XSS (CWE-79) in a regional enterprise document/workflow product. The provided CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4) indicates network reach and low attack complexity but requires privileges (PR:L), so an authenticated low-privilege account is needed to plant the payload - this is not an unauthenticated internet-facing flaw. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so exploitation status is 'no public exploit identified at time of analysis.' There is no SSVC decision data provided. The signals are internally consistent (network stored-XSS, partial C/I impact, no availability impact) and point to a real but not urgent issue; the main caveat is that the vendor rated UI:N and S:U, which understates typical stored-XSS behavior - a stored payload almost always fires when a separate victim (often a higher-privileged reviewer/admin in a workflow system) later views the record, which argues for UI:R and a scope change (S:C). Overall this is a genuine but lower-priority hardening item rather than a mass-exploitation threat, largely because it is authenticated and the product footprint is narrow.

An attacker with a low-privilege authenticated account in eBA Plus submits a document, form field, or workflow item containing a malicious script payload that is stored without proper neutralization. When a colleague or higher-privileged reviewer (e.g., a workflow approver or administrator) later opens that record, the script executes in their browser session, enabling session/token theft or actions performed as the victim. No public exploit code is identified in the provided data.