ghsa

A moderate severity security vulnerability has been identified in the Kaminari pagination library for Ruby on Rails, concerning insecure file permissions. This advisory outlines the vulnerability, affected versions, and provides guidance for mitigation. ### Impact This vulnerability is of moderate severity due to the potential for unauthorized write access to particular Ruby files managed by the library. Such access could lead to the alteration of application behavior or data integrity issues. ### Resolution Those who use the `gem install` command, such as `gem install kaminari -v 0.16.1`, `gem unpack kaminari -v 0.16.1`, or `bundle install` to download the package would **_not_** be affected and no action is required. Those who manually download and decompressing the affected versions are advised to update to 0.16.2 or later version of Kaminari where file permissions have been adjusted to enhance security. ### Workarounds If upgrading is not feasible immediately, manually adju...

The GraphQL controller lacked any CSRF protection, meaning authenticated users could be forced or tricked into visiting a URL that would send a GET request to the affected web server that could mutate or destroy data without the user knowing.

A potential SQL injection vulnerability was identified by using the silverstripe/postgresql database adapter. While unlikely to be exploitable, we have patched silverstripe/framework to ensure that table names are safely escaped before being passed to database adapters or user code.

A possible denial of service attack vector has been identified in the dev/build system controller. dev/build now has its own URL token, similar to flushtoken, to ensure users are authenticated when running dev/build outside of dev environments.

When running SilverStripe 3.7 or 4.x in dev mode with the mysqli database driver, there is a potential to disclose the connection details. We have blacklisted the sensitive parts of the connection information from being included in dev mode stack traces when database errors occur.

Some potentially dangerous file types exist in File.allowed_extensions which could allow a malicious CMS user to upload files that then get executed in the security context of the website. We have removed the ability to upload .css, .js, .potm, .dotm, .xltm and .jar files in the default configuration. Since allowed_extensions are synced to webserver configuration (in assets/.htaccess) automatically, this will also deny access to any existing uploads with these extensions. Review our security guidelines for the Common Web Platform and the File Security guide for SilverStripe 4 to find out how to add or remove extensions.

There is a user ID enumeration vulnerability in our brute force error messages. - Users that don't exist in will never get a locked out message - Users that do exist, will get a locked out message This means an attacker can infer or confirm user details that exist in the member table. This issue has been resolved by ensuring that login attempt logging and lockout process works equivalently for non-existent users as it does for existant users. This is a regression of [SS-2017-002](https://www.silverstripe.org/download/security-releases/ss-2017-002).

Under some circumstances a form may populate a PasswordField with submitted data, reflecting submitted data back to a user. The user will only see their own submissions for password data, which is not considered best practice. We are not aware of data leaks to other users, devices or sessions.

A weakness in the .htaccess rules preventing requests to uploaded PHP scripts allows PHP scripts that had made their way into the assets directory to be successfully executed through the use of a specially crafted URL. There are protections in place to disallow upload of PHP scripts through the CMS, meaning this weakness does not lead to direct vulnerabilities. In addition, sites hosted on the New Zealand Common Web Platform or SilverStripe Platform have additional configuration in place which prevents PHP script execution in assets, even in a malicious party manages to upload these into the folder.

There is a vulnerability whereby arbitrary global functions may be executed if malicious user input is passed through to in the second argument of `ViewableData::renderWith`. This argument resolves associative arrays as template placeholders. This exploit requires that user code has been written which makes use of the second argument in `renderWith` and where user input is passed directly as a value in an associative array without sanitisation such as `Convert::raw2xml()`. `ViewableData::customise` is not vulnerable.