Incorrect TLS certificate validation can lead to escalated privileges

The core of the vulnerability lies in Stork's inadequate TLS certificate validation. An attacker who can obtain a TLS certificate from the Stork server can then use this certificate to establish a connection to the Stork agent. Once connected, the attacker can inject malicious commands targeted at the monitored services, either Kea or BIND 9. This could lead to a range of severe consequences, including unauthorized data exfiltration, modification of DNS records (in the case of BIND 9), and denial-of-service attacks. The blast radius is limited to the services managed by Stork, but successful exploitation could have significant operational and security implications. This vulnerability does not directly affect Kea or BIND 9 themselves, only those using Stork for management.

1. आरक्षित2024-03-12
2. प्रकाशित2024-07-11
3. संशोधित2025-03-26
4. EPSS अद्यतन2026-04-02

The primary mitigation for CVE-2024-28872 is to upgrade Stork to version 1.15.1 or later, which includes the fix for the TLS certificate validation flaw. If an immediate upgrade is not feasible, consider implementing stricter network segmentation to limit access to the Stork agent. Additionally, carefully review and restrict the certificates that Stork trusts. While not a complete solution, implementing a Web Application Firewall (WAF) with TLS inspection capabilities might provide an additional layer of defense by detecting and blocking malicious requests. After upgrading, verify the fix by attempting to connect to the Stork agent with a self-signed certificate; the connection should be rejected.