ghsa

Prototype pollution vulnerability in `mergeDeep` after merging results of two standard schema validations with the same key. Due to the ordering of merging, there must be an `any` type that is set as a `standalone` guard, to allow for the `__proto__` prop to be merged. When combined with GHSA-8vch-m3f4-q8jf this allows for a full RCE by an attacker. ### Impact Routes with more than 2 standalone schema validation, eg. zod Example vulnerable code: ```typescript import { Elysia } from "elysia" import * as z from "zod" const app = new Elysia() .guard({ schema: "standalone", body: z.object({ data: z.any() }) }) .post("/", ({ body }) => ({ body, win: {}.foo }), { body: z.object({ data: z.object({ messageId: z.string("pollute-me"), }) }) }) ``` ### Patches Patched by 1.4.17 (https://github.com/elysiajs/elysia/pull/1564) Reference commit: - https://github.com/elysiajs/elysia/pull/1564/commits/26935bf76ebc43b4a43d48b173fc853de43bb51e - https://github.com/elysiaj...

## Summary An Open Redirect vulnerability exists in Taguette that allows attackers to craft malicious URLs that redirect users to arbitrary external websites after authentication. This can be exploited for phishing attacks where victims believe they are interacting with a trusted Taguette instance but are redirected to a malicious site designed to steal credentials or deliver malware. **Severity:** Medium to High --- ## Details The application accepts a user-controlled `next` parameter and uses it directly in HTTP redirects without any validation. The vulnerable code is located in two places: ### Location 1: Login Handler (`taguette/web/views.py`, lines 140-144) ```python def _go_to_next(self): next_ = self.get_argument('next', '') if not next_: next_ = self.reverse_url('index') return self.redirect(next_) # ← No validation of next_ parameter ``` This method is called after successful login (line 132) and when an already-logged-in user visits the login pa...

### Summary A directory traversal vulnerability in NiceGUI's `App.add_media_files()` allows a remote attacker to read arbitrary files on the server filesystem. ### Details Hello, I am Seungbin Yang, a university student studying cybersecurity. While reviewing the source code of the repository, I discovered a potential vulnerability and successfully verified it with a PoC. The `App.add_media_files(url_path, local_directory)` method allows users to serve media files. However, the implementation lacks proper path validation. ```python def add_media_files(self, url_path: str, local_directory: Union[str, Path]) -> None: @self.get(url_path.rstrip('/') + '/{filename:path}') def read_item(request: Request, filename: str, nicegui_chunk_size: int = 8192) -> Response: filepath = Path(local_directory) / filename if not filepath.is_file(): raise HTTPException(status_code=404, detail='Not Found') return get_range_response(filepath, request, chunk_siz...

### Summary A state consistency bug in `x/costaking` can leave a BTC delegator with non-zero `ActiveSatoshis` (Phatom Stake) even after they have fully unbonded their BTC delegation, if their Finality Provider (FP) drops out of the active set in the exact same babylon block height. This creates a “phantom stake”: the delegator’s BTC capital is withdrawn, the FP is inactive, but costaking continues to treat the delegation as active BTC stake allowing ongoing rewards accrual without backing BTC. ### Impact An address can keep earning costaking rewards with zero BTC staked. Reported by @BottyBott.

### Summary A vulnerability exists in Babylon’s BLS vote extension processing where a malicious active validator can submit a VoteExtension with the `block_hash` field omitted from the protobuf serialization. Because protobuf fields are optional, unmarshalling succeeds but leaves `BlockHash` as nil. Babylon then dereferences this nil pointer in consensus-critical code paths (notably `VerifyVoteExtension`, and also proposal-time vote verification), causing a runtime panic. ### Impact Intermittent validator crashes at epoch boundaries, which would slow down the creation of the epoch boundary block. ### Finder Vulnerability discovered by: - @GrumpyLaurie55348

### Summary A potential vulnerability exists in ZITADEL's logout endpoint in login V2. This endpoint accepts serval parameters including a `post_logout_redirect`. When this parameter is specified, users will be redirected to the site that is provided via this parameter. ZITADEL's login UI did not ensure that this parameter contained an allowed value and even executed passed scripts. ### Impact Zitadel is vulnerable to a DOM-Based XSS vulnerability. More specifically, the /logout endpoint insecurely routed to value that is supplied in the post_logout_redirect GET parameter. As a result, malicious JS code could be executed on Zitadel users’ browsers, in the Zitadel V2 Login domain. An unauthenticated remote attacker can exploit this DOM-based XSS vulnerability, and thus, execute malicious JavaScript code on behalf of Zitadel users. By doing so, such an attacker could reset the password of their victims, and take over their accounts. Note that for this to work, multiple user sessions...

### Summary A potential vulnerability exists in ZITADEL's password reset mechanism in login V2. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user. ### Impact If an attacker can manipulate these headers (e.g., via host header injection), they could cause ZITADEL to generate a password reset link pointing to a malicious domain controlled by the attacker. If the user clicks this manipulated link in the email, the secret reset code embedded in the URL can be captured by the attacker. This captured code could then be used to reset the user's password and gain unauthorized access to their account. It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled. ### Affected Versions Systems using the login UI (v2) and running one ...

### Summary Zitadel is vulnerable to an unauthenticated, full-read SSRF vulnerability. An unauthenticated remote attacker can force Zitadel into making HTTP requests to arbitrary domains, including internal addresses. The server then returns the upstream response to the attacker, enabling data exfiltration from internal services. ### Impact ZITADEL Login UI (V2) was vulnerable to service URL manipulation through the x-zitadel-forward-host header. The service URL resolution logic treated the header as a trusted fallback for all deployments, including self-hosted instances. This allowed unauthenticated attacker to force the server to make outbound requests and read the responses, reaching internal services, exfiltrating data, and bypassing IP-based or network-segmentation controls. ### Affected Versions Systems using the login UI (v2) and running one of the following versions are affected: - **v4.x**: `4.0.0-rc.1` through `4.7.0` ### Patches The vulnerability has been addressed ...

### Summary Symbolic links (_symlinks_) could be used to access files or directories outside the intended web root folder. ### Details SWS generally does not prevent symlinks from escaping the web server’s root directory. Therefore, if a malicious actor gains access to the web server’s root directory, they could create symlinks to access other files outside the designated web root folder either by URL or via the directory listing. ### PoC - Serve a directory (web root) with SWS. - Create a symlink inside the web root that points to a file outside the web root. e.g. `ln -s escape.txt $HOME/.bashrc` - Open `http://localhost/escape.txt` in your browser. - The file content will be served. ### Impact Any web server that runs with elevated privileges (e.g., root/administrator) and handles user-supplied file uploads is primarily impacted.

## Summary Arbitrary Remote Code Execution on development server via unsafe dynamic imports in `@vitejs/plugin-rsc` server function APIs (`loadServerAction`, `decodeReply`, `decodeAction`) when integrated into RSC applications that expose server function endpoints. ## Impact Attackers with network access to the development server can execute arbitrary JavaScript code with Node.js privileges, allowing them to read/modify files, exfiltrate sensitive data (source code, environment variables, credentials), or pivot to other internal services. While this affects development servers only, the risk increases when using `vite --host` to expose the server on all network interfaces. ## Details In the example RSC application provided in Proof of Concept, the server handles server function call through API such as `loadServerAction`, `decodeReply`, `decodeAction` with http request's header and body as inputs: https://github.com/vitejs/vite-plugin-react/blob/c8af971f57f12d0190d7fd8829a429f5e...