ghsa

### Impact Versions of OpenPubkey library prior to 0.10.0 contained a vulnerability that would allow a specially crafted JWS to bypass signature verification. ### Patches Upgrade to v0.10.0 or greater. This vulnerability is not present in versions of OpenPubkey after v0.9.0. ### References [CVE-2025-3757 ](https://www.cve.org/CVERecord?id=CVE-2025-3757)

In Flask 3.1.0, the way fallback key configuration was handled resulted in the last fallback key being used for signing, rather than the current signing key. Signing is provided by the `itsdangerous` library. A list of keys can be passed, and it expects the last (top) key in the list to be the most recent key, and uses that for signing. Flask was incorrectly constructing that list in reverse, passing the signing key first. Sites that have opted-in to use key rotation by setting `SECRET_KEY_FALLBACKS` are likely to unexpectedly be signing their sessions with stale keys, and their transition to fresher keys will be impeded. Sessions are still signed, so this would not cause any sort of data integrity loss.

### Impact The 'Send email' workflow does not HTML encode the user-provided field values in the sent email message, making any form with this workflow configured vulnerable, as it allows sending the message from a trusted system and address (potentially bypassing spam and email client security systems). ### Patches This issue affects all (supported) versions Umbraco Forms and is patched in 13.4.2 and 15.1.2. ### Workarounds Unpatched or unsupported versions can workaround this issue by using the 'Send email with template (Razor)' workflow instead or [writing a custom workflow type](https://docs.umbraco.com/umbraco-forms/developer/extending/adding-a-workflowtype). To avoid accidentally using the vulnerable workflow again, the `SendEmail` workflow type can be removed using the following composer (tested on Umbraco 10, 13, 14 and 15): ```c# using Umbraco.Cms.Core.Composing; using Umbraco.Forms.Core.Providers.Extensions; using Umbraco.Forms.Core.Providers.WorkflowTypes; internal sealed...

### Summary Users with limited sudo privileges (e.g. execution of a single command) can list sudo privileges of other users using the `-U` flag. This doesn't happen with the original sudo. ### PoC The initial test has been done in a container running Ubuntu 24.04 and installing [oxidizr](https://github.com/jnsgruk/oxidizr), running sudo-rs 0.2.2. A user (bob) has been added with only ps command executable through sudo: ``` root ALL=(ALL:ALL) ALL bob ALL=(ALL:ALL) /usr/bin/ps ``` The user is not able to read the `/etc/sudoers` file and running `sudo -l -Uroot` with original sudo (version 1.9.15p5) causes the following error: ``` Sorry, user bob is not allowed to execute 'list' as root on 43d4aed3cdbd. ``` The same command with sudo-rs is run without denying the execution: ``` User root may run the following commands on 43d4aed3cdbd: (ALL : ALL) ALL ``` The same happens for other non-root users: ``` bob@43d4aed3cdbd:~$ sudo -l -Ufoo User foo may run the following com...

### TL;DR This vulnerability affects all Kirby sites that use the `snippet()` helper or `$kirby->snippet()` method with a dynamic snippet name (such as a snippet name that depends on request or user data). Sites that only use fixed calls to the `snippet()` helper/`$kirby->snippet()` method (i.e. calls with a simple string for the snippet name) are *not* affected. ---- ### Introduction Kirby's `snippet()` helper and `$kirby->snippet()` method (in the following abbreviated to the `snippet()` helper) allow to load PHP snippet files that are normally stored in the `site/snippets` folder or registered by plugins through the `snippets` plugin extension. If the `snippet()` helper is called with an arbitrary snippet name, Kirby first checks if a file with this name exists in the snippets root (which defaults to `site/snippets`). This logic was vulnerable against path traversal attacks. By using special elements such as `..` and `/` separators, attackers can escape outside of the restric...

### TL;DR This vulnerability affects all Kirby setups that use PHP's built-in server. Such setups are commonly only used during local development. Sites that use other server software (such as Apache, nginx or Caddy) are *not* affected. ---- ### Introduction For use with PHP's built-in web server, Kirby provides a `router.php` file. The router delegates requests to static files to PHP so that assets and other static files in the document root can be accessed by the browser. This logic was vulnerable against path traversal attacks. By using special elements such as `..` and `/` separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the `../` sequence, which in most modern operating systems is interpreted as the parent directory of the current location. ### Impact The missing path traversal check allowed attackers to navigate all files on the server that were a...

### TL;DR This vulnerability affects all Kirby sites that use the `collection()` helper or `$kirby->collection()` method with a dynamic collection name (such as a collection name that depends on request or user data). Sites that only use fixed calls to the `collection()` helper/`$kirby->collection()` method (i.e. calls with a simple string for the collection name) are *not* affected. ---- ### Introduction Kirby's `collection()` helper and `$kirby->collection()` method (in the following abbreviated to the `collection()` helper) allow to load PHP logic files that are normally stored in the `site/collections` folder or registered by plugins through the `collections` plugin extension. If the `collection()` helper is called with an arbitrary collection name, Kirby first checks if a file with this name exists in the collections root (which defaults to `site/collections`). This logic was vulnerable against path traversal attacks. By using special elements such as `..` and `/` separator...

An issue was discovered in post.php in bootstrap-multiselect (aka Bootstrap Multiselect) 1.1.2. A PHP script in the source code echoes arbitrary POST data. If a developer adopts this structure wholesale in a live application, it could create a Reflective Cross-Site Scripting (XSS) vulnerability exploitable through Cross-Site Request Forgery (CSRF).

An issue was discovered in OXID eShop before 7. CMS pages in combination with Smarty may display user information if a CMS page contains a Smarty syntax error.

### Summary Users with no (or very limited) sudo privileges can determine whether files exists in folders that they otherwise cannot access using `sudo --list <pathname>`. ### PoC As root: ``` # mkdir /tmp/foo # chmod a-rwx /tmp/foo # touch /tmp/foo/secret_file ``` As a user without any (or limited) sudo rights: ``` $ sudo --list /tmp/foo/nonexistent_file sudo-rs: '/tmp/foo/nonexistent_file': command not found $ $ sudo --list /tmp/foo/secret_file sudo-rs: Sorry, user eve may not run sudo on host. ``` I.e. the user can distinguish whether files exist. ### Related Original sudo (vulnerable version tested by us: 1.9.15p5) exhibited similar behaviour for files with the executable bit set. ### Impact Users with local access to a machine can discover the existence/non-existence of certain files, revealing potentially sensitive information in the file names. This information can also be used in conjunction with other attacks. ### Credits This issue was identified by sudo-rs developer Ma...