How do you patch or mitigate CVE-2021-3560 (Red Hat Polkit Incorrect Authorization)?

CISA’s required action for CVE-2021-3560 is to apply updates per vendor instructions. In practice, find every instance of Red Hat Polkit in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What to do first when CVE-2021-3560 is in scope

Start by identifying every Red Hat Polkit installation and confirming where it is exposed, because the fastest path to reduction is to remove reachable attack surface while you work through the vendor fix. For exploitable vulnerabilities, use the vendor update path first and treat any temporary workaround as a short bridge, not a substitute for remediation.

For prioritisation, pair the vendor instructions with the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database entry to confirm the record, track exposure, and align remediation with your normal vulnerability workflow. If you need a broader emergency response playbook for actively exploited flaws, use the Zero-Day and Exploited Vulnerabilities Guide for the patch-gap and containment sequence.

Where the service is internet reachable or otherwise broadly reachable, remove that exposure immediately if patching is delayed. If the product cannot be fixed quickly enough, taking it out of service is safer than leaving a known exploited authorization flaw in place.

How to reduce exposure when patching must wait

When the update cannot be applied right away, the mitigation goal is to narrow who can reach the vulnerable host and what an attacker can do if they do reach it. That usually means restricting network paths, limiting administrative access, and avoiding any deployment pattern that leaves the service directly exposed to untrusted users or networks.

For the surrounding lifecycle work, the Vulnerability Management Guide is useful because this kind of issue needs asset scope, exception handling, and verification, not just a patch ticket. If you need a practical baseline for service and platform hardening, the IAM and IGA Basics guide reinforces the broader principle that exposed administrative paths and stale access are part of the problem, not just the software version itself.

Do not rely on compensating controls that still leave the vulnerable component reachable by arbitrary users. If you can only partially constrain exposure, document the exception, time-box it, and keep it under active watch until the update is applied.

How to check for exploitation after remediation

After patching, review logs for signs of earlier abuse because a fixed version does not undo a prior compromise. Look for suspicious privilege escalation, unexpected administrative actions, new local users, unusual session or process behaviour, and anything else that would indicate the flaw was used before you closed it.

If you need a deeper post-patch hunting lens, the Zero-Day and Exploited Vulnerabilities Guide covers compromise assessment and post-patch verification for exploited vulnerabilities. For teams that need to prioritise whether an issue was likely weaponised in the wild, the Exploit Prediction Scoring System and the KEV catalogue together help separate theoretical exposure from urgent operational risk.

Risk and Threat Considerations

This flaw matters because it is not just a software defect, it is an authorization weakness that can be used to cross a privilege boundary. In practice, the risk is greatest where the vulnerable host is reachable by untrusted users, where patching is slow, or where local compromise would expose credentials, administrative control, or adjacent systems.

Failure mechanism: An attacker abuses the incorrect authorization path to gain actions they should not have been allowed to perform, then pivots into stronger local or administrative access.

Impact: Successful exploitation can lead to privilege escalation, host compromise, and follow-on movement or persistence if the system is not reviewed for earlier abuse.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	CVE remediation requires tracked vulnerability handling and verification.
Recommendation — Track the issue through a vulnerability management process until remediation is verified.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The answer is about applying vendor fixes and handling known exploited flaws.
	AU-6 — Audit Review, Analysis, and Reporting	Post-patch log review is needed to detect earlier exploitation.
Recommendation — Apply vendor remediations and document exceptions until the flaw is closed. Review audit records for indicators of prior compromise after remediation.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The subject is a live CVE requiring prioritisation, patching, and verification.
	CIS-8 — Audit Log Management	Post-remediation hunting depends on retaining and reviewing logs.
Recommendation — Prioritise, remediate, and verify the vulnerable asset through continuous vulnerability management. Preserve and review logs to look for signs of exploitation before the patch.

Practitioner Guidance

What to prioritise: Patch the highest-exposure instances first, especially systems reachable by untrusted users or systems that would expose broader administrative access if compromised. If you cannot patch immediately, reduce reachability before you spend time on deeper tuning or postmortem work.

What to verify: Confirm not only that the vendor update was applied, but also that the affected hosts were actually in scope and that any temporary exposure reduction is still in place. If logs are incomplete, treat the environment as needing a broader compromise review rather than assuming absence of evidence.

Practitioner takeaway: For KEV-class flaws, remediation is a sequence: shrink exposure, apply the vendor fix, then prove the host was not already abused.