How to Fix CVE-2021-4034: PwnKit Polkit pkexec Local Privilege Escalation

⚠️ CISA KEV: federal civilian agencies were required to remediate by 2022-07-18. PwnKit remains one of the most reliable Linux local privilege escalations ever published. Any unpatched host where a local user can run pkexec should be treated as already rooted.

What is CVE-2021-4034?

pkexec is a setuid-root helper from the polkit project that lets unprivileged users run programs as another user under predefined policy. The bug, disclosed by Qualys in January 2022, is in how pkexec walks its argv array. When invoked with zero arguments (argc == 0), the code reads past the end of argv and into the adjacent envp block, then writes back into the same memory. By controlling that crossover, a local attacker can inject an environment variable into pkexec's own (privileged) process and force it to execute attacker-controlled code as root.

The bug is in code that has been in polkit since the very first commit in May 2009. Practically every Linux distribution shipped a vulnerable build for over twelve years. A reliable exploit takes a few hundred lines of C and works without crashes on default installs.

If you have shell access on a Linux box, through SSH, a web shell, a compromised service account, or a malicious user with login rights, PwnKit is the path to root.

Am I affected?

Almost certainly yes, unless you patched in early 2022. Check the installed polkit version against your distribution's fixed package:

# Red Hat / CentOS / Rocky / Alma
rpm -q polkit

# Debian / Ubuntu
dpkg -l | grep -E "policykit-1|polkit"

# Arch
pacman -Q polkit

# SUSE
zypper info polkit

Compare to the fixed package for your distro:

| Distribution | First fixed package |

|---|---|

| RHEL 8 | polkit-0.115-13.el8_5.1 |

| RHEL 7 | polkit-0.112-26.el7_9.1 |

| Ubuntu 22.04 | policykit-1 0.105-31ubuntu0.1 |

| Ubuntu 20.04 | policykit-1 0.105-31ubuntu0.5 |

| Ubuntu 18.04 | policykit-1 0.105-26ubuntu1.3 |

| Debian 11 | policykit-1 0.105-31+deb11u1 |

| Debian 10 | policykit-1 0.105-25+deb10u1 |

| SUSE / openSUSE | polkit-0.114-3.18.1 or later (per SUSE-SU-2022:0175-1) |

A quick proof-of-exploit check (non-destructive): if you have python3 and want to verify, the Qualys advisory at https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt describes the technique. Do not run third-party PoC binaries on production hosts.

How to fix CVE-2021-4034

The fix is a one-package update on every supported distribution. Reboots are not required — pkexec is invoked per-call, so the new binary takes effect immediately.

1. Update the polkit package from your distribution's repositories:

   # RHEL / CentOS / Rocky / Alma / Fedora
   sudo dnf update polkit

   # Older Red Hat with yum
   sudo yum update polkit

   # Debian / Ubuntu
   sudo apt update && sudo apt install --only-upgrade policykit-1

   # SUSE / openSUSE
   sudo zypper update polkit

   # Arch
   sudo pacman -Syu polkit

1. Confirm the new version is installed and that pkexec itself was updated:

   pkexec --version
   ls -l $(which pkexec)

The binary should still be setuid root (-rwsr-xr-x). That is correct and expected; the fix is to the code inside, not to the permission bits.

1. No service restart is needed. pkexec is a setuid binary, not a daemon. Subsequent invocations pick up the patched code automatically.

If you can't patch immediately

The Qualys advisory documents one official temporary mitigation: remove the setuid bit from pkexec so the bug cannot be exploited for privilege escalation.

sudo chmod 0755 /usr/bin/pkexec

This works because the bug only matters when pkexec runs as root (i.e. setuid). Stripping the setuid bit removes the privilege boundary the exploit targets. Side effects: any legitimate user or script that invokes pkexec to elevate privileges will fail. On a server with no graphical session and no admin automation, this is usually acceptable; on a workstation, it will break some desktop privilege prompts.

