ghsa

# Server-Side Request Forgery via LNURL Authentication Callback in LNbits Lightning Network Payment System ## Disclaimer This vulnerability was detected using **[XBOW](https://xbow.com/)**, a system that autonomously finds and exploits potential security vulnerabilities. The finding has been thoroughly reviewed and validated by a security researcher before submission. While XBOW is intended to work autonomously, during its development human experts ensure the accuracy and relevance of its reports. ## Description A Server-Side Request Forgery (SSRF) vulnerability has been discovered in LNbits' LNURL authentication handling functionality. The vulnerability exists in the LNURL authentication callback process where the application makes HTTP requests to user-provided callback URLs and follows redirects without proper validation. When processing LNURL authentication requests, the application accepts a callback URL parameter and makes an HTTP request to that URL using the httpx library ...

A vulnerability was identified in `tarteaucitron.js`, allowing a user with high privileges (access to the site's source code or a CMS plugin) to enter a URL containing an insecure scheme such as `javascript:alert()`. Before the fix, URL validation was insufficient, which could allow arbitrary JavaScript execution if a user clicked on a malicious link. ## Impact An attacker with high privileges could insert a link exploiting an insecure URL scheme, leading to: - Execution of arbitrary JavaScript code - Theft of sensitive data through phishing attacks - Modification of the user interface behavior ## Fix https://github.com/AmauriC/tarteaucitron.js/commit/2fa1e01023bce2e4b813200600bb1619d56ceb02 The issue was resolved by enforcing strict URL validation, ensuring that they start with `http://` or `https://` before being used.

### Summary Jujutsu 0.28.0 and earlier rely on versions of gitoxide that use SHA-1 hash implementations without any collision detection, leaving them vulnerable to hash collision attacks. ### Details This is a result of the underlying [CVE-2025-31130 / GHSA-2frx-2596-x5r6](https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-2frx-2596-x5r6) vulnerability in the gitoxide library Jujutsu uses to interact with Git repositories; see that advisory for technical details. This separate advisory is being issued due to the downstream impact on users of Jujutsu. ### Impact An attacker with the ability to mount a collision attack on SHA-1 like the [SHAttered](https://shattered.io/) or [SHA-1 is a Shambles](https://sha-mbles.github.io/) attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical colli...

A vulnerability was identified in `tarteaucitron.js`, where the `addOrUpdate` function, used for applying custom texts, did not properly validate input. This allowed an attacker with direct access to the site's source code or a CMS plugin to manipulate JavaScript object prototypes, leading to potential security risks such as data corruption or unintended code execution. ## Impact An attacker with high privileges could exploit this vulnerability to: - Modify object prototypes, affecting core JavaScript behavior, - Cause application crashes or unexpected behavior, - Potentially introduce further security vulnerabilities depending on the application's architecture. ## Fix https://github.com/AmauriC/tarteaucitron.js/commit/74c354c413ee3f82dff97a15a0a43942887c2b5b The issue was resolved by ensuring that user-controlled inputs cannot modify JavaScript object prototypes.

A vulnerability was identified in `tarteaucitron.js`, where user-controlled inputs for element dimensions (`width` and `height`) were not properly validated. This allowed an attacker with direct access to the site's source code or a CMS plugin to set values like `100%;height:100%;position:fixed;`, potentially covering the entire viewport and facilitating clickjacking attacks. ## Impact An attacker with high privileges could exploit this vulnerability to: - Overlay malicious UI elements on top of legitimate content, - Trick users into interacting with hidden elements (clickjacking), - Disrupt the intended functionality and accessibility of the website. ## Fix https://github.com/AmauriC/tarteaucitron.js/commit/25fcf828aaa55306ddc09cfbac9a6f8f126e2d07 The issue was resolved by enforcing strict validation and sanitization of user-provided CSS values to prevent unintended UI manipulation.

### Impact Starting with 6.1, HTTP Inputs can be configured to check if a specified header is present and has a specified value to authenticate HTTP-based ingestion. Unfortunately, even though in cases of a missing header or a wrong value the correct HTTP response (401) is returned, the message will be ingested nonetheless. ### Patches ### Workarounds Disabling http-based inputs and allow only authenticated pull-based inputs. ### References

Langflow versions prior to 1.3.0 are susceptible to code injection in the `/api/v1/validate/code` endpoint. A remote and unauthenticated attacker can send crafted HTTP requests to execute arbitrary code.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Airflow Common SQL Provider. When using the partition clause in SQLTableCheckOperator as parameter (which was a recommended pattern), Authenticated UI User could inject arbitrary SQL command when triggering DAG exposing partition_clause to the user. This allowed the DAG Triggering user to escalate privileges to execute those arbitrary commands which they normally would not have. This issue affects Apache Airflow Common SQL Provider: before 1.24.1. Users are recommended to upgrade to version 1.24.1, which fixes the issue.

When a `Some(...)` value was passed to the `properties` argument of either of these functions, a use-after-free would result. In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to `CString::drop`'s behavior). The maintainers thank [quitbug](https://github.com/quitbug/) for reporting this vulnerability to us.

### Summary gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks. ### Details gitoxide uses the `sha1_smol` or `sha1` crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide. The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the [sha1collisiondetection](https://github.com/crmarcstevens/sha1collisiondetection) algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes. ### PoC The following program demonstrates the problem, using the...