| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Codoforum 4.8.3 allows XSS in the admin dashboard via a name field of a new user, i.e., on the Manage Users screen. |
| In OctoberCMS (october/october composer package) versions from 1.0.319 and before 1.0.466, a user with the ability to use the import functionality of the `ImportExportController` behavior can be socially engineered by an attacker to upload a maliciously crafted CSV file which could result in a reflected XSS attack on the user in question Issue has been patched in Build 466 (v1.0.466). |
| PrestaShop module ps_facetedsearch versions before 2.1.0 has a reflected XSS with social networks fields The problem is fixed in 2.1.0 |
| In PrestaShop between versions 1.7.4.0 and 1.7.6.5, there is a reflected XSS when uploading a wrong file. The problem is fixed in 1.7.6.5 |
| In PrestaShop between versions 1.7.6.0 and 1.7.6.5, there is a reflected XSS with `back` parameter. The problem is fixed in 1.7.6.5 |
| ViewVC before versions 1.1.28 and 1.2.1 has a XSS vulnerability in CVS show_subdir_lastmod support. The impact of this vulnerability is mitigated by the need for an attacker to have commit privileges to a CVS repository exposed by an otherwise trusted ViewVC instance that also has the `show_subdir_lastmod` feature enabled. The attack vector involves files with unsafe names (names that, when embedded into an HTML stream, would cause the browser to run unwanted code), which themselves can be challenging to create. This vulnerability is patched in versions 1.2.1 and 1.1.28. |
| In PrestaShop between versions 1.5.4.0 and 1.7.6.5, there is a reflected XSS on Exception page The problem is fixed in 1.7.6.5 |
| PrestaShop module ps_facetedsearch versions before 3.5.0 has a reflected XSS with `url_name` parameter. The problem is fixed in 3.5.0 |
| In PrestaShop between versions 1.7.1.0 and 1.7.6.5, there is a reflected XSS on AdminCarts page with `cartBox` parameter The problem is fixed in 1.7.6.5 |
| In PrestaShop module ps_linklist versions before 3.1.0, there is a stored XSS when using custom URLs. The problem is fixed in version 3.1.0 |
| In PrestaShop between versions 1.5.5.0 and 1.7.6.5, there is a reflected XSS on Search page with `alias` and `search` parameters. The problem is patched in 1.7.6.5 |
| In PrestaShop between versions 1.6.0.0 and 1.7.6.5, there is a reflected XSS with `date_from` and `date_to` parameters in the dashboard page This problem is fixed in 1.7.6.5 |
| In PrestaShop between versions 1.7.6.1 and 1.7.6.5, there is a reflected XSS on AdminFeatures page by using the `id_feature` parameter. The problem is fixed in 1.7.6.5 |
| In ActionView before versions 6.0.2.2 and 5.2.4.2, there is a possible XSS vulnerability in ActionView's JavaScript literal escape helpers. Views that use the `j` or `escape_javascript` methods may be susceptible to XSS attacks. The issue is fixed in versions 6.0.2.2 and 5.2.4.2. |
| In the ps_link module for PrestaShop before version 3.1.0, there is a stored XSS when you create or edit a link list block with the title field. The problem is fixed in 3.1.0 |
| In PrestaShop between versions 1.7.6.1 and 1.7.6.5, there is a reflected XSS on AdminAttributesGroups page. The problem is patched in 1.7.6.5. |
| In PrestaShop before version 1.7.6.5, there is a reflected XSS while running the security compromised page. It allows anyone to execute arbitrary action. The problem is patched in the 1.7.6.5. |
| In Puma (RubyGem) before 4.3.3 and 3.12.4, if an application using Puma allows untrusted input in an early-hints header, an attacker can use a carriage return character to end the header and inject malicious content, such as additional headers or an entirely new response body. This vulnerability is known as HTTP Response Splitting. While not an attack in itself, response splitting is a vector for several other attacks, such as cross-site scripting (XSS). This is related to CVE-2020-5247, which fixed this vulnerability but only for regular responses. This has been fixed in 4.3.3 and 3.12.4. |
| GLPI before before version 9.4.6 has a vulnerability involving a default encryption key. GLPIKEY is public and is used on every instance. This means anyone can decrypt sensitive data stored using this key. It is possible to change the key before installing GLPI. But on existing instances, data must be reencrypted with the new key. Problem is we can not know which columns or rows in the database are using that; espcially from plugins. Changing the key without updating data would lend in bad password sent from glpi; but storing them again from the UI will work. |
| matestack-ui-core (RubyGem) before 0.7.4 is vulnerable to XSS/Script injection. This vulnerability is patched in version 0.7.4. |
