CVE-2021-4034

What it actually does

This is the Polkit pkexec local privilege-escalation flaw commonly known as PwnKit. A logic error in pkexec handling of an empty argument vector allows out-of-bounds read/write behavior that can cause pkexec to reintroduce unsafe environment variables that are normally stripped for setuid-root programs. A local unprivileged user can abuse this to load attacker-controlled shared-library code through mechanisms such as gconv and execute code as root. The vulnerable component is desktop.org/polkit/polkit, fixed upstream in commit a2bf5c9c83b6ae46cbd5c779d3055bff81ded683.

Why it matters to the business

Successful exploitation gives an attacker full administrative control of a Linux system after they have any local foothold, such as a compromised low-privilege account, web shell, container escape path, or malicious insider access. Because Polkit is widely deployed across Linux distributions and this issue is in CISA KEV with very high EPSS probability and active exploitation, unpatched systems materially increase the risk of server takeover, credential theft, persistence, lateral movement, security tooling disablement, and service disruption. The CISA remediation deadline was 2022-07-18, so remaining exposure should be treated as overdue high-priority technical debt.

How an attack unfolds

An attacker first obtains the ability to execute code as a non-root local user on a Linux host. They then invoke pkexec in an abnormal way, specifically with an empty argument vector, causing pkexec to read and write outside the intended argv array and treat attacker-controlled environment data as trusted program state. The attacker uses this condition to restore dangerous environment variables that setuid programs normally remove, commonly involving GCONV_PATH, CHARSET, and a malicious gconv module. When pkexec runs with root privileges, it loads the attacker-controlled shared object and executes the attacker's code as root. Public exploit code is mature, reliable, and has been used in the wild; no confirmed named actor attribution is required for operational prioritization, and the supplied actor labels appear to describe vulnerability categories rather than confirmed threat groups.

How to fix it

Upgrade Polkit/pkexec to a vendor-fixed package immediately. For upstream desktop.org/polkit/polkit, the fix is commit a2bf5c9c83b6ae46cbd5c779d3055bff81ded683. Prefer distribution security updates rather than building manually, because package versions and backports vary by Linux vendor. If immediate patching is not possible, remove the setuid bit from pkexec as a temporary mitigation using a vendor-approved emergency procedure, for example chmod 0755 /usr/bin/pkexec or chmod u-s /usr/bin/pkexec, understanding this may break legitimate workflows that depend on pkexec. Restrict local shell access, harden web applications and service accounts, and monitor for abuse until patching is complete. Re-enable normal permissions only after installing a fixed package.

How to confirm the fix worked

Confirm the installed Polkit package is at or above the vendor-fixed version for each Linux distribution, or that the upstream source contains commit a2bf5c9c83b6ae46cbd5c779d3055bff81ded683. Verify /usr/bin/pkexec exists and is provided by the patched package. Check package metadata with tools such as rpm -q --changelog polkit, dpkg -l policykit-1 polkitd, apt-cache policy policykit-1, yum/dnf updateinfo, or vendor vulnerability scanners. Validate that temporary mitigation, if used, removed the setuid bit from /usr/bin/pkexec, and document any operational impact. Vulnerability scanners should no longer report vulnerable Polkit packages, and controlled exploit validation in an isolated test environment should fail to obtain root.

Typical attack path

1. Gain local command execution as an unprivileged Linux user through phishing, stolen credentials, exposed service exploitation, web shell, or insider access.
2. Check whether pkexec is present and setuid-root, typically at /usr/bin/pkexec.
3. Stage exploit artifacts such as a malicious shared object, gconv-modules file, and GCONV_PATH-related directory or file names in a writable directory such as /tmp, /dev/shm, or the current working directory.
4. Execute pkexec with a malformed empty argument vector and crafted environment variables.
5. Cause pkexec to load attacker-controlled code through the gconv mechanism while running with root privileges.
6. Spawn a root shell, add privileged users or keys, deploy persistence, dump credentials, disable defenses, or move laterally.

How to detect it

Focus on endpoint, audit, EDR, process accounting, shell history, and filesystem telemetry. Useful log sources include auditd execve records, Linux process creation telemetry, EDR command-line and environment capture, syslog/auth logs, package manager logs, file integrity monitoring, and filesystem scans of writable directories. Look for pkexec executions by non-root users that are followed immediately by root shells, user creation, sudoers modification, SSH key placement, credential dumping, defense evasion, or outbound connections. Hunt for exploit staging artifacts such as GCONV_PATH=., gconv-modules, suspicious shared objects, and pwnkit-themed filenames in /tmp, /var/tmp, /dev/shm, and user-writable paths. Failed or test exploitation may create pkexec error messages referencing invalid SHELL values, CHARSET, or gconv conversion failures. Because successful exploitation may leave little native logging, absence of pkexec logs does not prove absence of compromise; correlate process ancestry, file creation times, and privilege changes around suspicious local-user activity.

• /usr/bin/pkexec
• GCONV_PATH=.
• GCONV_PATH=/tmp
• GCONV_PATH=/var/tmp
• GCONV_PATH=/dev/shm
• CHARSET=PWNKIT
• SHELL=whatever
• gconv-modules
• pwnkit.so
• pwnkit
• PwnKit
• /tmp/GCONV_PATH=.
• /var/tmp/GCONV_PATH=.
• /dev/shm/GCONV_PATH=.
• /tmp/gconv-modules
• /var/tmp/gconv-modules
• /dev/shm/gconv-modules
• /tmp/pwnkit.so
• /var/tmp/pwnkit.so
• /dev/shm/pwnkit.so
• The value for the SHELL variable was not found the /etc/shells file
• pkexec must be setuid root
• pkexec --version
• audit: EXECVE.*pkexec
• comm="pkexec"
• exe="/usr/bin/pkexec"

What your security team should do

• Prioritize remediation on all Linux servers, workstations, appliances, golden images, containers with host-level pkexec exposure, and cloud images because the issue is KEV-listed, actively exploited, and has a very high EPSS score.
• Patch Polkit using vendor security updates; where source builds are used, ensure commit a2bf5c9c83b6ae46cbd5c779d3055bff81ded683 or an equivalent fix is present.
• If patching cannot be completed immediately, temporarily remove the setuid bit from /usr/bin/pkexec and track affected systems as exceptions until fully remediated.
• Search for exploitation artifacts in writable directories, especially /tmp, /var/tmp, /dev/shm, and user home directories, and review historical audit, EDR, shell, and process telemetry for suspicious pkexec execution.
• Add detections for pkexec executions with unusual environment variables, missing or abnormal argv, gconv-related artifacts, or root shells spawned shortly after pkexec.
• Rebuild or refresh long-lived Linux images and templates so newly provisioned systems do not reintroduce vulnerable Polkit packages.
• Treat confirmed exploitation as full host compromise: isolate the host, preserve evidence, rotate credentials and keys exposed on the system, hunt for persistence, and consider rebuild from trusted media.