Vulnpedia
← All CVEs

CVE-2021-4034

HIGH 7.8 KNOWN EXPLOITED RANSOMWARE PoC CATALOGUED ALL-YEARS

Published 2022-01-28 · Last modified 2026-08-15 · redhat · NVD: Analyzed

A local privilege escalation vulnerability was found on polkit's pkexec utility. The pkexec application is a setuid tool designed to allow unprivileged users to run commands as privileged users according predefined policies. The current version of pkexec doesn't handle the calling parameters count correctly and ends trying to execute environment variables as commands. An attacker can leverage this by crafting environment variables in such a way it'll induce pkexec to execute arbitrary code. When successfully executed the attack can cause a local privilege escalation given unprivileged users administrative rights on the target machine.

ACTIVELY EXPLOITED

Confirmed exploited in the wild — in CISA KEV since 2022-06-27, linked to ransomware campaigns. Patch or mitigate now.

Exploitation likelihood

94.9%chance of exploitation in 30 days · 100th percentile

● In CISA KEV (2022-06-27)● Catalogued PoC◆ SSVC: exploitation active, automatable no

Impact if exploited

7.8CVSS 3.1 · HIGH · ADP

  • ConfidentialityHigh
  • IntegrityHigh
  • AvailabilityHigh

What an attacker needs

  • ⚠Access: Requires local access to the host
  • ⚠Privileges: Requires a low-privilege account
  • ✓User interaction: No user interaction needed
  • ✓Complexity: No special conditions — reliably repeatable

✓ lowers the bar for an attacker · ⚠ raises it

Proof of concept

Public PoC or exploit resources are catalogued below.

Listed by the named source; Vulnpedia has not tested these resources.

PoC data: JSON

Resource commands

searchsploit --cve CVE-2021-4034 && searchsploit -m 50689Fetch the ExploitDB PoC locally; review the code before running it.
curl -s https://vulnpedia.com/cve/CVE-2021-4034/poc.jsonMachine-readable PoC index for this CVE (for automation).

Search for new PoCs

Search GitHub now — results may be empty or unverified.

Tracked sources are checked weekly for the full archive, including PoCs published after the original disclosure. A later release appears after a tracked source lists it and a refresh succeeds.

Data snapshot:

Affected

Vendors Polkit Project Redhat Canonical Suse Oracle Siemens Starwindsoftware

Products Polkit Enterprise Linux Server Update Services For Sap Solutions Enterprise Linux Enterprise Linux Desktop Enterprise Linux Eus Enterprise Linux For Ibm Z Systems Enterprise Linux For Ibm Z Systems Eus Enterprise Linux For Power Big Endian Enterprise Linux For Power Little Endian Enterprise Linux For Power Little Endian Eus Enterprise Linux For Scientific Computing Enterprise Linux Server Enterprise Linux Server Aus Enterprise Linux Server Eus Enterprise Linux Server Tus Enterprise Linux Workstation Ubuntu Linux Enterprise Storage Linux Enterprise High Performance Computing Manager Proxy Manager Server Linux Enterprise Desktop Linux Enterprise Server Linux Enterprise Workstation Extension Http Server Zfs Storage Appliance Kit Sinumerik Edge Scalance Lpe9403 Firmware Scalance Lpe9403 Command Center Starwind Virtual San

Weakness (CWE)

  • CWE-787: (CWE-787|CWE-125)
  • CWE-125: Out-of-bounds read

CVSS vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References and research data (JSON)

Vendor product assessments

