Source
ghsa
A critical flaw has been identified in elijaa/phpmemcachedadmin affecting version 1.3.0, specifically related to a stored XSS vulnerability. This vulnerability allows malicious actors to insert a carefully crafted JavaScript payload. The issue arises from improper encoding of user-controlled entries in the "/pmcadmin/configure.php" parameter.
Improper Restriction of XML External Entity Reference vulnerability in Apache Cocoon. This issue affects Apache Cocoon: from 2.2.0 before 2.3.0. Users are recommended to upgrade to version 2.3.0, which fixes the issue.
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Cocoon. This issue affects Apache Cocoon: from 2.2.0 before 2.3.0. Users are recommended to upgrade to version 2.3.0, which fixes the issue.
Before DolphinScheduler version 3.1.0, the login user could delete UDF function in the resource center unauthorized (which almost used in sql task), with unauthorized access vulnerability (IDOR), but after version 3.1.0 we fixed this issue. We mark this cve as moderate level because it still requires user login to operate, please upgrade to version 3.1.0 to avoid this vulnerability
File Upload vulnerability in Microweber v.2.0.4 allows a remote attacker to execute arbitrary code via a crafted script to the file upload function in the created forms component.
### Impact A user with access to the media manager that stores SVG files could create a stored XSS attack against themselves and any other user with access to the media manager when SVG files are supported. SVG files are supported by default in v3 for convenience; however, this has resulted in multiple mistaken vulnerability reports from security researchers. As per the documentation, if a backend user is not trusted, the advice is to remove the `svg` extension from the list of supported file types. ### Patches The issue has been patched in v3.5.2 by including an SVG sanister. It is enabled by default for new installations but must be enabled for existing sites in the **config/media.php** file. ``` 'clean_vectors' => true, ``` ### Workarounds If you cannot upgrade for this patch, follow the pervious advice and remove `svg` from the supported file types. ### References - https://github.com/octobercms/october/blob/3.x/config/media.php Credits to: - Faris Krivic - Okan Kurtulus ...
### Impact [CarrierWave::Uploader::ContentTypeAllowlist](https://github.com/carrierwaveuploader/carrierwave/blob/master/lib/carrierwave/uploader/content_type_allowlist.rb) has a Content-Type allowlist bypass vulnerability, possibly leading to XSS. The validation in `allowlisted_content_type?` determines Content-Type permissions by performing a partial match. If the `content_type` argument of `allowlisted_content_type?` is passed a value crafted by the attacker, Content-Types not included in the `content_type_allowlist` will be allowed. In addition, by setting the Content-Type configured by the attacker at the time of file delivery, it is possible to cause XSS on the user's browser when the uploaded file is opened. ### Patches Upgrade to [3.0.5](https://rubygems.org/gems/carrierwave/versions/3.0.5) or [2.2.5](https://rubygems.org/gems/carrierwave/versions/2.2.5). ### Workarounds When validating with `allowlisted_content_type?` in [CarrierWave::Uploader::ContentTypeAllowlist](https:...
### Impact An authenticated backend user with the `editor.cms_pages`, `editor.cms_layouts`, or `editor.cms_partials` permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to `cms.safe_mode` being enabled can write specific Twig code to escape the Twig sandbox and execute arbitrary PHP. This is not a problem for anyone who trusts their users with those permissions to usually write and manage PHP within the CMS by not having `cms.safe_mode` enabled. Still, it would be a problem for anyone relying on `cms.safe_mode` to ensure that users with those permissions in production do not have access to write and execute arbitrary PHP. ### Patches This issue has been patched in v3.4.15. ### Workarounds As a workaround, remove the specified permissions from untrusted users. ### References Credits to: - [Vasiliy Bodrov](https://github.com/whatev3n) ### For more information If you have any questions or comments about this advisory: * Email us at [h...
### Impact An authenticated backend user with the `editor.cms_pages`, `editor.cms_layouts`, or `editor.cms_partials` permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to `cms.safe_mode` being enabled can craft a special request to include PHP code in the CMS template. This is not a problem for anyone who trusts their users with those permissions to usually write & manage PHP within the CMS by not having `cms.safe_mode` enabled. Still, it would be a problem for anyone relying on `cms.safe_mode` to ensure that users with those permissions in production do not have access to write and execute arbitrary PHP. ### Patches This issue has been patched in v3.4.15. ### Workarounds As a workaround, remove the specified permissions from untrusted users. ### References Credits to: - [Vasiliy Bodrov](https://github.com/whatev3n) ### For more information If you have any questions or comments about this advisory: * Email us at [hello@octobercms....
A flaw was found in the Keycloak package. This flaw allows an attacker to benefit from an LDAP query and access existing usernames in the server.