TLDR: Halborn performed a security audit for ArcaneOS and found zero critical vulnerabilities.
WHO: This article is for Fluxers with apps deployed on FluxCloud who use ArcaneOS for secure disk space on provider hardware.
NEXT STEPS: Review the full audit here to see Halborn’s findings.
WHAT TO DO: Explore ArcaneOS and see how it secures applications on the network.
Introduction
InFlux Technologies is committed to security and transparency. We want Fluxers who use our systems daily to know that our infrastructure is stable and will protect their applications.
We unveiled ArcaneOS in 2025 as a security upgrade to FluxOS that cryptographically encrypts and allocates secure disk space on provider machines, ensuring that only developers have access to their deployment data.
To demonstrate our commitment to security and transparency, ArcaneOS recently underwent a rigorous security audit by the blockchain security firm Halborn.
Flux provided Halborn with access to the ArcaneOS Git repository to conduct thorough security testing, including automated testing and manual analysis, to detect potential vulnerabilities. This article will review the audit and highlight key details of Halborn’s security report. Let’s get into it!
Report Findings
Overall, Halborn’s security audit came back clean; the audit revealed 14 findings, including 2 high risk, 3 medium risk, and 9 low risk issues, all of which have been addressed and patched since the report was released. Additionally, Halborn’s audit found zero critical vulnerabilities in ArcaneOS.
The two high-risk findings the audit revealed occurred in the low-level system layer. Kernel modules act as app foundations, allowing codebases to be updated with new features without rebooting the entire system. Kernel-level vulnerabilities can cause issues elsewhere.
The first high-risk vulnerability that Halborn’s audit found was a use-after-free (UAF) bug in an ArcaneOS kernel module, leading to memory referencing issues between computing threads. UAF vulnerabilities occur when datasets in a codebase are removed but are still referenced by threads later, which can corrupt the application’s behavior.
Halborn suggested synchronizing properly with spawned threads during app shutdowns so that data removal or cleanup doesn’t occur while workloads are running. The report notes that the UAF finding has been resolved.
The second high-risk finding the Halborn audit revealed was a race condition that could also corrupt application memory. Race conditions occur when app operations depend on the timing of uncontrollable events and variable workload sequencing rather than on fixed, predictable timelines.
When two parts of an operating system access shared data at the same time, and no one is coordinating traffic, data flows become congested because memory references don’t know which dataset to reference first. Most of the time, race-condition vulnerabilities are harmless, and this finding has been addressed by the Flux team.
ArcaneOS Boot Integrity
Halborn noted that ArcaneOS features solid boot integrity—a mechanism within an operating system that enables apps to launch in unmodified, trusted states when devices boot consistently.
Secure boot measurements can confirm certain early boot states. Halborn’s audit found that despite its boot setup, the integrity of Arcane’s initial RAM disk, a temporary root file for memory, was not automatically guaranteed and could lead to unauthorized tampering.
If the integrity of early-boot components isn’t guaranteed and can be tampered with, malicious parties could reduce protections before apps even launch.
Halborn recommended that ArcaneOS strengthen access key protection by tying them more directly to additional boot measurements.
Application Layer Vulnerabilities
The low-level layer and Kernel modules handle backend interactions, while the application layer is the frontend that manages user interactions. Halborn’s audit found several medium-risk vulnerabilities at the application layer of ArcaneOS.
One medium-risk finding of the audit was the use of hardcoded tokens between systems, implemented as static strings with light obfuscation. Meaning that tokens, which are used as sensitive access credentials, are directly embedded into application source code rather than separately and securely stored on their own.
Halborn’s audit stated that hardcoded access can appear to be a security boundary without actually functioning as one, especially if a malicious actor already has deep access to the system.
This issue was resolved because the Flux team holds that tokens don’t serve as a point of access in ArcaneOS and that obfuscation is used to resist automated app scans, rather than as a headline security control.
Another medium-level application‑layer issue was a CORS misconfiguration. CORS controls which websites are allowed to read responses from an API inside a user’s browser. If CORS is too permissive, a malicious site can potentially trick a logged‑in user’s browser into making requests and reading the API responses.
Halborn recommended allowing only approved API requests when the origin can be determined. The Flux team has resolved this issue.
Conclusion
Halborn’s audit found no critical security vulnerabilities in ArcaneOS. However, it did identify a small number of high‑impact low‑level problems and then tracked how the team responded. Some issues were fixed directly. A few were accepted as risks based on how ArcaneOS is intended to be used
Halborn also recommends a follow‑up assessment within six months or after major system updates, which is just standard maintenance. Flux will continue to improve the security of its systems for users, and we will always report audit findings directly to our community.