ghsa

A flaw was found in Keycloak. This flaw depends on a non-default configuration "Revalidate Client Certificate" to be enabled and the reverse proxy is not validating the certificate before Keycloak. Using this method an attacker may choose the certificate which will be validated by the server. If this happens and the KC_SPI_TRUSTSTORE_FILE_FILE variable is missing/misconfigured, any trustfile may be accepted with the logging information of "Cannot validate client certificate trust: Truststore not available". This may not impact availability as the attacker would have no access to the server, but consumer applications Integrity or Confidentiality may be impacted considering a possible access to them. Considering the environment is correctly set to use "Revalidate Client Certificate" this flaw is avoidable.

In Spring Boot versions 3.0.0 - 3.0.6, 2.7.0 - 2.7.11, 2.6.0 - 2.6.14, 2.5.0 - 2.5.14 and older unsupported versions, there is potential for a denial-of-service (DoS) attack if Spring MVC is used together with a reverse proxy cache. Specifically, an application is vulnerable if all of the conditions are true: * The application has Spring MVC auto-configuration enabled. This is the case by default if Spring MVC is on the classpath. * The application makes use of Spring Boot's welcome page support, either static or templated. * Your application is deployed behind a proxy which caches 404 responses. Your application is NOT vulnerable if any of the following are true: * Spring MVC auto-configuration is disabled. This is true if WebMvcAutoConfiguration is explicitly excluded, if Spring MVC is not on the classpath, or if spring.main.web-application-type is set to a value other than SERVLET. * The application does not use Spring Boot's welcome page support. * You do not have a proxy which...

Camaleon CMS prior to 2.7.4 was discovered to contain a Server-Side Template Injection (SSTI) vulnerability via the `formats` parameter.

A security issue was discovered in secrets-store-csi-driver where an actor with access to the driver logs could observe service account tokens. These tokens could then potentially be exchanged with external cloud providers to access secrets stored in cloud vault solutions. Tokens are only logged when [TokenRequests is configured in the CSIDriver object](https://kubernetes-csi.github.io/docs/token-requests.html) and the driver is set to run at log level 2 or greater via the -v flag. This issue has been rated MEDIUM [CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) (6.5), and assigned CVE-2023-2878 ### Am I vulnerable? You may be vulnerable if [TokenRequests is configured in the CSIDriver object](https://kubernetes-csi.github.io/docs/token-requests.html) and the driver is set to run at log level 2 or greater via the -v flag. To check if token requests are configured, run the following command: ...

### Impact Unicode RIGHT-TO-LEFT OVERRIDE characters can be used to mask the original filename. ### Reported-By Thanks to the report from Mio Li [wulilixi1@gmail.com](mailto:wulilixi1@gmail.com) ### Patches ``` commit 17e791afb90c9ad27c65f63c6be14f2f6a3a9d60 Author: Daniel Valdivia <18384552+dvaldivia@users.noreply.github.com> Date: Tue May 23 08:47:12 2023 -0700 Replace RIGHT-TO-LEFT OVERRIDE unicode (#2828) Signed-off-by: Daniel Valdivia <18384552+dvaldivia@users.noreply.github.com> ``` ### Workarounds Workarounds are to remove the concerned file and rewrite it properly with the right file and extensions. Avoid using RTLO characters in your filenames.

### Summary XSS can be triggered via the Update Asset Index utility ### PoC 1. Access setting tab 2. Create new assets 3. In assets name inject payload: "<script>alert(26)</script> 4. Click Utilities tab 5. Choose all volumes, or volume trigger xss 7. Click Update asset indexes. XSS will be triggered Json response volumes name makes triggers the payload "session":{"id":1,"indexedVolumes":{"1":"\"<script>alert(26)</script>"}, It’s run on every POST request in the utility. Resolved in https://github.com/craftcms/cms/commit/8c2ad0bd313015b8ee42326af2848ee748f1d766

### Summary XSS can be triggered by review volumes ### PoC 1. Access setting tab 2. Create new assets 3. In assets name inject payload: "<script>alert(1337)</script> 4. Click Utilities tab 5. Choose all volumes, or volume trigger xss 6. Click Update asset indexes. 7. Wait to assets update success. 8. Progress complete. 9. Click on review button will trigger XSS ### Root cause Function: index.php?p=admin/actions/asset-indexes/process-indexing-session&v=1680710595770 After loading completed, progess will load: "skippedEntries" and "missingEntries" These parameters is not yet filtered, I just tried "skippedEntries" but I think it will be work with "missingEntries" ### My reponse: { "session": { "id": 10, "indexedVolumes": { "6": "\"<script>alert(1337)</script>" }, "totalEntries": 2235, "processedEntries": 2235, "cacheRemoteImages": true, "listEmptyFolders": false, "isCli": false, "actionRequired": true, ...

### Summary A malformed RSS feed can deliver an XSS payload ### PoC Create an RSS widget and add the domain https://blog.whitebear.vn/file/rss-xss2.rss The XSS payload will be triggered by the title in tag `<item>` Resolved in https://github.com/craftcms/cms/commit/b77cb3023bed4f4a37c11294c4d319ff9f598e1f

### Summary The platform does not filter input and encode output in Quick Post validation error message, which can deliver an XSS payload. ### Details Old CVE fixed the XSS in label HTML but didn’t fix it when clicking save. ### PoC 1. Login at admin 2. Go to setting 3. Create a Section 4. On Entry page, click Edit label 5. Inject the XSS payload into the label and save 6. On the admin dashboard choose new widget -> Quick Post 7. In Quick Post, click save with blank slug; The XSS will be executed "errors":{"title":["<script>alert('nono')</script> cannot be blank."],"slug":["Slug cannot be blank."] Fixed in https://github.com/craftcms/cms/commit/9d0cd0bda7c8a830a3373f8c0f06943e519ac888

### Impact Highlight may record passwords on customer deployments when a password html input is switched to `type="text"` via a javascript "Show Password" button. This differs from the expected behavior which always obfuscates `type="password"` inputs. A customer may assume that switching to `type="text"` would also not record this input; hence, they would not add additional `highlight-mask` css-class obfuscation to this part of the DOM, resulting in unintentional recording of a password value when a `Show Password` button is used. ### Patches `highlight.run@6.0.0` resolves the issue via https://github.com/rrweb-io/rrweb/pull/1184 This patch tracks changes to the `type` attribute of an input to ensure an input that used to be a `type="password"` continues to be obfuscated. ### Workarounds We have deployed a change to our data ingest to obfuscate passwords server side from older clients. This means that upgrading to the latest version of highlight.run is not necessary but recommended...