CVE-2021-3560: Red Hat Polkit Incorrect Authorization Vulnerability
Red Hat Polkit contains an incorrect authorization vulnerability through the bypassing of credential checks for D-Bus requests, allowing for privilege escalation.
CVE-2021-3560 is an incorrect authorization flaw in Red Hat Polkit that lets an attacker bypass credential checks on certain D-Bus requests and escalate privileges. Polkit is a common authorization service on Linux systems that decides whether a process may perform privileged actions; when those checks can be skipped, a low-privileged local user can gain higher rights. Because Polkit is widely present on enterprise Linux distributions, the issue matters for any environment that relies on it for access control.
Public detail is limited to the CISA description of the weakness and the required action to apply vendor updates. Confirm exact package versions, fixed releases, and any additional configuration notes against the vendor advisory before acting.
How it works
The vulnerability is classified as CWE-863 (Incorrect Authorization). Polkit evaluates authorization for D-Bus method calls that request privileged operations. In the affected implementation, the credential-checking path can be bypassed, so the service may grant the requested privilege without properly verifying the caller’s identity or rights. An attacker who already has a local foothold can craft or sequence D-Bus requests that trigger this path, obtaining elevated privileges on the host. No remote network vector is described; the abuse model is local privilege escalation. Specific request formats or timing details are not provided in the available facts and must be confirmed against the vendor advisory if needed for detection rules.
Am I affected? How to find it in your systems
Polkit (often packaged as polkit or policykit) typically runs on Red Hat Enterprise Linux and related distributions, as well as other Linux systems that use the same authorization framework. It is commonly present on servers, workstations, and container hosts that perform privileged operations via D-Bus.
- Inventory: query package managers for the polkit package (for example, rpm -q polkit or equivalent) and note the installed version. Cross-check that version against the fixed releases listed in the vendor advisory.
- Configuration: look for systems that expose D-Bus system bus services and that use Polkit for authorization decisions; these are the hosts most likely to be relevant.
- Telemetry: review authentication and privilege-escalation logs (journalctl, auditd, or equivalent) for unexpected successful privilege grants or anomalous D-Bus traffic originating from unprivileged users. Sudden appearance of root-owned processes launched by non-root accounts can be a secondary indicator, though it is not unique to this CVE.
Because exact vulnerable version ranges are not supplied here, treat any unpatched Polkit installation as potentially affected until the advisory confirms otherwise.
How to remediate
Apply the vendor-supplied update for Polkit as directed by the advisory; CISA’s required action is simply to apply updates per vendor instructions. After patching, restart any services that depend on Polkit if the advisory recommends it, then re-verify the package version.
- Validate the fix by confirming the new package version and, where practical, re-testing the authorization path that previously allowed the bypass.
- Harden the broader class of authorization flaws: keep Polkit and related D-Bus components current, restrict local unprivileged access where possible, and ensure that only necessary D-Bus interfaces are exposed.
- Review and tighten Polkit rules so that high-privilege actions require explicit, well-scoped authorization rather than broad defaults.
If you can't patch immediately
Until the update can be installed, reduce exposure with compensating controls that limit the attacker’s ability to reach or abuse the flawed authorization path.
- Segmentation: isolate hosts that still run the vulnerable Polkit package from general user workstations and from high-value assets.
- Access restriction: limit local interactive logins and remove unnecessary local accounts so that fewer unprivileged users can attempt the escalation.
- Feature reduction: if operationally feasible, disable or tightly constrain D-Bus services that rely on Polkit for privilege decisions until the patch is applied.
- Monitoring: increase logging and alerting around D-Bus authorization decisions and unexpected privilege transitions; treat any successful escalation from a low-privileged context as high priority.
- Virtual patching is less common for local authorization flaws, but host-based intrusion-prevention rules that block suspicious D-Bus call patterns may provide temporary coverage if available from your security tooling vendor.
These measures only lower risk; they do not eliminate the underlying incorrect-authorization condition.
If your data may have been exposed
Actively exploited vulnerabilities can lead to breaches. If privilege escalation succeeded on a host that stores or processes sensitive data, treat the system as potentially compromised, preserve forensic evidence, and follow your incident-response plan. You can run a free exposure scan of your email address to check whether it appears in known breach data sets.
AICompiled with AI assistance from public sources and published under our editorial standards.