ghsa

An information disclosure vulnerability exists in the lunary-ai/lunary, specifically in the `runs/{run_id}/related` endpoint. This endpoint does not verify that the user has the necessary access rights to the run(s) they are accessing. As a result, it returns not only the specified run but also all runs that have the `run_id` listed as their parent run. This issue affects the main branch, commit a761d833. The vulnerability allows unauthorized users to obtain information about non-public runs and their related runs, given the `run_id` of a public or non-public run.

A Server-Side Request Forgery (SSRF) vulnerability exists in berriai/litellm version 1.38.10. This vulnerability allows users to specify the `api_base` parameter when making requests to `POST /chat/completions`, causing the application to send the request to the domain specified by `api_base`. This request includes the OpenAI API key. A malicious user can set the `api_base` to their own domain and intercept the OpenAI API key, leading to unauthorized access and potential misuse of the API key.

Applications serving static resources through the functional web frameworks WebMvc.fn or WebFlux.fn are vulnerable to path traversal attacks. An attacker can craft malicious HTTP requests and obtain any file on the file system that is also accessible to the process in which the Spring application is running. Specifically, an application is vulnerable when both of the following are true: * the web application uses RouterFunctions to serve static resources * resource handling is explicitly configured with a FileSystemResource location However, malicious requests are blocked and rejected when any of the following is true: * the Spring Security HTTP Firewall https://docs.spring.io/spring-security/reference/servlet/exploits/firewall.html  is in use * the application runs on Tomcat or Jetty

### Impact Incorrect Access Control, anyone using the post or verifyRequestSignature methods to handle messages is impacted. ### Patches Patched in version 4.0.3. ### Workarounds It's possible to check the payload validation using the WhatsAppAPI.verifyRequestSignature and expect false when the signature is valid. ```ts function doPost(payload, header_signature) { if (whatsapp.verifyRequestSignature(payload.toString(), header_signature) { throw 403; } // Now the payload is correctly verified whatsapp.post(payload); } ``` ### References https://github.com/Secreto31126/whatsapp-api-js/pull/371

An arbitrary code execution vulnerability exists in versions 23.10.5.0 up to 24.7.4.1 of the MindsDB platform, when the Microsoft SharePoint integration is installed on the server. For databases created with the SharePoint engine, an ‘INSERT’ query can be used for list item creation. If such a query is specially crafted to contain Python code and is run against the database, the code will be passed to an eval function and executed on the server.

Deserialization of untrusted data can occur in versions 23.3.2.0 and newer of the MindsDB platform, enabling a maliciously uploaded model to run arbitrary code on the server when interacted with.

Deserialization of untrusted data can occur in versions 23.10.3.0 and newer of the MindsDB platform, enabling a maliciously uploaded ‘inhouse’ model to run arbitrary code on the server when a ‘describe’ query is run on it.

Deserialization of untrusted data can occur in versions 23.10.2.0 and newer of the MindsDB platform, enabling a maliciously uploaded ‘inhouse’ model to run arbitrary code on the server when used for a prediction.

Deserialization of untrusted data can occur in versions 23.10.2.0 and newer of the MindsDB platform, enabling a maliciously uploaded ‘inhouse’ model to run arbitrary code on the server when using ‘finetune’ on it.

Deserialization of untrusted data can occur in versions 2.4.0 or newer of the Cleanlab project, enabling a maliciously crafted datalab.pkl file to run arbitrary code on an end user’s system when the data directory is loaded.