Showing 32 of 271 vendor product statements; 239 omitted. Read the full vendor advisory.

  • polkit-0:0.96-11.el6_10.2.i686 as a component of Red Hat Enterprise Linux Server (v. 6 ELS) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_10.2?arch=i686

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-0:0.112-26.el7_9.1.i686 as a component of Red Hat Enterprise Linux Client (v. 7) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_9.1?arch=i686

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-0:0.112-12.el7_3.1.src as a component of Red Hat Enterprise Linux Server AUS (v. 7.3) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_3.1?arch=src

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-0:0.112-18.el7_6.3.x86_64 as a component of Red Hat Enterprise Linux Server AUS (v. 7.6) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_6.3?arch=x86_64

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-0:0.112-18.el7_6.3.i686 as a component of Red Hat Enterprise Linux Server TUS (v. 7.6) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_6.3?arch=i686

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-0:0.112-22.el7_7.2.i686 as a component of Red Hat Enterprise Linux Server E4S (v. 7.7) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_7.2?arch=i686

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-devel-0:0.112-22.el7_7.2.x86_64 as a component of Red Hat Enterprise Linux Server TUS (v. 7.7) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_7.2?arch=x86_64

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-devel-0:0.112-26.el7_9.1.i686 as a component of Red Hat Enterprise Linux Server (v. 7) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_9.1?arch=i686

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-debuginfo-0:0.112-26.el7_9.1.x86_64 as a component of Red Hat Enterprise Linux Workstation (v. 7) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_9.1?arch=x86_64

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-devel-0:0.115-9.el8_1.2.x86_64 as a component of Red Hat Enterprise Linux BaseOS E4S (v. 8.1) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_1.2?arch=x86_64

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-debuginfo-0:0.115-11.el8_2.2.x86_64 as a component of Red Hat Enterprise Linux BaseOS EUS (v. 8.2) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_2.2?arch=x86_64

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-libs-0:0.115-11.el8_2.2.x86_64 as a component of Red Hat Enterprise Linux BaseOS EUS (v. 8.2) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_2.2?arch=x86_64

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-debugsource-0:0.115-11.el8_4.2.i686 as a component of Red Hat Enterprise Linux BaseOS EUS (v.8.4) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_4.2?arch=i686

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-libs-debuginfo-0:0.115-11.el8_4.2.ppc64le as a component of Red Hat Enterprise Linux BaseOS EUS (v.8.4) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_4.2?arch=ppc64le

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-debugsource-0:0.115-13.el8_5.1.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_5.1?arch=s390x

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-libs-debuginfo-0:0.115-13.el8_5.1.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8) · fixed

    Vendor assessment for this product only.

    pkg:rpm/redhat/[email protected]_5.1?arch=x86_64

    • vendor fix: For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 Vendor guidance
    • workaround: For customers who cannot update immediately and doesn't have Secure Boot feature enabled, the issue can be mitigated by executing the following steps: 1) Install required systemtap packages and dependencies as per - pointed by https://access.redhat.com/solutions/5441 2) Install polkit debug info: ~~~ debuginfo-install polkit ~~~ 3) Create the following systemtap script, and name it pkexec-block.stp: ~~~ probe process("/usr/bin/pkexec").function("main") { if (cmdline_arg(1) == "") raise(9); } ~~~ 4) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_pkexec_block pkexec_block.stp ~~~ 5) Ensure the module is loaded: ~~~ lsmod | grep -i stap_pkexec_block stap_pkexec_block 434176 0 ~~~ 6) Once polkit package was updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_pkexec_block ~~~ This mitigation doesn't work for Secure Boot enabled system as SystemTap would require an external compiling server to be able to sign the generated kernel module with a key enrolled into the Kernel's keyring.
    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • redhat-release-virtualization-host-0:4.3.21-1.el7ev.src as a component of RHEL 7-based RHEV-H for RHEV 4 (build requirements) · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=src

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • redhat-release-virtualization-host-0:4.3.21-1.el7ev.x86_64 as a component of RHEL 7-based RHEV-H for RHEV 4 (build requirements) · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=x86_64

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • libmetalink-0:0.1.3-7.el8.src as a component of Red Hat Virtualization 4 Hypervisor for RHEL 8 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=src

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • libmetalink-0:0.1.3-7.el8.x86_64 as a component of Red Hat Virtualization 4 Hypervisor for RHEL 8 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=x86_64

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • libmetalink-debuginfo-0:0.1.3-7.el8.x86_64 as a component of Red Hat Virtualization 4 Hypervisor for RHEL 8 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=x86_64

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • libmetalink-debugsource-0:0.1.3-7.el8.x86_64 as a component of Red Hat Virtualization 4 Hypervisor for RHEL 8 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=x86_64

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • wget-0:1.19.5-10.el8.src as a component of Red Hat Virtualization 4 Hypervisor for RHEL 8 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=src

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • wget-0:1.19.5-10.el8.x86_64 as a component of Red Hat Virtualization 4 Hypervisor for RHEL 8 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=x86_64

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • wget-debuginfo-0:1.19.5-10.el8.x86_64 as a component of Red Hat Virtualization 4 Hypervisor for RHEL 8 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=x86_64

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • wget-debugsource-0:1.19.5-10.el8.x86_64 as a component of Red Hat Virtualization 4 Hypervisor for RHEL 8 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=x86_64

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • redhat-release-virtualization-host-0:4.4.10-1.el8ev.x86_64 as a component of RHEL 8-based RHEV-H for RHEV 4 (build requirements) · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=x86_64

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • redhat-release-virtualization-host-content-0:4.4.10-1.el8ev.x86_64 as a component of RHEL 8-based RHEV-H for RHEV 4 (build requirements) · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/[email protected]?arch=x86_64

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • redhat-virtualization-host-image-update-placeholder-0:4.4.10-1.el8ev.noarch as a component of RHEL 8-based RHEV-H for RHEV 4 (build requirements) · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/redhat-virtualization-host-image-update-placeholder@4.4.10-1.el8ev?arch=noarch

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-devel as a component of Red Hat Enterprise Linux 9 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/polkit-devel

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit-libs as a component of Red Hat Enterprise Linux 9 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/polkit-libs

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00
  • polkit.src as a component of Red Hat Enterprise Linux 9 · known not affected

    Vendor assessment for this product only.

    Reason: vulnerable code not present

    pkg:rpm/redhat/polkit?arch=src

    Red Hat · CVE-2021-4034 · Updated 2026-08-07T01:07:56+00:00

