Security
Headlines
HeadlinesLatestCVEs

Tag

#git

GHSA-56wx-66px-9j66: OPKSSH Vulnerable to Authentication Bypass

### Impact Versions of OpenPubkey library prior to 0.10.0 contained a vulnerability that would allow a specially crafted JWS to bypass signature verification. As OPKSSH depends on the OpenPubkey library for authentication, this vulnerability in OpenPubkey also applies to OPKSSH versions prior to 0.5.0 and would allow an attacker to bypass OPKSSH authentication. ### Patches The vulnerability does not exist in more recent versions of OPKSSH. his only impacts OPKSSH when used to verify ssh keys on a server, the OPKSSH client is unaffected. To remediate upgrade to a version of OPKSSH v0.5.0 or greater. To determine if you are vulnerable run on your server: ```bash opkssh --version ``` If the version is less than 0.5.0 you should upgrade. To upgrade to the latest version run: ```bash wget -qO- "https://raw.githubusercontent.com/openpubkey/opkssh/main/scripts/install-linux.sh" | sudo bash ``` ### References [CVE-2025-4658](https://www.cve.org/CVERecord?id=CVE-2025-4658) The upst...

ghsa
#vulnerability#linux#git#auth#ssh
GHSA-4grg-w6v8-c28g: Flask uses fallback key instead of current signing key

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.

GHSA-w9q3-g4p5-5q2r: sudo-rs Allows Low Privilege Users to Enumerate Privileges of Others

### 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...

GHSA-fw82-87p8-v6hp: Kirby vulnerable to path traversal of snippet names in the `snippet()` helper

### 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...

GHSA-9p3p-w5jf-8xxg: Kirby vulnerable to path traversal in the router for PHP's built-in server

### 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...

GHSA-x275-h9j4-7p4h: Kirby vulnerable to path traversal of collection names during file system lookup

### 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...

Google Is Using On-Device AI to Spot Scam Texts and Investment Fraud

Android’s “Scam Detection” protection in Google Messages will now be able to flag even more types of digital fraud.

iClicker Website Hacked with Fake CAPTCHA in ClickFix Attack

Popular student engagement platform iClicker’s website was compromised with a ClickFix attack. A fake “I’m not a robot”…

GHSA-98cv-wqjx-wx8f: sudo-rs Allows Low Privilege Users to Discover the Existence of Files in Inaccessible Folders

### 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...