ghsa

### Summary Due to insufficient validation on the content of new FAQ posts, it is possible for authenticated users to inject malicious HTML or JavaScript code that can impact other users viewing the FAQ. This vulnerability arises when user-provided inputs in FAQ entries are not sanitized or escaped before being rendered on the page. ### Details An attacker can inject malicious HTML content into the FAQ editor at http://localhost/admin/index.php?action=editentry, resulting in a complete disruption of the FAQ page's user interface. By injecting malformed HTML elements styled to cover the entire screen, an attacker can render the page unusable. This injection manipulates the page structure by introducing overlapping buttons, images, and iframes, breaking the intended layout and functionality. ### PoC 1. In the source code of a FAQ Q&A post, insert the likes of this snippet: ``` <p>&lt;--`<img src="&#96;"> --!&gt;</p> <div style="position: absolute; top: 0; left: 0; width: 100%; height...

A security issue was discovered in the LRA Coordinator component of Narayana. When Cancel is called in LRA, an execution time of approximately 2 seconds occurs. If Join is called with the same LRA ID within that timeframe, the application may crash or hang indefinitely, leading to a denial of service.

### Summary This is a POC for a path-sanitizer [npm package](https://www.npmjs.com/package/path-sanitizer). The filters can be bypassed and can result in path traversal. Payload: `..=%5c` can be used to bypass this on CLI (along with other candidates). Something similar would likely work on web apps as well. ### PoC Here's the code to test for the filter bypass: ```js const sanitize = require("path-sanitizer") const path = require("path") const fs = require("fs") // Real scenario: function routeHandler(myPath) { // Lets just assume that the path was extracted from the request // We want to read a file in the C:\Users\user\Desktop\myApp\ directory // But the user should be able to access C:\Users\user\Desktop\ // So we need to sanitize the path const APP_DIR = "/var/hacker" const sanitized = path.join(APP_DIR, sanitize(myPath)) // Now we would usally read the file // But in this case we just gonna print the path // console.log(sanitized) return sanitized } fu...

A flaw was found in the Hive ClusterDeployments resource in OpenShift Dedicated. In certain conditions, this issue may allow a developer account on a Hive-enabled cluster to obtain cluster-admin privileges by executing arbitrary commands on the hive/hive-controllers pod.

This crate uses a number of cryptographic algorithms that are no longer considered secure and it uses them in ways that do not guarantee the integrity of the encrypted data. `MagicCrypt64` uses the insecure DES block cipher in CBC mode without authentication. This allows for practical brute force and padding oracle attacks and does not protect the integrity of the encrypted data. Key and IV are generated from user input using CRC64, which is not at all a key derivation function. `MagicCrypt64`, `MagicCrypt128`, `MagicCrypt192`, and `MagicCrypt256` are all vulnerable to padding-oracle attacks. None of them protect the integrity of the ciphertext. Furthermore, none use password-based key derivation functions, even though the key is intended to be generated from a password. Each of the implementations are unsound in that they use uninitialized memory without `MaybeUninit` or equivalent structures. For more information, visit the [issue](https://github.com/magiclen/rust-magiccrypt/issu...

We consider `as_slice` and `as_slice_mut` unsound because: the pointer with any bit patterns could be cast to the slice of arbitrary types. The pointer could be created by unsafe new and deprecated `from_parts`. We consider that `from_parts` should be removed in latest version because it will help trigger unsoundness in `as_slice`. With new declared as unsafe, `as_slice` should also declared as unsafe. This was patched in by marking two functions as `unsafe`.

# Reflected XSS at /lgsl_files/lgsl_list.php **Description:** Vulnerability: A reflected XSS vulnerability exists in the `Referer` HTTP header of [LGSL v6.2.1](https://github.com/tltneon/lgsl/releases/tag/v6.2.1). The vulnerability allows attackers to inject arbitrary JavaScript code, which is reflected in the HTML response without proper sanitization. When crafted malicious input is provided in the `Referer` header, it is echoed back into an HTML attribute in the application’s response. The vulnerability is present at [Line 20-24](https://github.com/tltneon/lgsl/blob/master/lgsl_files/lgsl_list.php#L20-L24) ```php $uri = $_SERVER['REQUEST_URI']; if ($lgsl_config['preloader']) { $uri = $_SERVER['HTTP_REFERER']; } ``` **Proof of Concept:** 1. Capture a request to the path `/lgsl_files/lgsl_list.php`. 2. Inject the following payload into the Referer header: `test'><script>alert(1)</script><`. 3. Send the request. 4. The XSS payload is triggered when reloading. ![image](h...

## Summary An **open redirect vulnerability** has been identified in the **verify email endpoint** of Better Auth, potentially allowing attackers to redirect users to malicious websites. This issue affects users relying on email verification links generated by the library. ## Affected Versions - All versions prior to **v1.1.6**. ## Impact Attackers could craft malicious email verification links that exploit the redirect functionality to send users to untrusted domains. This can result in: - **Phishing attacks** – Users may unknowingly enter sensitive information on fake login pages. - **Reputation damage** – Trust issues for applications using Better Auth. ## Vulnerability Details The verify email callback endpoint accepts a `callbackURL` parameter. Unlike other verification methods, email verification only uses JWT to verify and redirect without proper validation of the target domain. The origin checker is bypassed in this scenario because it only checks for `POST` requests. An at...

### Impact A vulnerability has been reported in Password Pusher where an attacker can copy the session cookie before a user logs out, potentially allowing session hijacking. Although the session token is replaced and invalidated upon logout, if an attacker manages to capture the session cookie before this process, they can use the token to gain unauthorized access to the user's session until the token expires or is manually cleared. This vulnerability hinges on the attacker's ability to access the session cookie during an active session, either through a man-in-the-middle attack, by exploiting another vulnerability like XSS, or via direct access to the victim's device. ### Patches Although there is no direct resolution to this vulnerability, it is recommended to always use the latest version of Password Pusher to best mitigate risk. ### Workarounds If self-hosting, ensure Password Pusher is hosted exclusively over SSL connections to encrypt traffic and prevent session cookies fr...

### Summary An Insecure Direct Object Reference (IDOR) vulnerability in the update_subscription endpoint allows any authenticated user to manipulate other users' Stripe subscriptions by simply modifying the email parameter in the request. ### Details The vulnerability exists in the subscription endpoint at `/api/subscription`. The endpoint uses an email parameter as a direct reference to user subscriptions without verifying object ownership. While authentication is required, there is no authorization check to verify if the authenticated user owns the referenced subscription. Vulnerable code in `/api/subscription`: ```python @subscription_router.patch("") @requires(["authenticated"]) async def update_subscription(request: Request, email: str, operation: str): # IDOR: email parameter directly references user subscriptions without ownership verification customers = stripe.Customer.list(email=email).auto_paging_iter() customer = next(customers, None) if operation == ...