Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Joomla Extension - icagenda.com - Authenticated Stored XSS in iCagenda 4.0.8 to 4.0.12 - The frontend "Submit an Event" form stores the `image` and `file` fields as raw strings with no output-side HTML-attribute escaping.Show less

The Kirki WordPress plugin before 6.2.3 does not properly validate the files contained in archives uploaded by users with the Editor role, and does not remove all unwanted files after extracting them, allowing such users to upload arbitrary files to a web accessible directory, leading to Stored XSS as well as RCE on some server configurations.Show less

The GutenKit WordPress plugin before 2.5.0 does not sanitise uploaded SVG files on all of the upload paths it enables, allowing users with the file upload capability, such as Author, to upload a malicious SVG and perform Stored Cross-Site Scripting attacks against any user opening it, including administrators.Show less

The Admin and Site Enhancements (ASE) WordPress plugin before 9.0.1 does not sanitise uploaded SVG files on every route it accepts them through, allowing users with a role the site owner granted upload access to store a file containing JavaScript which then executes in the browser of anyone who opens it.Show less

In Splunk SOAR versions below 8.6.0, a user who holds the "Incident Commander" Splunk SOAR role could store JavaScript in a note and run it in the browser of another user when that user opens the note. The stored Cross-Site Scripting (XSS) vulnerability is possible because Splunk SOAR can treat existing note content as Hypertext Markup Language (HTML) without sanitizing that content when the note format changes. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "Incident Commander" Splunk SOAR role should not be able to exploit the vulnerability at will. For more information see Manage roles and permissions in Splunk SOAR (Cloud) (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) in the Splunk documentation.Show less

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store a malicious script in dashboard sparkline format options and execute unauthorized JavaScript in the browser of another user who views the dashboard. If the other user holds the "admin" Splunk role, the script could access all relevant data available through Splunk Web and perform actions with that user's permissions. The vulnerability is possible because Splunk Web does not limit the permitted dashboard visualization options to safe presentation settings and does not escape tooltip values before rendering them. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access) in the Splunk documentation.Show less