Minor Changes
-
#993
17b501aThanks @CorentinTh! - Breaking change regarding webhook URLsAdded SSRF protection for webhook URLs. Webhook URLs are now validated to ensure they do not point to private or reserved IP addresses, preventing potential server-side request forgery attacks.
So webhooks pointing to private IPs (e.g.http://192.168.0.1/some/stuff), or with domains resolving to private IPs (e.g.http://myservice.local/some/stuff) will be blocked unless explicitly allowed.Two new configuration options are available:
WEBHOOK_SSRF_PROTECTION_ENABLEDSet tofalseto fully disable SSRF protection. This is not recommended, prefer using the allowlist below instead.WEBHOOK_URL_ALLOWED_HOSTNAMESA comma-separated list of hostnames (IP addresses or domain names) that are explicitly trusted and exempt from SSRF checks (e.g. internal services you control).
Addressing GHSA-cjw7-qg95-58mq, credit to @Toothless5143 for the responsible disclosure.
Patch Changes
-
#986
884d470Thanks @CorentinTh! - Removed currently unusedexpiresAtplaceholder fields in the internal API key creation endpoint to avoid confusions, as non-ui (so non-standard) creation of API keys can set an expiration date, which is not currently enforced by the system.Addressing GHSA-866c-mc22-wvv5, credit to @Toothless5143 for the responsible disclosure.
-
#992
9039b48Thanks @CorentinTh! - Properly return a "document already has tag" error when trying to add a tag to a document that already has it, instead of a generic 500 error when using an hosted Turso db. -
#992
9039b48Thanks @CorentinTh! - Api now returns a 409 status code instead of a 400 when either creating a tag that already exists or adding a tag to a document that already has it. -
#995
327eda0Thanks @CorentinTh! - Properly sanitize user name before including it in the email content to prevent potential XSS or html injection attacks.Addressing GHSA-6f8x-2rc9-vgh4, credit to @Toothless5143 for the responsible disclosure.
-
#981
f336b84Thanks @CorentinTh! - Moved the theme picker to the user settings dropdown -
#984
8fe222bThanks @CorentinTh! - App environment configuration validation is now a bit stricter, with slightly different error messages. And the following specific changes:- Boolean env variables previously considered non-truthy values as
false. Now they will throw a validation error if the value is not a valid boolean-ish value AUTH_PROVIDERS_CUSTOMSjson parsing now accepts only valid boolean values for thepkceproperty, while before it accepted any non-true value asfalse- Stricter
AUTH_FORBIDDEN_EMAIL_DOMAINSdomain validation
- Boolean env variables previously considered non-truthy values as