Red Hat Gatekeeper 3.20.1 Fixes Two High-Severity Vulnerabilities
Tech GuruQuick Answer
Red Hat Gatekeeper 3.20.1 addresses two Go TLS denial-of-service vulnerabilities in the advisory-listed operator images. For these CVEs, the CSAF record marks the listed Gatekeeper operand and operator-bundle images known not affected. Match product status as well as version and architecture; not every image in the product tree is a vulnerable image.
Confirm Scope And Apply The Supported Fix
What to do now: Inventory Red Hat Gatekeeper 3.20, match the exact affected release or feature, apply the authority-supported fixed build or service remediation, validate the dependent workflow, and preserve evidence.
Last verified: 2026-10-02 UTC. Recheck the authoritative advisory and supported distribution channel before changing production.
Scope And Authority
| Product scope | Red Hat Gatekeeper 3.20 |
|---|---|
| Advisory | RHSA-2026:74791 |
| CVEs | CVE-2026-32280, CVE-2026-32283 |
| Authoritative release date | 2026-10-01 22:38:04 UTC |
| Authority revision date | Latest current_release_date in the checked advisory set: 2026-10-02T17:19:16+00:00. Individual advisories may have earlier revisions. |
| Affected versions | Gatekeeper 3.20 image builds before the v3.20.1 advisory digests. |
| Fixed version | Gatekeeper v3.20.1 advisory-listed signed image digests |
| CVSS base score | 7.5 (official CVSS v3.1) |
| CVSS severity | High |
| Exploitation status | Not stated by the authority; no exploitation claim is inferred. |
What Changed
CVE-2026-32280 concerns excessive certificate-chain-building work; CVE-2026-32283 concerns TLS 1.3 key-update messages causing connection deadlock/resource exhaustion. Neither is described here as a policy-language bypass. The 3.20 release also has webhook configuration changes, including separate mutating settings and rules overriding operations.
What To Validate Now
- Inventory. Locate Red Hat Gatekeeper 3.20 deployments, versions, enabled features, exposure paths, owners, and dependent services.
- Establish applicability. Match entitlement, product stream, architecture, source package or image repository, and each advisory's product status. Do not apply one branch's build or digest to another branch.
- Remediate. Use the supported Red Hat Gatekeeper Operator update path and matching architecture image. Preserve policy resources and webhook configuration, and review the 3.20 parameter changes. Do not bypass the operator or change admission failure behavior merely to make an upgrade appear healthy.
- Validate. Confirm operator reconciliation and running image digests, webhook availability and audit status. In an approved test namespace, submit a benign compliant resource and a benign resource that the existing policy should reject. Record the expected decisions without weakening production constraints.
- Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.
Operational Cautions
A healthy pod is not enough to prove admission and audit still enforce the intended policy. Plan availability and recovery with the cluster owner and retain policy/configuration backups. No TLS stress test or cluster upgrade was performed for this notice.
Evidence To Retain
- Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
- UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
- Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.
Related TechGeeks Resources
Authoritative References
Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.
