Silverstripe: XSS in breadcrumbs in page list view
Page breadcrumbs in the CMS are vulnerable to XSS when viewed using the page list view
Page breadcrumbs in the CMS are vulnerable to XSS when viewed using the page list view
A cross-site scripting vulnerability has been discovered in the VirtualPage class. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any of the textfields of a page which a VirtualPage refers to. This has been resolved by ensuring that VirtualPage safely escapes all field content.
A vulnerability exists in the permission validation for SiteTree object creation. By default user permissions are not validated by the SiteTree::canCreate method, unless overridden by user code or via the configuration system. This vulnerability will allow users, or unauthenticated guests, to create new SiteTree objects in the database. This vulnerability is present when such users are given CMS access via other means, or if there is another mechanism (such as …
A cross-site scripting vulnerability has been discovered in the CMS page history tab. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any of the text fields on a page, and if the "compare mode" option is selected. The HTML will be embedded into the page unescaped. This has been resolved by performing the text comparison in a HTML friendly …
A malicious content author could create a custom meta tag and execute an arbitrary JavaScript payload. This would require convincing a legitimate user to access a page and enter a custom keyboard shortcut. This requires CMS access to exploit.
Silverstripe CMS through 4.5 can be susceptible to script execution from malicious upload contents under allowed file extensions (for example HTML code in a TXT file). When these files are stored as protected or draft files, the MIME detection can cause browsers to execute the file contents. Uploads stored as protected or draft files are allowed by default for authorised users only, but can also be enabled through custom logic …
In SilverStripe through 4.5.0, a specific URL path configured by default through the silverstripe/framework module can be used to disclose the fact that a domain is hosting a Silverstripe application. There is no disclosure of the specific version. The functionality on this URL path is limited to execution in a CLI context, and is not known to present a vulnerability through web-based access. As a side-effect, this preconfigured path also …
In SilverStripe through 4.5, malicious users with a valid Silverstripe CMS login (usually CMS access) can craft profile information which can lead to XSS for other users through specially crafted login form URLs.
SilverStripe CMS before 3.6.1 has XSS via an SVG document that is mishandled by (1) the Insert Media option in the content editor or (2) an admin/assets/add pathname, as demonstrated by the admin/pages/edit/EditorToolbar/MediaForm/field/AssetUploadField/upload URI, aka issue SS-2017-017.
code/sitefeatures/PageCommentInterface.php in SilverStripe 2.4.x before 2.4.6 might allow remote attackers to execute arbitrary code via a crafted cookie in a user comment submission, which is not properly handled when it is deserialized.
Response discrepancy in the login and password reset forms in SilverStripe CMS before 3.5.5 and 3.6.x before 3.6.1 allows remote attackers to enumerate users via timing attacks.
Multiple cross-site scripting (XSS) vulnerabilities in SilverStripe before 2.3.5 allow remote attackers to inject arbitrary web script or HTML via (1) the CommenterURL parameter to PostCommentForm, and in the Forum module before 0.2.5 in SilverStripe before 2.3.5 allow remote attackers to inject arbitrary web script or HTML via (2) the Search parameter to forums/search (aka the search script).
Open redirect vulnerability in SilverStripe CMS & Framework 3.1.13 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the returnURL parameter to dev/build.
There is XSS in SilverStripe CMS before 3.4.4 and 3.5.x before 3.5.2. The attack vector is a page name. An example payload is a crafted JavaScript event handler within a malformed SVG element.
Multiple cross-site scripting (XSS) vulnerabilities in SilverStripe CMS & Framework before 3.1.16 and 3.2.x before 3.2.1 allow remote attackers to inject arbitrary web script or HTML via the (1) Locale or (2) FailedLoginCount parameter to admin/security/EditForm/field/Members/item/new/ItemEditForm.
In SilverStripe through 4.3.3, a missing warning about leaving install.php in a public webroot can lead to unauthenticated admin access.
The buildDefaults method on DevelopmentAdmin is missing a permission check. In live mode, if you access /dev/build, you are requested to login first. However, if you access /dev/build/defaults, then the action is performed without any login check. This should be protected in the same way that /dev/build is. The buildDefaults view is requireDefaultRecords() on each DataObject class, and hence has the potential to modify database state. It also lists all …
In it's default configuration, SilverStripe trusts all originating IPs to include HTTP headers for Hostname, IP and Protocol. This enables reverse proxies to forward requests while still retaining the original request information. Trusted IPs can be limited via the SS_TRUSTED_PROXY_IPS constant. Even with this restriction in place, SilverStripe trusts a variety of HTTP headers due to different proxy notations (e.g. X-Forwarded-For vs. Client-IP). Unless a proxy explicitly unsets invalid HTTP …
GridField does not have sufficient CSRF protection, meaning that in some cases users with CMS access can be tricked into posting unspecified data into the CMS from external websites. Amongst other default CMS interfaces, GridField is used for management of groups, users and permissions in the CMS.
SavedJobData and SavedJobMessages contain php serialized data. There's no point showing these to a CMS Admin as they're not human readable. Worse, it might be insecure, as a malicious CMS Admin might be able to craft a payload thats dangerous to unserialize. This issue has been resolved by hiding this content, even from administrators.
By default, the CMS Admin editable template for the NotifyUsers action has access to a large number of fields, including (for instance) Member#Password. This would allow a malicious CMS Admin to extract other admin passwords by adding a template emailing these fields to themselves when other admins trigger the workflow. A new configuration option has been added; when this option is set to true via the Config API then only …
SiteTree Creation Permission Vulnerability in silverstripe.
History XSS Vulnerability in silverstripe.
VirtualPage XSS in silverstripe.