ghsa

### Impact Improper header parsing. An attacker could sneak in a newline (`\n`) into both the header names and values. While the specification states that `\r\n\r\n` is used to terminate the header list, many servers in the wild will also accept `\n\n`. ### Patches The issue is patched in 1.0.12. ### Workarounds There are no known workarounds. ### References * https://www.rfc-editor.org/rfc/rfc7230#section-3.2.4

### Impact The SQL parser contains a regular expression that is vulnerable to [ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (Regular Expression Denial of Service). The vulnerability may lead to Denial of Service (DoS). ### Patches This issues has been fixed in sqlparse 0.4.4. ### Workarounds None. ### References This issue was discovered and reported by GHSL team member [@erik-krogh (Erik Krogh Kristensen)](https://github.com/erik-krogh). - Commit that introduced the vulnerability: e75e35869473832a1eb67772b1adfee2db11b85a

## Summary: A potential risk in clusternet which can be leveraged to make a cluster-level privilege escalation. ## Detailed analysis: The clusternet has a deployment called cluster-hub inside the clusternet-system Kubernetes namespace, which runs on worker nodes randomly. The deployment has a service account called clusternet-hub, which has a cluster role called clusternet:hub via cluster role binding. The clusternet:hub cluster role has "*" verbs of "*.*" resources. Thus, if a malicious user can access the worker node which runs the clusternet, he/she can leverage the service account to do malicious actions to critical system resources. For example, he/she can leverage the service account to get ALL secrets in the entire cluster, resulting in cluster-level privilege escalation.

There MultipartParser usage in Encode's Starlette python framework before versions 0.25.0 allows an unauthenticated and remote attacker to specify any number of form fields or files which can cause excessive memory usage resulting in denial of service of the HTTP service.

Shopware v5.5.10 was discovered to contain a cross-site scripting (XSS) vulnerability.

In modoboa prior to 2.1.0, sending a GET request to the endpoint `/api/v2/parameters/core/` returns sensitive information without any authentication or authorization.

modoboa prior to 2.1.0 is vulnerable to cross-site request forgery. An attacker must be logged in as admin to exploit this issue.

sidekiq prior to 7.0.8 is vulnerable to reflected cross-site scripting.

RosarioSIS prior to version 10.9.3 has a vulnerability that allows a user to return to a page containing personally identifiable information (PII) and sensitive information even after logging out of the application by using the browser's back button.

### Impact Steps to reproduce: Open <xwiki-host>/xwiki/bin/view/XWiki/Notifications/Code/LegacyNotificationAdministration?since=%7B%7B%2Fhtml%7D%7D+%7B%7Basync+async%3D%22true%22+cached%3D%22false%22+context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello+%22+%2B+%22from+groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D, where <xwiki-host> is the URL of your XWiki installation. This demonstrates an XWiki syntax injection attack via the since-parameter, allowing privilege escalation from view to programming rights. ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8 and 14.10.3. ### Workarounds For versions >= 14.6-rc-1 the workaround is to modify the page `XWiki.Notifications.Code.LegacyNotificationAdministration` to add the missing escaping, as described on https://github.com/xwiki/xwiki-platform/commit/8e7c7f90f2ddaf067cb5b83b181af41513028754#diff-4e13f4ee4a42938bf1201b7ee71ca32edeacba22559daf0bcb89d534e0225949R70 For vers...