ghsa

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.

An SQL injection risk was identified in the module list filter within course search.

Description information displayed in the site administration live log required additional sanitizing to prevent a stored XSS risk.

The question bank filter required additional sanitizing to prevent a reflected XSS risk.

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.

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

### Summary A bypass was found for the security feature **trustedOrigins**. This works for wild card or absolute URLs trustedOrigins configs and opens the victims website to a **Open Redirect** vulnerability, where it can be used to steal the **reset password token** of a victims account by changing the "callbackURL" parameter value to a website owned by the attacker. ### Details #### Absolute URLs The issue here appears in the **middleware**, [specifically](https://github.com/better-auth/better-auth/blob/ddebd0358d74376ea64541512d0167dd4377f182/packages/better-auth/src/api/middlewares/origin-check.ts#L53). This protection is not sufficiente and it allows attackers to get a open redirect, by using the payload `/\/example.com`. We can check this is a valid URL ( or it will be a valid URL because the URL parser fix it for us ), by checking the image bellow:  ```typescript // trustedOrigins = [ ...