Headline
CVE-2023-48226: HTML Injection - real OpenReplay emails
OpenReplay is a self-hosted session replay suite. In version 1.14.0, due to lack of validation Name field - Account Settings (for registration looks like validation is correct), a bad actor can send emails with HTML injected code to the victims. Bad actors can use this to phishing actions for example. Email is really send from OpenReplay, but bad actors can add there HTML code injected (content spoofing). Please notice that during Registration steps for FullName looks like is validated correct - can not type there, but using this kind of bypass/workaround - bad actors can achieve own goal. As of time of publication, no known fixes or workarounds are available.
Summary
Due to lack of validation Name field - Account Settings (for registration looks like validation is correct), bad actor can send emails with HTML injected code to the victims.
Details
Occurrences
https://github.com/openreplay/openreplay/blob/main/api/chalicelib/utils/html/invitation.html#L421
PoC
Payload example: Ja<a href="www.evilsite.com">mees
Repro steps:
- As logged in user go to https://app.openreplay.com/client/account and for field ‘Name’ use payload with HTML (so change your name/update - with payload).
- Now go to your Project (https://app.openreplay.com/[number]/onboarding/installing) and Invite user (here - victim; “Invite and Collaborate”).
- Open email from OpenReplay ([email protected]) titled 'Welcome to OpenReplay’, see valid payload. Hover by mouse - see injected link. “You have been invited by Jamees to join [TEAM-NAME] team on OpenReplay.” , from part of message contains Name (here “Jamees”) - contains payload to the end of sentence.
Result - screenshot:
For Repro steps please use own emails, but please notice that bad actors can make this with victims email addresses (which not own).
Impact
Bad actors can use this to phishing actions for example. Email is really send from OpenReplay, but bad actors can add there HTML code injected (content spoofing). Please notice that during Registration steps for FullName looks like is validated correct - can not type there, but using this kind of bypass/workaround - bad actors can achieve own goal.
Proposed remediation: Sanitize/purify mentioned input data from users - don’t allow to this.
Additional information:
Server-Side Injection - Content Spoofing - Email HTML Injection - https://bugcrowd.com/vulnerability-rating-taxonomy
References
CAPEC-242: Code Injection - https://capec.mitre.org/data/definitions/242.html
Bugcrowd - vulnerability-rating-taxonomy - https://bugcrowd.com/vulnerability-rating-taxonomy
CWE-20: Improper Input Validation - https://cwe.mitre.org/data/definitions/20.html
Best regards,