#xss

A Reflected Cross-site scripting (XSS) vulnerability located in htdocs/compta/paiement/card.php of Dolibarr before 19.0.2 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into the facid parameter.

Failing to sanitize content from unauthenticated website visitors, the form component is susceptible to Cross-Site Scripting.

Failing to sanitize content from editors, the legacy form component is susceptible to Cross-Site Scripting. A valid editor account with access to a form content element is required to exploit this vulnerability.

Failing to sanitize content from editors, the link validator component is susceptible to Cross-Site Scripting. A valid editor account with access to content which is scanned by the link validator component is required to exploit this vulnerability.

Failing to properly encode editor input, several frontend components are susceptible to Cross-Site Scripting, allowing authenticated editors to inject arbitrary HTML.

Fastly researchers discover unauthenticated stored XSS attacks plaguing WordPress Plugins including WP Meta SEO, and the popular WP…

Failing to properly encode editor input, the search result view of indexed_search is susceptible to Cross-Site Scripting, allowing authenticated editors to inject arbitrary HTML.

Failing to properly encode user input, several backend components are susceptible to Cross-Site Scripting, allowing authenticated editors to inject arbitrary HTML or JavaScript.

Sitefinity version 15.0 suffers from a persistent cross site scripting vulnerability.

### Impact Users settings their active admin form legends dynamically may be vulnerable to stored XSS, as long as its value can be injected directly by a malicious user. For example: * A public web application allows users to create entities with arbitrary names. * Active Admin is used to administrate these entities through a private backend. * The form to edit these entities in the private backend has the following shape (note the dynamic `name` value dependent on an attribute of the `resource`): ```ruby form do |f| f.inputs name: resource.name do f.input :name f.input :description end f.actions end ``` Then a malicious user could create an entity with a payload that would get executed in the active admin administrator's browser. Both `form` blocks with an implicit or explicit name (i.e., both `form resource.name` or `form name: resource.name` would suffer from the problem), where the value of the name can be arbitrarily set by non admin users. ### ...