ghsa

During installation, certain parameters (admin_username and admin_password) are not escaped in the setup form. This issue is resolved in 3.1.14 stable, although existing users are advised to remove this file prior to deploying to a production server.

When a secure token parameter is provided to a SilverStripe site (such as isDev or flush) an empty token parameter can be provided in order to bypass normal authentication parameters. For instance, http://www.mysite.com/?isDev=1&isDevtoken will force a site to dev mode. Alternatively, "flush" could also be used in succession to cause excessive load on a victim site and risk denial of service. The fix in this case is to ensure that empty tokens fail the validation check.

A XSS risk exists in the returnURL parameter passed to dev/build. An unvalidated url could cause the user to redirect to an unverified third party url outside of the site. This issue is resolved in framework 3.1.14 stable release.

A vulnerability has been found in the SilverStripe framework where a login url can be potentially redirected to an external site. For example, the url http://www.my-silverstripe-site.com/Security/login?BackURL=/\attacker-site.com will redirect successful logins to the page http://attacker-site.com. If that website were set up to look identical to the first with "login failed" then the user will likely just enter their user/pass again.

A potential hostname injection vulnerability has been found which could allow attackers to alter url resolution. If a request contains the X-Forwarded-Host HTTP header a website would then use its value in place of the actual HTTP hostname. In cases where caching is enabled, this could allow an attacker to potentially embed a remote url as the base_url for any site. This would then cause other visitors to the site to be redirected unknowingly. This header is necessary for servers running behind a reverse proxy (such as nginx). Such servers are likely not vulnerable to this risk. A fix has been merged into the default installer, although existing projects which do not run behind a reverse proxy should update their htaccess as below: ``` <IfModule mod_headers.c> # Remove X-Forwarded-Host header sent as a part of any request from the web RequestHeader unset X-Forwarded-Host </IfModule> ```

A low level XSS vulnerability has been found in the Framework affecting http redirection via the Director::force_redirect method. Attempts to redirect to a url may generate HTML which is not safely escaped, and may pose a risk of XSS in some environments. This vulnerability is marked low as it is difficult to exploit, as any injected HTML will only be returned from the server if the Location HTTP header is also sent, meaning that any user browsing the site would not be exposed to the body of the response before their browser redirects them.

A cross-site scripting vulnerability has been discovered in the FormAction field where a user-specified title may be specified.

A high level XSS vulnerability has been discovered in the SilverStripe framework which causes links containing hash anchors (E.g. href="#anchor") to be rewritten in an unsafe way. The rewriteHashlinks option on SSViewer will rewrite these to contain the current url, although without adequate escaping, meaning that HTML could be injected via injecting unsafe values to any page via the querystring. Due to the nature of this issue it is likely that a large number of SilverStripe sites are affected.

### Impact There is a vulnerability in [GO managing malformed DNS message](https://groups.google.com/g/golang-announce/c/wkkO4P9stm0), which impacts Traefik. This vulnerability could be exploited to cause a denial of service. ### References - [CVE-2024-24788](https://www.cve.org/CVERecord?id=CVE-2024-24788) ### Patches - https://github.com/traefik/traefik/releases/tag/v2.11.3 - https://github.com/traefik/traefik/releases/tag/v3.0.1 ### Workarounds No workaround. ### For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).

A cross-site scripting vulnerability has been discovered in the print view of GridField. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any field of an object in a GridField, and the print feature is used. This has been resolved by ensuring that the print feature safely escapes all fields.