Kea and Stork Projects Audited

In mid-2025 ISC contracted with OSTIF to identify an external organization to audit our Kea and Stork code for security issues. Kea is a modern DHCP server, and Stork is a graphical management tool for DHCP and DNS, and both projects are open source under the MPL 2.0 license.

Working with OSTIF, we identified four key goals for the Kea audit

Kea is a fairly stable and mature codebase, without a lot of external dependencies. Kea has an extensive API and is often deployed with an SQL database for external data storage. When Kea was first developed, network management applications could be assumed to be deployed on a “bastion host,” in a protected network segment. However, since then the focus for network security has shifted to a defense-in-depth approach. We wanted to:

1. Develop a threat model for Kea to identify the likely attack points.
2. Audit the source code, specifically including the extensive API and the connections with external systems, such as databases, which we felt were logical attack surfaces.
3. We hadn’t had the time to set up fuzz testing for Kea, so OSTIF suggested they could focus on finding an auditor with specific expertise in that area to help establish a fuzz-testing program.
4. We also had not yet generated Software Bills of Materials (SBOMs) for Kea, and we also hoped to get some help with that.

OSTIF recommended ADALogics for this audit. In addition to their specific security expertise, this team has extensive experience with fuzzing open source projects, and familiarity with generating SBOMs. After a meeting to introduce ourselves, clarify our objectives, and organize our communications, the auditors worked largely independently of the Kea team.

Kea audit results

The review included scanning the source code with several analyzers that Kea was not using at the time, as well as some manual inspection. The auditors also delivered a working fuzz-testing project, set up with Google’s OSS-Fuzz system. With the analysis and fuzzing, the inspectors found a total of six potential issues. These were all assessed to be of “informational” severity: a couple are opportunities for enhancements to Kea. An example is a suggestion that we should enable multi-factor authentication for Kea administrators, which was already under consideration.

At the conclusion of the audit the ADALogics team transferred ownership of the fuzzing project to the Kea team, so we will receive any test findings and will be able to modify and extend the tests going forward.

The full audit report from ADALogics is available: https://ostif.org/wp-content/uploads/2025/12/audit-report-2-1.pdf.

We had slightly different goals for the Stork audit

Stork is a graphical management utility with a web interface. It is written in Go, using Angular and PrimeNG as significant user interface dependencies. We had recently completed a major upgrade of those components, and asked the auditors to specifically study our exposure to possible vulnerabilities in these components. Stork provides privileged access to both Kea and any monitored DNS servers, so we requested a special focus on our handling of these secrets and enforcement of access controls. We think most of our Stork users may be relying on our packages, and because of our significant dependencies on external projects, we wanted to explore enhancing our supply-chain tracking and security.

OSTIF recommended 7A Security for this study. Their approach is more of a white box pen-testing approach than manual code inspection, which we thought was appropriate for a web-based product.

7A Security proposed seven “work packages” for this project:

1. Whitebox Tests Against Stork Web Frontend and API
2. Whitebox Tests Against Stork Backend, Agents, and Auth Logic
3. Whitebox Tests Against Stork Supply Chain Analysis Implementation
4. Lightweight Threat Model for Stork and Kea Integration Points
5. Stork Dependency Management Review & SBOM Creation
6. Stork Config Parser Fuzzing and Test Case Creation

Stork Audit Results

The 7A team identified seven potential vulnerabilities, two of which they scored as high severity. None of these met ISC’s requirements for a CVE, but we prioritized fixing all of them. ISC has implemented fixes for all seven vulnerabilities and 7A has verified the fixes. These fixes were included in the Stork 2.4.0 release, which was posted on February 25, 2026. The 7A team agreed to delay publication of their report until after the release.

7A made five recommendations for hardening Stork. ISC has developed fixes that address four of these: the fifth, a recommendation that we implement multi-factor authentication for Stork users, was already on our roadmap, and is being tracked as Stork issue number 2210.

The auditors assessed Stork’s compliance vs the SLSA Framework versions 0.1 and 1.0. We do not yet have any clear requirements for supply chain security from our users, but we are anticipating this may become a compliance requirement soon. The SLSA assessment was complicated by the fact that ISC’s testing and package building infrastructure is not exposed on the public Internet, and we had given 7A Security access only to our public Stork development repository. 7A judged that Stork met the SLSA 0.1 requirements, and met the SLSA 1.0 framework requirements for the Level 1 criteria. We have opened a few issues to address some outstanding changes to help us achieve Level 2, which addresses the build service as well as automatically generating, storing, and publishing build artifacts alongside our packages.

We encourage users to read the full audit report from 7A Security. We have opened GitLab issues to track all of the 7A Security recommendations, which can be found in our Stork repository by doing a search for issues with the label “sec-audit2.”

Acknowledgements

These audits were part of a project funded through the ICANN Grant Program. ICANN is a nonprofit public benefit corporation established in 1998. Its mission is to ensure a stable, secure, and unified global Internet by coordinating the allocation and management of Internet Protocol (IP) addresses, domain names, and protocol parameters.