CVE-2026-79899 in BoKS Manager
Summary
by MITRE • 10/01/2026
Fortra BoKS Manager contains an insecure temporary file vulnerability in bccgethostcert. The utility creates predictable temporary files without first setting a restrictive umask. A local user on the BoKS Master who can read files under BOKS_tmp may be able to obtain CA secret or host private-key material while the utility runs, or obtain CA secret material left behind after successful certificate creation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/01/2026
The vulnerability identified in Fortra BoKS Manager within the bccgethostcert utility represents a classic insecure temporary file race condition rooted in improper handling of system permissions and file creation practices. The core technical flaw lies in the application's failure to establish a restrictive umask before generating temporary files. In Unix-like operating systems, the umask determines which permission bits are masked out when new files or directories are created. By not setting this mask appropriately, typically to something like 077 which denies access to group and others, the utility creates files with default permissions that often allow read and write access by other users on the same system. This oversight transforms a local privilege boundary into an exploitable vector for information disclosure. The specific component affected is responsible for managing certificate authority operations, meaning the data at risk includes highly sensitive cryptographic material such as Certificate Authority secrets and host private keys.
From an operational perspective, this vulnerability allows any local user who has read access to the BOKS_tmp directory to intercept or exfiltrate critical security credentials while the bccgethostcert utility is actively running. The attack scenario involves a malicious actor monitoring the temporary file creation process. Because the filenames are predictable and the permissions are permissive, an attacker can potentially open these files before the application finishes writing them or read their contents after they have been written but not yet securely deleted or moved to protected storage. This leads to two distinct phases of compromise: during execution, where partial or complete key material might be captured in transit within the temporary file system, and post-execution, where residual CA secret materials may remain on disk with insufficient access controls if the cleanup process is also flawed or delayed. The ability to obtain host private-key material effectively compromises the identity integrity of systems managed by BoKS Manager, potentially allowing an attacker to impersonate these hosts in network communications or decrypt sensitive traffic intended for them.
This vulnerability maps directly to CWE-377, which describes Insecure Temporary File creation, and specifically aligns with the aspect of predictable filenames combined with insufficient access controls. Furthermore, it falls under the broader category of CWE-250, where operations are performed with unnecessary privileges or without enforcing least privilege principles regarding file system permissions. In terms of the MITRE ATT&CK framework, this behavior is consistent with techniques found in T1564, specifically T1564.008 which involves Hidden Files and Directories if the attacker uses symlinks to redirect output, but more accurately reflects data exfiltration methods where sensitive information is accessed from local storage due to misconfiguration rather than active exploitation of a buffer overflow or injection flaw. The lack of atomic file creation operations using secure flags like O_CREAT with exclusive access further exacerbates the risk by allowing race conditions that could be leveraged for symlink attacks if directory permissions are also weakly configured, although the primary impact here is information disclosure through predictable paths and open permissions.
Mitigation strategies must focus on enforcing strict file system security controls at both the application level and the operating system configuration level. The most critical immediate fix involves modifying the bccgethostcert utility to explicitly set a restrictive umask, such as 077 or 007, immediately before any temporary files are created. This ensures that newly generated files are only accessible by the owner of the process, effectively neutralizing the threat posed by other local users. Additionally, developers should implement secure file creation practices using platform-specific APIs like mkstemp on Unix systems which atomically create a unique temporary file with restrictive permissions, thereby eliminating predictability and race conditions associated with static filenames. On the infrastructure side, administrators should ensure that the BOKS_tmp directory itself is owned by the BoKS service account and has permissions set to 700 or similar restricted modes to prevent unauthorized users from even listing its contents. Regular audits of temporary file handling across all components of the Fortra BoKS Manager suite are recommended to identify and remediate similar patterns in other utilities that may share this architectural weakness, ensuring comprehensive protection against local privilege escalation via information disclosure.