Polkit (formerly PolicyKit) is a component for controlling system-wide privileges in Unix-like operating systems. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to components such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy.

The Qualys Research Team has discovered and published a memory corruption vulnerability in polkit’s pkexec, a SUID-root program that is installed by default on every major Linux distribution. This vulnerability has been hiding in plain sight for more than 12 years. It’s easily exploited and allows any unprivileged user to gain root privileges on a vulnerable host. This vulnerability has been designated as CVE-2021-4034 and nicknamed “pwnkit”. The CVSSv3 base score is calculated to be a high 7.8 out of 10.0.

The team that manages Polkit has since patched the vulnerability in this commit on the public repository and the various Linux distributions have released updates that address the vulnerability.

To ensure airtight security, we need to constantly scan our systems for vulnerable versions of Polkit, and also monitor event logs to detect when there is a potential exploitation of this vulnerability.

Scanning vulnerable package

Wazuh can be used to proactively detect vulnerable versions of the Polkit package using its vulnerability detection module.

First, we enable the vulnerability detection module on Wazuh manager by modifying the <vulnerability-detector> block in the manager configuration file at /var/ossec/etc/ossec.conf:


We also enable the provider for our operating system in the manager configuration file. We use a CentOS endpoint, so we enable the provider for Red Hat because CentOS is the open source flavor of RHEL and they use the same packages (more on Wazuh compatibility matrix):

    <!-- RedHat OS vulnerabilities -->
    <provider name="redhat">

We restart the Wazuh manager to apply the changes:

# systemctl restart wazuh-manager

After the vulnerability scan has completed, the vulnerability appears as part of the inventory of the selected agent:

The vulnerability appears as part of the inventory of the selected agent

Detecting exploitation attempts

There is an indicator of compromise that can be used to detect exploitation attempts. Attempting to exploit this vulnerability in some cases will trigger the error message “...The value for the SHELL variable was not found the /etc/shells file [USER=root]...”. This error message is usually logged as part of the system logs and can be helpful in detecting exploitation attempts.

Wazuh by default monitors the system logs, therefore it can be configured to alert when there is an exploitation attempt. To do this, we create a custom rule on the Wazuh manager in the local rule file located at /var/ossec/etc/rules/local_rules.xml:

<group name="syslog">
  <rule id="111111" level="12">
    <match>The value for the SHELL variable was not found the /etc/shells file [USER=root]</match>
    <description>Possible attempt to exploit a local privilege escalation vulnerability in polkit pkexec (CVE-2021-4034) via unsecure environment variable injection.</description>

We restart the Wazuh manager to apply this rule:

# systemctl restart wazuh-manager

To test the rule, an exploitation script from GitHub is run on the target endpoint:

user2@ubuntu-client:~cd CVE-2021-4034/
# whoami

We confirm on the Wazuh dashboard that the alert has been triggered.

We confirm on the Wazuh dashboard that the alert has been triggered

More advanced attackers can exploit this vulnerability without leaving any trace in the system log, therefore, making it more difficult to detect. To address this challenge, we monitor all executed commands and system calls with the aid of auditd.

Auditd is the userspace component of the Linux Auditing System. It’s responsible for writing audit records to the disk.

Install auditd on the endpoint

Auditd is installed by default on all CentOS systems. If Auditd is not installed, the following command installs it on the monitored endpoint:

# sudo yum -y install auditd

In order to keep log of when pkexec is executed, or an attempt is made to download files, we append the following audit rules to /etc/audit/rules.d/audit.rules:

# echo "-w /usr/bin/pkexec -p x" >> /etc/audit/rules.d/audit.rules

# echo "-w /usr/bin/curl -p x" >> /etc/audit/rules.d/audit.rules

# echo "-w /usr/bin/wget -p -x" >> /etc/audit/rules.d/audit.rules

We reload the rules to apply the changes:

# auditctl -R /etc/audit/rules.d/audit.rules
# auditctl -l
-w /usr/bin/pkexec -p x

-w /usr/bin/curl -p x

-w /usr/bin/wget -p -x

Configure Wazuh manager to collect the logs and create a detection rule

We configure the Wazuh manager to monitor auditd logs by adding the following to the shared agent configuration file located at /var/ossec/etc/shared/default/agent.conf:


We create another detection rule on the Wazuh manager in /var/ossec/etc/rules/local_rules.xml to trigger when any of the indicators of compromise is logged by auditd:

<group name="pwnkit, attack,">
  <rule id="100010" level="12">
    <regex type="pcre2">(?i)name="\/usr\/bin\/pkexec".*="root"|https:\/\/raw\.githubusercontent\.com.*PwnKit|pwnkit</span></regex>
    <description>Possible attempt to exploit a local privilege escalation in polkit pkexec (CVE-2021-4034) via unsecure environment variable injection.</description>


Linux distributors have already released patches for this package. E.g:

A temporary mitigation can be applied if no patches are available for your operating system. This mitigation can be implemented by removing the SUID-bit from pkexec. This can be done by running the following command:

# chmod 0755 /usr/bin/pkexec


This article demonstrates how to scan for versions of Polkit’s pkexec that have the pwnkit vulnerability, and also how to detect potential exploitation attempts. The pwnkit vulnerability can be detected with the aid of the Wazuh vulnerability detection module which contains a comprehensive vulnerability database. The goal of detecting potential exploitation is achieved by creating custom Wazuh rules that monitor event logs for indicators of compromise.