Security
Headlines
HeadlinesLatestCVEs

Tag

#xss

GHSA-r85g-7jpv-8xrx: silverstripe/framework has Cross-site Scripting vulnerability in CMSSecurity BackURL

In follow up to [SS-2016-001](https://www.silverstripe.org/download/security-releases/ss-2016-001/) there is yet a minor unresolved fix to incorrectly encoded URL.

ghsa
#xss#vulnerability#git
GHSA-hhvj-mcrx-3vcf: silverstripe/framework has Cross-site Scripting vulnerability in page name

silverstripe/framework is vulnerable to XSS in Page name where the payload `"><svg/onload=alert(/xss/)>` will trigger an XSS alert.

GHSA-468j-6jrc-2rjx: silverstripe/framework vulnerable to Cross-site Scripting In `OptionsetField` and `CheckboxSetField`

List of key / value pairs assigned to `OptionsetField` or `CheckboxSetField` do not have a default casting assigned to them. The effect of this is a potential XSS vulnerability in lists where either key or value contain unescaped HTML.

GHSA-r9vp-fp72-xgf7: silverstripe/framework's `Member.Name` is not escaped

The core template `framework/templates/Includes/GridField_print.ss` uses "Printed by $Member.Name". If the currently logged in members first name or surname contain XSS, this prints the raw HTML out, because Member->getName() just returns the raw FirstName + Surname as a string, which is injected directly.

GHSA-frm9-7pm9-5rgc: SilverStripe comments module includes version of jQuery vulnerable to Cross-site Scripting

The silverstripe/comments module, the cwp/starter-theme and the cwp/watea-theme include an outdated version of jQuery by default, which contains XSS vulnerabilities if user input is used in certain contexts. Though no known exploit has been found for these in the existing usage, user customisation to these themes could have made them exploitable. CWP 2.0.0 has been released with the fixed cwp/stater-theme and silverstripe/comments module, and SilverStripe 4.2.0 will be released with the fixed silverstripe-themes/simple theme.

Debian Security Advisory 5699-1

Debian Linux Security Advisory 5699-1 - Multiple cross-site scripting vulnerabilities were found in Redmine, a project management web application.

GHSA-rq7f-j68f-mqh3: PHP Server Monitor vulnerable to Cross-site Scripting

PHP Server Monitor, version 3.2.0, is vulnerable to an XSS via the /phpservermon-3.2.0/vendor/phpmailer/phpmailer/test_script/index.php page in all visible parameters. An attacker could create a specially crafted URL, send it to a victim and retrieve their session details.

Jcow Social Network Cross Site Scripting

Jcow Social Networking versions 14.2 up to 16.2.1 suffer from a persistent cross site scripting vulnerability.

GHSA-2qjp-fg8c-g878: vxe-table Cross-site Scripting vulnerability

A vulnerability, which was classified as problematic, has been found in xuliangzhan vxe-table up to 3.7.9. This issue affects the function export of the file packages/textarea/src/textarea.js of the component vxe-textarea. The manipulation of the argument inputValue leads to cross site scripting. The attack may be initiated remotely. Upgrading to version 3.7.10 is able to address this issue. The patch is named d70b0e089740b65a22c89c106ebc4627ac48a22d. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-266123.

GHSA-97jm-g33h-f46g: silverstripe/framework ReadOnly transformation for formfields exploitable

Form fields returning isReadonly() as true are vulnerable to reflected XSS injections. This includes ReadonlyField, LookupField, HTMLReadonlyField, as well as special purpose fields like TimeField_Readonly. Values submitted to through these form fields are not filtered out from the form session data, and might be shown to the user depending on the form behaviour. For example, form validation errors cause the form to re-render with previously submitted values by default. SilverStripe forms automatically load values from request data (GET and POST), which enables malicious use of URLs if your form uses these fields and doesn't overwrite data on form construction. Readonly and disabled form fields are already filtered out in Form->saveInto(), so maliciously submitted data on these fields doesn't make it into the database unless you are accessing form values directly in your saving logic.