Most recent entries from all

bdu:2025-13248

2026-10-02T12:35:38.291654+00:00

bdu:2025-13248

EUVD-2026-224408

2026-10-02T12:35:38.291689+00:00

EUVD-2026-224408

fkie_cve-2025-27591

2026-10-02T12:35:38.291703+00:00

A privilege escalation vulnerability existed in the Below service prior to v0.9.0 due to the creation of a world-writable directory at /var/log/below. This could have allowed local unprivileged users to escalate to root privileges through symlink attacks that manipulate files such as /etc/shadow.

GHSA-9mc5-7qhg-fp3w — Below has Incorrect Permission Assignment for Critical Resource

2026-10-02T12:35:38.291732+00:00

Affected: crates.io: below

### Impact A privilege escalation vulnerability existed in the Below service prior to v0.9.0 due to the creation of a world-writable directory at /var/log/below. This could have allowed local unprivileged users to escalate to root privileges through symlink attacks that manipulate files such as /etc/shadow.

### Patches https://github.com/facebookincubator/below/commit/10e73a21d67baa2cd613ee92ce999cda145e1a83

This is included in version 0.9.0

### Workarounds Change the permission on `/var/log/below` manually

### References https://www.facebook.com/security/advisories/cve-2025-27591 https://www.cve.org/CVERecord?id=CVE-2025-27591

openSUSE-SU-2026:10194-1 — cargo-audit-advisory-db-20260213-1.1 on GA media

2026-10-02T12:35:38.291762+00:00

cargo-audit-advisory-db-20260213-1.1 on GA media

RUSTSEC-2025-0149 — World Writable Directory in /var/log/below Allows Local Privilege Escalation

2026-10-02T12:35:38.291779+00:00

Affected: crates.io: below

Below is a tool for recording and displaying system data like hardware utilization and cgroup information on Linux.

## Symlink Attack in `/var/log/below/error_root.log`

Below's systemd service runs with full `root` privileges. It attempts to create a world-writable directory in `/var/log/below`. Even if the directory already exists, the Rust code ensures [1] that it receives mode 0777 permissions:

``` if perm.mode() & 0o777 != 0o777 { perm.set_mode(0o777); match dir.set_permissions(perm) { Ok(()) => {} Err(e) => { bail!( "Failed to set permissions on {}: {}", path.to_string_lossy(), e ); } } } ```

This logic leads to different outcomes depending on the packaging on Linux distributions:

- in openSUSE Tumbleweed the directory was packaged with 01755 permissions (below.spec [2] line 73), thus causing the `set_permissions()` call to run, resulting in a directory with mode 0777 during runtime. - in Gentoo Linux the directory is created with mode 01755 resulting in the same outcome as on openSUSE Tumbleweed (below.ebuild [3]). Where the 01755 mode is exactly coming from is not fully clear, maybe the `cargo` build process assigns these permissions during installation. - in Fedora Linux the directory is packaged with 01777 permissions, thus the `set_permissions()` code will not run, because the `if` condit…