Overview
In OpenAtlas 8.11.0, a name field allowed JavaScript to be stored persistently. The payload subsequently reappeared in the interface and could execute in another user’s browser when that record was edited or deleted.
Technical findings
Unlike reflected XSS, this payload remained stored in the application. The public CVE record identifies the name field; my original advisory documents its later execution during the delete workflow.
A single crafted record is sufficient. The attack does not need a new malicious link each time; it affects a subsequent user who opens the vulnerable workflow.
The root cause is missing or context-inappropriate output encoding for stored, user-controlled data.
Why it matters
An attacker stores a manipulated name. If another user—especially a privileged one—later opens the affected record or workflow, the code executes in the OpenAtlas origin.
Potential impact
- JavaScript execution within the application context in the victim’s browser.
- Depending on privileges, possible risks include account takeover, session theft, and data modification or deletion.
Remediation
- Upgrade to OpenAtlas 8.12.0 or later.
- Apply context-aware output encoding whenever user input is rendered; input validation alone is not a substitute.
- Do not interpret HTML in name or label fields unless the application genuinely requires it.
- Use CSP and safe template defaults as additional layers of protection.