Re-add the setuid bit after the package is updated:

sudo chmod 4755 /usr/bin/pkexec

There is no other vendor-recommended workaround. Disabling polkit entirely is not a supported mitigation.

How to verify the fix worked

1. Confirm the patched package is present:

   rpm -q polkit    # or dpkg -l | grep policykit-1

1. Look for evidence of past exploitation. Because PwnKit has been weaponized for years and leaves few obvious traces, focus on what an attacker would do after gaining root:

- Audit /etc/passwd and /etc/shadow for unfamiliar UID-0 accounts.

- Check /root/.ssh/authorized_keys and every user's ~/.ssh/authorized_keys for keys you did not add.

- Review /etc/sudoers and /etc/sudoers.d/ for unexpected entries.

- Inspect cron tables (crontab -l per user, /etc/cron.*, /var/spool/cron/) for unfamiliar jobs.

- Look for systemd services or timers added recently in /etc/systemd/system/.

- Search for setuid binaries created after January 2022:

     sudo find / -xdev -perm -4000 -newermt 2022-01-01 -type f 2>/dev/null

1. In auth/audit logs, look for pkexec invocations with unusual argv or environment, historical exploitation rarely leaves clean PwnKit-specific signatures, but unexpected pkexec traffic from non-admin users is worth investigating.

If you find any indicator of compromise, treat the host as fully owned. Rebuild from a known-clean image, rotate all credentials that touched the host (SSH keys, cloud API tokens, service account passwords, secrets in mounted volumes), and restore data only from backups dated before any suspicious activity.

Frequently asked questions

Related fixes

Other vulnerabilities in the same area that are worth patching alongside this one:

• How to Fix CVE-2021-3493: Local Privilege Escalation in linux kernel — Local Privilege Escalation in linux kernel
• How to Fix CVE-2021-22600: Critical Vulnerability in Kernel , Critical Vulnerability in Kernel
• How to Fix CVE-2021-22555: Out-of-Bounds Write in N/a Linux Kernel , Out-of-Bounds Write in N/a Linux Kernel

Is PwnKit a remote vulnerability?

No. CVE-2021-4034 requires the attacker to already have a local account or shell on the system. It is the privilege escalation half of an attack chain; a remote RCE in a separate service typically supplies the initial shell.

Does removing the setuid bit on pkexec break my system?

On servers, usually not, most server-side automation runs as root via sudo, not pkexec. On desktops, GUI privilege prompts that route through polkit will fail, which can break Software Update, NetworkManager admin actions, and similar tasks. Patch and restore the setuid bit as soon as the updated package is available.

The bug was in the code for twelve years. Am I compromised already?

You won't know without checking. Hosts that ran a vulnerable polkit and were reachable by any untrusted user (including via web RCE chains, container escapes, or compromised service accounts) should be treated as suspect and triaged with the IoC list above.

Containers, am I affected inside Docker?

Only if pkexec is installed inside the container and the container runs as a non-root user with shell access. Most minimal container images do not ship polkit. Check with which pkexec inside the container.

References

• Red Hat security advisory RHSB-2022-001: https://access.redhat.com/security/vulnerabilities/RHSB-2022-001
• Qualys disclosure advisory (PwnKit technical writeup): https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
• Upstream polkit fix commit: https://gitlab.freedesktop.org/polkit/polkit/-/commit/a2bf5c9c83b6ae46cbd5c779d3055bff81ded683
• Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2025869
• SUSE security update: https://www.suse.com/support/kb/doc/?id=000020564
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2021-4034
• CISA KEV catalog entry: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

*This guide was assembled from the Red Hat security bulletin, the Qualys disclosure advisory, the upstream polkit fix commit, the NVD record, and the CISA KEV listing on 2026-05-25. Always confirm against your distribution's security advisory before applying changes in production. Byline: Sai Kiran Pandrala.*