Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-8686-4cr3-76wj: usememos/memos vulnerable to stored Cross-site Scripting

Cross-site Scripting (XSS) - Stored in GitHub repository usememos/memos prior to 0.10.0.

ghsa
#xss#git
GHSA-9h7x-9pmh-7gg8: usememos/memos vulnerable to stored Cross-site Scripting

Cross-site Scripting (XSS) - Stored in GitHub repository usememos/memos prior to 0.10.0.

GHSA-h2ph-9r76-37v5: usememos/memos vulnerable to stored Cross-site Scripting

Cross-site Scripting (XSS) - Stored in GitHub repository usememos/memos prior to 0.10.0.

GHSA-fpjc-cxr6-w6h8: usememos/memos vulnerable to stored Cross-site Scripting

Cross-site Scripting (XSS) - Stored in GitHub repository usememos/memos prior to 0.10.0.

GHSA-x22v-qgm2-7qc7: usememos/memos vulnerable to stored Cross-site Scripting

Cross-site Scripting (XSS) - Stored in GitHub repository usememos/memos prior to 0.10.0.

GHSA-7rrj-xr53-82p7: Tokio reject_remote_clients configuration may get dropped when creating a Windows named pipe

### Impact When configuring a Windows named pipe server, setting `pipe_mode` will reset `reject_remote_clients` to `false`. If the application has previously configured `reject_remote_clients` to `true`, this effectively undoes the configuration. This also applies if `reject_remote_clients` is not explicitly set as this is the default configuration and is cleared by calling `pipe_mode`. Remote clients may only access the named pipe if the named pipe's associated path is accessible via a publically shared folder (SMB). ### Patches The following versions have been patched: * 1.23.1 * 1.20.3 * 1.18.4 The fix will also be present in all releases starting from version 1.24.0. Named pipes were introduced to Tokio in version 1.7.0, so releases older than 1.7.0 are not affected. ### Workarounds Ensure that `pipe_mode` is set **first** after initializing a `ServerOptions`. For example: ```rust let mut opts = ServerOptions::new(); opts.pipe_mode(PipeMode::Message); opts.reject_remote_cl...

GHSA-54w6-vxfh-fw7f: Http4s improperly parses User-Agent and Server headers

### Impact The `User-Agent` and `Server` header parsers are susceptible to a fatal error on certain inputs. In http4s, modeled headers are lazily parsed, so this only applies to services that explicitly request these typed headers. #### v0.21.x ```scala val unsafe: Option[`User-Agent`] = req.headers.get(`User-Agent`) ``` #### v0.22.x, v0.23.x, v1.x ```scala val unsafe: Option[`User-Agent`] = req.headers.get[`User-Agent`] val alsoUnsafe: Option[`Server`] = req.headers.get[Server] ``` ### Patches Fixes are released in 0.21.34, 0.22.15, 0.23.17, and 1.0.0-M38. ### Workarounds #### Use the weakly typed header interface ##### v0.21.x ```scala val safe: Option[Header] = req.headers.get("User-Agent".ci) // but don't do this val unsafe = header.map(_.parsed) ``` ##### v0.22.x, v0.23.x, v1.x ```scala val safe: Option[Header] = req.headers.get(ci"User-Agent") ```

GHSA-vjhf-8vqx-vqpq: KubePi allows malicious actor to login with a forged JWT token via Hardcoded Jwtsigkeys

### Summary The jwt authentication function of kubepi <= v1.6.2 uses hard-coded Jwtsigkeys, resulting in the same Jwtsigkeys for all online projects. This means that an attacker can forge any jwt token to take over the administrator account of any online project. ### Details [`session.go`](https://github.com/KubeOperator/KubePi/blob/da784f5532ea2495b92708cacb32703bff3a45a3/internal/api/v1/session/session.go#L35), the use of hard-coded JwtSigKey allows an attacker to use this value to forge jwt tokens arbitrarily. The JwtSigKey is confidential and should not be hard-coded in the code. ```golang var JwtSigKey = []byte("signature_hmac_secret_shared_key") var jwtMaxAge = 10 * time.Minute type Handler struct { userService user.Service roleService role.Service clusterService cluster.Service rolebindingService rolebinding.Service ldapService ldap.Service jwtSigner *jwt.Signer } ``` ### Affected Version <= v1.6.2 ### Patches The vulnerability has be...

GHSA-6mjp-2rm6-9g85: XWiki CKEditor.HTMLConverter vulnerable to Remote Code Execution via Cross-Site Request Forgery (CSRF)

### Impact The `CKEditor.HTMLConverter` document lacked a protection against Cross-Site Request Forgery (CSRF), allowing to execute macros with the rights of the current user. If a privileged user with programming rights was tricked into executing a GET request to this document with certain parameters (e.g., via an image with a corresponding URL embedded in a comment or via a redirect), this would allow arbitrary remote code execution and the attacker could gain rights, access private information or impact the availability of the wiki. The attack can be demonstrated by accessing the URL `<server>/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter&language=en&sourceSyntax=xwiki%2F2.1&stripHTMLEnvelope=true&fromHTML=false&toHTML=true&text=%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D` where `<server>` is the URL of the XWiki installation as a user with programming rights. If this displays the text "Hello from Groovy!", the installation is vulnerable. ### ...

GHSA-q84x-3476-8ff2: Apache James MIME4J vulnerable to information disclosure to local users

Unproper laxist permissions on the temporary files used by MIME4J TempFileStorageProvider may lead to information disclosure to other local users. This issue affects Apache James MIME4J version 0.8.8 and prior versions. We recommend users to upgrade to MIME4j version 0.8.9 or later.