ghsa

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.

A cross-site scripting vulnerability has been discovered in the TreeDropdownField and TreeMultiSelectField. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any of the dataobjects used as a data source for either of these fields. This has been resolved by ensuring that all dataobjects used as a data source have their content safely encoded.

A low level vulnerability has been found in the SilverStripe framework, where the Quadratic Blowup Attack could potentially be exploited to affect the performance of a site. See http://mashable.com/2014/08/06/wordpress-xml-blowup-dos/ for a writeup.

Non IE browsers don’t appear to be affected, but I haven’t tested a wide range of browsers to be sure Requests that come through from IE do NOT appear to encode all entities in the URL string, meaning they are inserted into output content directly by SSViewer::process() when rewriting hashlinks, as it directly outputs $_SERVER[‘REQUEST_URI’] **Example IE8 request** 127.0.0.1 - - [18/Jun/2014:14:13:42 +1000] “GET /site/cars/brands/toyota?one=1\”onmouseover=\”alert(‘things’);\” HTTP/1.1” 200 **Example FF request** 127.0.0.1 - - [18/Jun/2014:14:14:22 +1000] “GET /site/cars/brands/toyota?one=1\%22onmouseover=\%22alert(%27things%27);\%22 HTTP/1.1” 200 This causes any hash anchor to have the JS code inserted into the page as-is.

A number of form actions in the Forum module are directly accessible. A malicious user (e.g. spammer) can use GET requests to create Members and post to forums, bypassing CSRF and anti-spam measures. Additionally, a forum moderator could be tricked into clicking a specially crafted URL, resulting in a topic being moved. Thanks to Michael Strong for discovering.