ghsa

A security vulnerability was discovered for [gardenctl](https://github.com/gardener/gardenctl-v2) when it is used with non‑POSIX shells such as **[Fish](https://fishshell.com/)** and **[PowerShell](https://learn.microsoft.com/en-us/powershell/)**. Such setup could allow an attacker with administrative privileges for a Gardener project to craft malicious credential values in infrastructure Secret objects that break out of the intended string context when evaluated in Fish or PowerShell environments used by the Gardener service operators, leading to arbitrary command execution on the operator's device. **Am I vulnerable?** This CVE affects all Gardener operators who use **gardenctl < v2.12.0** with non‑POSIX shells such as **[Fish](https://fishshell.com/)** and **[PowerShell](https://learn.microsoft.com/en-us/powershell/)**.

## Summary An attacker can cause excessive memory allocation in quic-go's HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame that decodes into a large header field section (many unique header names and/or large values). The implementation builds an `http.Header` (used on the `http.Request` and `http.Response`, respectively), while only enforcing limits on the size of the (QPACK-compressed) HEADERS frame, but not on the decoded header, leading to memory exhaustion. ## Impact A misbehaving or malicious peer can cause a denial-of-service (DoS) attack on quic-go's HTTP/3 servers or clients by triggering excessive memory allocation, potentially leading to crashes or exhaustion. It affects both servers and clients due to symmetric header construction. ## Details In HTTP/3, headers are compressed using QPACK (RFC 9204). quic-go's HTTP/3 server (and client) decodes the QPACK-encoded HEADERS frame into header fields, then constructs an http.Request (or respon...

A vulnerability was identified in PowerJob up to 5.1.2. This vulnerability affects the function checkConnectivity of the file src/main/java/tech/powerjob/common/utils/net/PingPongUtils.java of the component Network Request Handler. The manipulation of the argument targetIp/targetPort leads to server-side request forgery. Remote exploitation of the attack is possible. The exploit is publicly available and might be used.

### Description An input-validation flaw in the returnTo parameter in the Auth0 Next.js SDK could allow attackers to inject unintended OAuth query parameters into the Auth0 authorization request. Successful exploitation may result in tokens being issued with unintended parameters ### Am I Affected? You are affected if you meet the following preconditions: - Applications using the auth0/nextjs-auth0 SDK version prior to 4.13.0 ### Affected product and versions Auth0/nextjs-auth0 versions >= 4.9.0 and < 4.13.0 ### Resolution Upgrade Auth0/nextjs-auth0 version to v4.13.0 ### Acknowledgements Okta would like to thank Joshua Rogers (MegaManSec) for their discovery and responsible disclosure.

### Description In the Okta Java SDK, race conditions may arise from concurrent requests using the ApiClient class. This could cause a status code or response header from one request’s response to influence another request’s response. ### Affected product and versions You may be affected if you meet the following preconditions: - Using the Okta Java SDK between versions 11.0.0 and 20.0.0, and - Implementing a multithreaded application with the ApiClient class where the response status code is used in access control flows ### Resolution Upgrade Okta/okta-sdk-java to versions 21.0.0 or greater.

1Panel versions 1.10.33 - 2.0.15 contain a cross-site request forgery (CSRF) vulnerability in the web port configuration functionality. The port-change endpoint lacks CSRF defenses such as anti-CSRF tokens or Origin/Referer validation. An attacker can craft a malicious webpage that submits a port-change request; when a victim visits it while authenticated, the browser includes valid session cookies and the request succeeds. This allows an attacker to change the port on which the 1Panel web service listens, causing loss of access on the original port and resulting in service disruption or denial of service, and may unintentionally expose the service on an attacker-chosen port.

1Panel versions 1.10.33 through 2.0.15 contain a cross-site request forgery (CSRF) vulnerability in the panel name management functionality. The affected endpoint does not implement CSRF defenses such as anti-CSRF tokens or Origin/Referer validation. An attacker can craft a malicious webpage that submits a panel-name change request; if a victim visits the page while authenticated, the browser includes valid session cookies and the request succeeds. This allows a remote attacker to change the victim’s panel name to an arbitrary value without consent.

### Description When using affected versions of the Next.js SDK, simultaneous requests on the same client may result in improper lookups in the TokenRequestCache for the request results. ### Am I Affected? You are affected if you meet the following preconditions: - Applications using the auth0/nextjs-auth0 SDK with a singleton client instance, versions 4.11.0, 4.11.1, and 4.12.0. ### Affected product and versions Auth0/nextjs-auth0 v4.11.0, v4.11.1, and v4.12.0. ### Resolution Upgrade Auth0/nextjs-auth0 version to v4.11.2 or v4.12.1 ### Acknowledgements Okta would like to thank Joshua Rogers for their discovery and responsible disclosure.

### Description In the Okta Java SDK, specific multithreaded implementations may encounter memory issues as threads are not properly cleaned up after requests are completed. Over time, this can degrade performance and availability in long-running applications and may result in a denial-of-service condition under sustained load. ### Affected product and versions You may be affected by this vulnerability if you meet the following preconditions: - Using the Okta Java SDK between versions 21.0.0 and 24.0.0, and - Implementing a long-running application using the ApiClient in a multi-threaded manner. ### Resolution Upgrade Okta/okta-sdk-java to versions 24.0.1 or greater. ### Acknowledgement Okta would like to thank Andrew Pikler (pyckle) for their discovery and responsible disclosure.

## Summary The `download_media` method in Pyrofork does not sanitize filenames received from Telegram messages before using them in file path construction. This allows a remote attacker to write files to arbitrary locations on the filesystem by sending a specially crafted document with path traversal sequences (e.g., `../`) or absolute paths in the filename. --- ## Details When downloading media, if the user does not specify a custom filename (which is the common/default usage), the method falls back to using the `file_name` attribute from the media object. This attribute originates from Telegram's `DocumentAttributeFilename` and is controlled by the message sender. ### Vulnerable Code Path **Step 1**: In `pyrogram/methods/messages/download_media.py` (lines 145-151): ```python media_file_name = getattr(media, "file_name", "") # Value from Telegram message directory, file_name = os.path.split(file_name) # Split user's path parameter file_name = file_name or media_file_name o...