ghsa

Inserts/JSX expressions inside illegal inlined JSX fragments lacked escaping, allowing user input to be rendered as HTML when put directly inside JSX fragments. For instance, `?text=<svg/onload=alert(1)>` would trigger XSS here. ```js const [text] = createResource(() => { return new URL(getRequestEvent().request.url).searchParams.get("text"); }); return ( <> Text: {text()} </> ); ```

### Summary In certain Subsonic API endpoints, authentication can be bypassed by using a non-existent username combined with an empty (salted) password hash. This allows read-only access to the server’s resources, though attempts at write operations fail with a “permission denied” error. ### Details A flaw in the authentication check process allows an attacker to specify any arbitrary username that does not exist on the system, along with a salted hash of an empty password. Under these conditions, Navidrome treats the request as authenticated, granting access to various Subsonic endpoints without requiring valid credentials. ### Proof of Concept (PoC) 1. Generate a random salt: ```javascript // e.g., salt = "x1vbudn1m6d" Math.random().toString(36).substring(2, 15) ``` 2. Calculate the MD5 hash of an empty password plus the salt: ```shell # Using the example salt above echo -n "x1vbudn1m6d" | md5sum 81f0c0fb5d202ab0d012e6eaeb722d79 - ``` 3. Send a re...

### Impact Only users that has configured a JupyterHub installation to use the authenticator class `LTI13Authenticator` are influenced. LTI13Authenticator that was introduced in `jupyterhub-ltiauthenticator` 1.3.0 wasn't validating JWT signatures. This is believed to allow the LTI13Authenticator to authorize a forged request granting access to existing and new user identities. ### Patches None. ### Workarounds None. ### References - [This code segment](https://github.com/jupyterhub/ltiauthenticator/blob/3feec2e81b9d3b0ad6b58ab4226af640833039f3/ltiauthenticator/lti13/validator.py#L122-L164) didn't validate a JWT signature.

### Impact When parsing compact JWS or JWE input, go-jose could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of '.' characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. ### Patches Version 4.0.5 fixes this issue ### Workarounds Applications could pre-validate payloads passed to go-jose do not contain an excessive number of '.' characters. ### References This is the same sort of issue as in the golang.org/x/oauth2/jws package as CVE-2025-22868 and Go issue https://go.dev/issue/71490.

Separate Groups mode restrictions were not factored into permission checks before allowing viewing or deletion of responses in Feedback activities.

Insufficient sanitizing in the TeX notation filter resulted in an arbitrary file read risk on sites where pdfTeX is available (such as those with TeX Live installed).

Insufficient capability checks made it possible to disable badges a user does not have permission to access.

Tags not expected to be visible to a user could still be discovered by them via the tag search page or in the tags block.

Additional checks were required to ensure trusttext is applied (when enabled) to glossary entries being restored.

The drag-and-drop onto image (ddimageortext) question type required additional sanitizing to prevent a stored XSS risk.