ghsa

Improper Input Validation vulnerability in Apache Software Foundation Apache Airflow Drill Provider. Apache Airflow Drill Provider is affected by a vulnerability that allows an attacker to pass in malicious parameters when establishing a connection with DrillHook giving an opportunity to read files on the Airflow server. This issue affects Apache Airflow Drill Provider before 2.4.3. It is recommended to upgrade to a version that is not affected.

GitPython before 3.1.32 does not block insecure non-multi options in `clone` and `clone_from`, making it vulnerable to Remote Code Execution (RCE) due to improper user input validation, which makes it possible to inject a maliciously crafted remote URL into the clone command. Exploiting this vulnerability is possible because the library makes external calls to git without sufficient sanitization of input arguments. NOTE: this issue exists because of an incomplete fix for CVE-2022-24439.

Business Logic Errors in GitHub repository froxlor/froxlor prior to 2.0.22

# Summary An arbitrary file write vulnerability could lead to direct control of the server # Details ## Arbitrary file creation In the api/v1/file.go file, there is a function called SaveContentthat,It recieves JSON data sent by users in the form of a POST request. And the lack of parameter filtering allows for arbitrary file write operations.It looks like this: - Vulnerable Code  # PoC - We can write the SSH public key into the /etc/.root/authorized_keys configuration file on the server.  - The server was successfully written to the public key  - Successfully connected to the target server using an SSH priv...

### Summary Any file downloading vulnerability exists in 1Panel backend. ### Details Authenticated attackers can download arbitrary files through the API interface. This code has unauthorized access.  ### PoC payload: POST /api/v1/files/download/bypath HTTP/1.1 Host: ip Content-Type: application/json {"path":"/etc/passwd"}  ### Impact Attackers can freely download the file content on the target system. This will be caused a large amount of information leakage.

### Summary Arbitrary file reads allow an attacker to read arbitrary important configuration files on the server. ### Details In the api/v1/file.go file, there is a function called LoadFromFile, which directly reads the file by obtaining the requested path parameter[path]. The request parameters are not filtered, resulting in a background arbitrary file reading vulnerability  ### PoC Request /api/v1/files/loadfile, carry /etc/passwd data to read, as shown below:  ### Impact 1Panel v1.4.3

Moq v4.20.0 and 4.20.1 include support for [SponsorLink](https://github.com/devlooped/SponsorLink), which runs an obfuscated DLL at build time that scans local `git config` data and shares the user's hashed email address with SponsorLink's remote servers. There is no option to disable this. Moq v4.20.2 has removed this functionality.

## Impact The `import-in-the-middle` loader used by `@opentelemetry/instrumentation` works by generating a wrapper module on the fly. The wrapper uses the module specifier to load the original module and add some wrapping code. It allows for remote code execution in cases where an application passes user-supplied input directly to an `import()` function. ## Patches This vulnerability has been patched in `@opentelemetry/instrumentation` version `0.41.2` ## Workarounds - Do not pass any user-supplied input to `import()`. Instead, verify it against a set of allowed values. - If using `@opentelemetry/instrumentation` with support for EcmaScript Modules is not needed, ensure that none of the following options are set (either via command-line or the `NODE_OPTIONS` environment variable): ``` --experimental-loader=@opentelemetry/instrumentation/hook.mjs --experimental-loader @opentelemetry/instrumentation/hook.mjs --loader=import-in-the-middle/hook.mjs --loader import-in-the-middle/hook.m...

### Impact An attacker with sufficient client-side exploits could retrieve a valid access token for another user during the OAuth token exchange due to incorrect credential validation. The client ID must be known and the API application must have already been authorized on the targeted user account. ### Remediation - **Sentry SaaS** customers do not need to take any action. Those with the highest risk will be contacted directly by Sentry. - **Self-hosted installations** should upgrade to version 23.7.2 or higher. ### Workarounds There are no direct workarounds, but users should review applications authorized on their account (_User Settings > Authorized Applications_) and remove any that are no longer needed.

### Impact Blst versions v0.3.0 through 0.3.10 failed to perform a signature group-check if the call to `SigValidate` in the Go bindings was complemented with a check for infinity. Formally speaking, infinity, or the identity element of the elliptic curve group, is a member of the group, and the group-check should allow it. An initial review of blst users on GitHub did not uncover any use of this function with the complementary infinity check. This optional check was added as a convenience feature because despite infinity being a legitimate member of the group, individual signatures should never be infinite (as it is equivalent to having zero for the secret key), and observing one should raise a flag. ### Description The vulnerable function is declared as `SigValidate(sigInfcheck bool) bool` and if called with `sigInfcheck` argument set to `true`, the group-check was omitted. The group-check is required to be performed on untrusted input, because the pairing, the corner-stone operat...