Unverified PoC candidates

Catalogue matches for further research. These repositories have not been validated as working exploits.

184 candidates

Additional exploitation reports

Source-specific reports, separate from CISA KEV. Repeated observations from one source are not independent confirmations.

33 more source reports

Known Affected Software Configurations

VendorProductVersion range
Polkit ProjectPolkit< 121
RedhatEnterprise Linux Server Update Services For Sap Solutions7.6
RedhatEnterprise Linux Server Update Services For Sap Solutions7.7
RedhatEnterprise Linux8.0
RedhatEnterprise Linux Desktop7.0
RedhatEnterprise Linux Eus8.2
RedhatEnterprise Linux For Ibm Z Systems7.0
RedhatEnterprise Linux For Ibm Z Systems8.0
RedhatEnterprise Linux For Ibm Z Systems Eus8.2
RedhatEnterprise Linux For Ibm Z Systems Eus8.4
RedhatEnterprise Linux For Power Big Endian7.0
RedhatEnterprise Linux For Power Little Endian7.0
RedhatEnterprise Linux For Power Little Endian8.0
RedhatEnterprise Linux For Power Little Endian Eus8.1
RedhatEnterprise Linux For Power Little Endian Eus8.2
RedhatEnterprise Linux For Power Little Endian Eus8.4
RedhatEnterprise Linux For Scientific Computing7.0
RedhatEnterprise Linux Server6.0
RedhatEnterprise Linux Server7.0
RedhatEnterprise Linux Server Aus7.3
RedhatEnterprise Linux Server Aus7.4
RedhatEnterprise Linux Server Aus7.6
RedhatEnterprise Linux Server Aus7.7
RedhatEnterprise Linux Server Aus8.2
RedhatEnterprise Linux Server Aus8.4
RedhatEnterprise Linux Server Eus8.4
RedhatEnterprise Linux Server Tus7.6
RedhatEnterprise Linux Server Tus7.7
RedhatEnterprise Linux Server Tus8.2
RedhatEnterprise Linux Server Tus8.4
RedhatEnterprise Linux Server Update Services For Sap Solutions8.1
RedhatEnterprise Linux Server Update Services For Sap Solutions8.2
RedhatEnterprise Linux Server Update Services For Sap Solutions8.4
RedhatEnterprise Linux Workstation7.0
CanonicalUbuntu Linux14.04
CanonicalUbuntu Linux16.04
CanonicalUbuntu Linux18.04
CanonicalUbuntu Linux20.04
CanonicalUbuntu Linux21.10
SuseEnterprise Storage7.0
SuseLinux Enterprise High Performance Computing15.0
SuseManager Proxy4.1
SuseManager Server4.1
SuseLinux Enterprise Desktop15
SuseLinux Enterprise Server15
SuseLinux Enterprise Server15
SuseLinux Enterprise Workstation Extension12
OracleHttp Server12.2.1.3.0
OracleHttp Server12.2.1.4.0
OracleZfs Storage Appliance Kit8.8
SiemensSinumerik Edge< 3.3.0
SiemensScalance Lpe9403 Firmware< 2.0
StarwindsoftwareCommand Center1.0
StarwindsoftwareStarwind Virtual Sanv8

All CVSS metrics

  • HIGH 7.8 v3.1 · ADP Primary
    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
  • HIGH 7.8 v3.1 · NVD Primary
    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
  • HIGH 7.2 v2.0 · NVD Primary
    AV:L/AC:L/Au:N/C:C/I:C/A:C

References

Exploit-tagged references (not proof of a PoC)

Patches & mitigations

Advisories

Technical & other

Sources: NVD · CVE.org · All sources and attribution · EPSS