CVE-2022-32981

What it actually does

The vulnerability permits improper handling of notification events and secret references within the controller, allowing cross-namespace access or unvalidated webhook payloads.

Why it matters to the business

Organizations using affected Flux CD deployments face potential unauthorized notification triggers or data exposure, increasing operational risk and compliance exposure until patched versions are deployed at scale.

How an attack unfolds

An attacker with access to create or modify Flux resources submits crafted notification configurations that bypass namespace isolation or validation, leading to unintended secret reads or event processing.

How to fix it

Upgrade flux-notification-controller to the fixed versions provided for Chainguard and Wolfi distributions; verify all instances are running patched releases and re-apply any required RBAC or webhook configurations.

How to confirm the fix worked

Query running controller versions via kubectl or package managers, confirm no instances report pre-fix builds, and test webhook admission with cross-namespace references to ensure rejection.

Typical attack path

1. Identify Flux-managed clusters exposing notification-controller endpoints
2. Craft malicious Notification or Provider custom resources referencing cross-namespace secrets
3. Submit resources to the API server to trigger webhook processing
4. Observe or exfiltrate data through resulting notifications or side effects

How to detect it

Review Kubernetes audit logs and controller logs for Notification and Provider objects referencing unexpected namespaces or secrets; look for repeated admission webhook denials or anomalous notification deliveries.

What your security team should do

• Immediately inventory all Flux installations and prioritize upgrade of notification-controller
• Enable admission webhooks and namespace isolation policies as compensating controls
• Monitor EPSS and exploit availability trends for any change in risk posture