Prepared by:
HALBORN
Last Updated 02/05/2026
Date of Engagement: October 8th, 2025 - November 18th, 2025
100% of all REPORTED Findings have been addressed
All findings
14
Critical
0
High
2
Medium
3
Low
9
Informational
0
InFlux Technologies engaged Halborn to conduct a security assessment of the ArcaneOS system. Halborn was provided access to the GitHub repository and the associated internal documentation in order to conduct security testing using a combination of automated testing and manual analysis to scan, detect, validate and report possible vulnerabilities.
A comprehensive security assessment of the system identified multiple classes of vulnerabilities affecting the platform’s reliability, confidentiality, and integrity across the kernel, application, and infrastructure layers. Several findings were related to inadequate privilege separation, unsafe concurrency handling, weak cryptographic practices, insecure communication patterns, and architectural decisions that increase operational and attack surface risk.
At the kernel and low-level system layer, unsafe thread management and race conditions created conditions that could lead to Use-After-Free scenarios, memory corruption, and undefined behavior. The system employs a Unified Kernel Image (UKI), in which the kernel, initrd, and command line are bundled and cryptographically signed, providing strong protection against pre-boot tampering of these components. In addition, ArcaneOS leverages dm-verity to ensure runtime integrity of the filesystem, preventing unauthorized modification of disk contents after boot. While Secure Boot and PCR7 contribute to a trusted boot baseline, the overall boot and runtime integrity model relies on the combination of signed UKIs and dm-verity rather than PCR measurements alone. The assessment also noted that the hardware platform lacks mitigations against certain physical memory-extraction attacks, and that Trusted Execution Environments (TEEs) are not currently used to protect sensitive runtime secrets.
At the application layer, several architectural weaknesses were identified that increased the system’s attack surface. These included components running with elevated privileges, token-generation mechanisms with limited entropy designed for manual use, unsafe deserialization paths that could lead to denial-of-service conditions, and improper file-write synchronization resulting in potential configuration corruption or service instability. Information-disclosure issues—such as verbose error handling, exposure of internal secrets, and leakage of network topology—could further assist an attacker in chaining attacks.
Web-facing components exhibited additional risks, including CORS misconfigurations, insecure cookie attributes, archive-extraction logic vulnerable to Zip Slip-style path traversal, and anti-debugging mechanisms that do not provide strong security guarantees. Collectively, these issues could enable privilege escalation, denial of service, or unintended disclosure of internal system details to both local and remote adversaries.
Mitigations should focus on strengthening defenses across all layers of the stack. Recommended actions include enforcing strict least-privilege execution, improving concurrency safety, hardening token and cryptographic handling within their intended threat model, validating all external inputs, securing cookie and CORS configurations, and continuing to rely on signed UKIs and dm-verity for boot-time and runtime integrity. Where the threat model requires protection against advanced physical or runtime attacks, the optional adoption of TEEs may further reduce risk. Implementing these measures would materially improve the platform’s resilience while preserving its existing secure-by-design boot architecture.
Although the use of PCR7 (Secure Boot) provided a baseline level of protection, it did not guarantee the integrity of the initrd. This introduced a single point of failure in which an attacker could compromise the boot partition and disable downstream security controls—such as watchdog mechanisms, privilege separation, and data separation—before those controls were even loaded. Furthermore, without a Trusted Execution Environment (TEE), the system remained vulnerable to runtime memory-extraction attacks.
To achieve a robust security posture, the engineering effort was required to shift toward preventative cryptographic enforcement, including extended PCR policies and the adoption of TEEs.
Extend TPM Sealing Policy
The reliance on PCR7 alone was insufficient to protect the system against physical attacks at rest, as it did not include measurements of the initial RAM disk (initrd).
Action: The TPM sealing policy was to be extended to include at least PCR9 (to measure and secure the initrd) and, ideally, PCR11 (to cover Unified Kernel Image components).
Benefit: This ensured that if an attacker modified the initrd—for example, to inject a shell or extract encryption keys—the TPM would refuse to unseal the disk-encryption key, thereby keeping the data volume inaccessible.
Re-engineer the Update Process for PCR Compliance
Implementing the strict PCR sealing described above introduced additional complexity into the update cycle, as any kernel or initrd modification altered the corresponding measurements and would otherwise break the seal.
Action: The fluxos updater logic was to be modified to support pre-calculated sealing. During an update, the system was required to compute the future hash of the new initrd and kernel, and seal the disk key to these new measurements prior to rebooting.
Benefit: This approach preserved the seamless automatic-update experience without requiring user intervention, while simultaneously closing the security gap in the boot process. This behavior was necessary for achieving a properly secure boot chain.
Mitigation of Runtime Memory Attacks
It was acknowledged that standard Intel/AMD architectures, without dedicated security extensions, were unable to protect against physical RAM extraction (cold-boot attacks) or bus-sniffing attacks while the system was running.
Action: If resistance to sophisticated physical attacks during runtime was required, the hardware scope had to be expanded to include support for Trusted Execution Environments (TEEs), such as AWS Nitro Enclaves or Intel SGX/TDX (noting that SGX had a history of significant vulnerabilities and was generally not recommended).
Benefit: This ensured that keys and other sensitive in-memory data remained encrypted even in scenarios where the physical host hardware was compromised.
Enforce the Principle of Least Privilege
The application layer currently executed critical components—such as the web server—with root privileges, increasing the impact of any potential exploitation.
Action: The application architecture was to be refactored so that the frontend, web server, and parsers operated under an unprivileged user account. Privileged operations were to be delegated through D-Bus, polkit, or narrowly scoped sudo allow-lists (the latter being the least recommended).
Benefit: This approach reduced the blast radius of any application-level compromise (for example, exploitation of the Zip Slip vulnerability), preventing such issues from escalating into a full system takeover.
Critical
0
High
2
Medium
3
Low
9
Informational
0
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Linux Kernel Module UAF | High | Solved |
| Data race condition involving memory corruption | High | Risk Accepted - 01/12/2026 |
| Key extraction on first boot | Medium | Risk Accepted - 12/15/2025 |
| File corruption from race condition | Medium | Solved - 12/16/2025 |
| Hardcoded credentials and tokens | Medium | Risk Accepted - 01/12/2026 |
| Weak API security configuration | Low | Solved - 12/15/2025 |
| Cleartext transmission of metadata | Low | Solved - 12/15/2025 |
| Weak cookie security attribute | Low | Solved - 12/16/2025 |
| DoS due to deserialization of attacker-controlled data | Low | Solved - 12/16/2025 |
| Info leak on exception in runtime-proxy | Low | Solved - 12/15/2025 |
| Infringement of least privilege principle | Low | Solved - 01/12/2026 |
| Weak Token Generation | Low | Risk Accepted - 12/15/2025 |
| Mitigated arbitrary file write using Zip Slip | Low | Solved - 12/16/2025 |
| Antidebug bypass | Low | Risk Accepted - 01/12/2026 |
//High
//High
//Medium
//Medium
//Medium
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
ArcaneOS
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
