PatchFirst · Свежие уязвимости
За последние 30 дней в silverstripe/framework опубликовано уязвимостей: 0; в каталоге KEV: 0.
Уязвимостей: 93
Silverstripe Framework is a PHP framework which powers the Silverstripe CMS. In versions prior to 6.2.2, the "Insert media from web" functionality in the CMS is vulnerable to XSS from a specially crafted embed. This issue was fixed in version 6.2.2/
### Impact User enumeration is possible by performing a timing attack on the login or password reset pages with user credentials. This was originally disclosed in https://www.silverstripe.org/download/security-releases/ss-2017-005/ for CMS 3 but was not patched in CMS 4+ ### References - https://www.silverstripe.org/download/security-releases/ss-2017-005 - https://www.silverstripe.org/download/security-releases/ss-2025-001
Silverstripe Framework is a PHP framework which powers the Silverstripe CMS. Prior to 5.3.23, bad actor with access to edit content in the CMS could send a specifically crafted encoded payload to the server, which could be used to inject a JavaScript payload on the front end of the site. The payload would be sanitized on the client-side, but server-side sanitization doesn't catch it. The server-side sanitization logic has been updated to sanitize against this attack. This vulnerability is fixed in 5.3.23.
If a website has been set to the "dev" environment mode, a URL can be provided which includes an XSS payload which will be executed in the resulting error message.
Silverstripe Framework is a PHP framework which powers the Silverstripe CMS. In some cases, form messages can contain HTML markup. This is an intentional feature, allowing links and other relevant HTML markup for the given message. Some form messages include content that the user can provide. There are scenarios in the CMS where that content doesn't get correctly sanitised prior to being included in the form message, resulting in an XSS vulnerability. This issue has been addressed in silverstripe/framework version 5.3.8 and users are advised to upgrade. There are no known workarounds for this vulnerability.
silverstripe-asset-admin is a silverstripe assets gallery for asset management. When using the "insert media" functionality, the linked oEmbed JSON includes an HTML attribute which will replace the embed shortcode. The HTML is not sanitized before replacing the shortcode, allowing a script payload to be executed on both the CMS and the front-end of the website. This issue has been addressed in silverstripe/framework version 5.3.8 and users are advised to upgrade. There are no known workarounds for this vulnerability.
> [!IMPORTANT] > This vulnerability only affects sites which are in the "dev" environment mode. If your production website is in "dev" mode, it has been misconfigured, and you should immediately swap it to "live" mode. > See https://docs.silverstripe.org/en/developer_guides/debugging/environment_types/ for more information. If a website has been set to the "dev" environment mode, a URL can be provided which includes an XSS payload which will be executed in the resulting error message. ## References - https://www.silverstripe.org/download/security-releases/ss-2024-002 ## Reported by Gaurav Nayak from [Chaleit](https://chaleit.com/)
Silverstripe framework is the PHP framework forming the base for the Silverstripe CMS. In affected versions a bad actor with access to edit content in the CMS could add send a specifically crafted encoded payload to the server, which could be used to inject a JavaScript payload on the front end of the site. The payload would be sanitised on the client-side, but server-side sanitisation doesn't catch it. The server-side sanitisation logic has been updated to sanitise against this type of attack in version 5.2.16. All users are advised to upgrade. There are no known workarounds for this vulnerability.
### Impact TinyMCE v6 has a configuration value `convert_unsafe_embeds` set to `false` which allows svg files containing javascript to be used in `<object>` or `<embed>` tags, which can be used as a vector for XSS attacks. Note that `<embed>` tags are not allowed by default. After patching the default value of `convert_unsafe_embeds` will be set to `true`. This means that `<object>` tags will be converted to iframes instead the next time the page is saved, which may break any pages that rely upon previously saved `<object>` tags. Developers can override this configuration if desired to revert to the original behaviour. We reviewed the pote
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.
A carefully constructed malformed URL can be used to circumvent the offsite redirection protection used on `BackURL` parameters. This could lead to users entering sensitive data in malicious websites instead of the intended one.
When accessing the `install.php` script it is possible to extract any pre-configured database or default admin account password by viewing the source of the page, and inspecting the `value` property of the password fields.
A member with the permission `EDIT_PERMISSIONS` and access to the "Security" section is able to re-assign themselves (or another member) to `ADMIN` level. CMS Fields for the member are constructed using DirectGroups instead of Groups relation which results in bypassing security logic preventing privilege escalation.
Сопоставьте установленный стек и версии со свежими базами уязвимостей.