Summary
OpenCATS before 0.12.0 contains a stored cross-site scripting vulnerability in names and title fields for records such as candidates, companies, contacts, job orders, and lists. A low-privileged authenticated user may store HTML or JavaScript that executes when another user views the affected record through the Recent navigation panel, potentially compromising higher-privileged sessions.
OpenCATS before 0.12.0 contains a stored cross-site scripting vulnerability in names and title fields for records such as candidates, companies, contacts, job orders, and lists. A low-privileged authenticated user may store HTML or JavaScript that executes when another user views the affected record through the Recent navigation panel, potentially compromising higher-privileged sessions.
Affected context
The issue occurs in OpenCATS deployments where user-controlled record names or titles are saved without adequate output encoding and later rendered in the Recent or MRU navigation panel. The affected rendering path is associated with the getFormatted() function in lib/MRU.php, which may display stored values across many application pages. Risk depends on the ability of an authenticated user to create or modify records and on other users viewing pages that render the malicious value.
The issue occurs in OpenCATS deployments where user-controlled record names or titles are saved without adequate output encoding and later rendered in the Recent or MRU navigation panel. The affected rendering path is associated with the getFormatted() function in lib/MRU.php, which may display stored values across many application pages. Risk depends on the ability of an authenticated user to create or modify records and on other users viewing pages that render the malicious value.
Exploit preconditions
- Attack surface: Authenticated OpenCATS web interface and the Recent/MRU navigation panel
- Required access: A low-privileged authenticated account with permission to create or edit an affected record
- Trigger point: A page view that renders the stored record name or title in the MRU panel
- Why exploitation is possible: User-controlled content is stored without sufficient sanitization or context-appropriate output encoding and is later rendered as browser-interpreted markup
- Attack surface: Authenticated OpenCATS web interface and the Recent/MRU navigation panel
- Required access: A low-privileged authenticated account with permission to create or edit an affected record
- Trigger point: A page view that renders the stored record name or title in the MRU panel
- Why exploitation is possible: User-controlled content is stored without sufficient sanitization or context-appropriate output encoding and is later rendered as browser-interpreted markup
Why this happens
The vulnerability results from storing user-controlled names or titles and later inserting them into HTML without appropriate output encoding. When the application treats data as trusted markup rather than context-sensitive text, a stored script can execute in the browser security context of a user who views the affected interface. This behavior maps to CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), specifically a persistent or stored XSS pattern.
The vulnerability results from storing user-controlled names or titles and later inserting them into HTML without appropriate output encoding. When the application treats data as trusted markup rather than context-sensitive text, a stored script can execute in the browser security context of a user who views the affected interface. This behavior maps to CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), specifically a persistent or stored XSS pattern.
Potential impact
- An attacker may execute JavaScript in another user's browser session
- Session identifiers or accessible browser data could be exposed
- Administrative actions could be performed through a compromised user's session
- Privileges could be escalated if a Site Administrator views the affected content
- Application data may be modified, disclosed, or damaged
- An attacker may execute JavaScript in another user's browser session
- Session identifiers or accessible browser data could be exposed
- Administrative actions could be performed through a compromised user's session
- Privileges could be escalated if a Site Administrator views the affected content
- Application data may be modified, disclosed, or damaged
General mitigation guidance
Mitigation generally focuses on treating all record names and titles as untrusted data throughout their lifecycle.
Common defensive patterns include:
- Apply context-appropriate output encoding at every HTML rendering boundary
- Prefer safe text-rendering APIs and avoid inserting untrusted values as raw HTML
- Validate input against appropriate field-length and character policies without relying on validation as a substitute for encoding
- Use a restrictive Content Security Policy as defense in depth
- Limit permissions for users who can create or edit shared records
- Reduce administrative session exposure and apply least privilege to accounts and application roles
- Centralize escaping and output-safety helpers so rendering paths use consistent protections
Mitigation generally focuses on treating all record names and titles as untrusted data throughout their lifecycle.
Common defensive patterns include:
- Apply context-appropriate output encoding at every HTML rendering boundary
- Prefer safe text-rendering APIs and avoid inserting untrusted values as raw HTML
- Validate input against appropriate field-length and character policies without relying on validation as a substitute for encoding
- Use a restrictive Content Security Policy as defense in depth
- Limit permissions for users who can create or edit shared records
- Reduce administrative session exposure and apply least privilege to accounts and application roles
- Centralize escaping and output-safety helpers so rendering paths use consistent protections
How teams detect issues like this
Organizations can look for:
- Static analysis findings involving raw HTML interpolation, unescaped template output, or direct DOM and markup construction
- Code review signals where database values are rendered without context-specific encoding
- Tests that create records containing harmless markup-like text and verify that it is displayed as text rather than interpreted
- Runtime monitoring for unexpected script-related content in record-name or title fields
- Policy checks requiring output encoding at every web response boundary and restricting unsafe HTML rendering
- Automated application security testing that covers stored input displayed in shared navigation components
Organizations can look for:
- Static analysis findings involving raw HTML interpolation, unescaped template output, or direct DOM and markup construction
- Code review signals where database values are rendered without context-specific encoding
- Tests that create records containing harmless markup-like text and verify that it is displayed as text rather than interpreted
- Runtime monitoring for unexpected script-related content in record-name or title fields
- Policy checks requiring output encoding at every web response boundary and restricting unsafe HTML rendering
- Automated application security testing that covers stored input displayed in shared navigation components
