Fortra releases new updates for GoAnywhere: what HANDD customers need to know. Posted by HANDD on 29th July 2026 At HANDD, HANDD Business Solutions Ltd is always keeping a close eye on the latest developments from its technology partners, and this month, Fortra has rolled out a significant round of updates across the GoAnywhere product family, covering MFT, Agents, Gateway, and the Outlook Plugin. Below, HANDD Business Solutions Ltd break down what's new, what's fixed, and what HANDD Business Solutions Ltd recommend for your environment. GoAnywhere MFT 7.10.1. The standout item in this release is Fortra's renewed Drummond Certification for GoAnywhere MFT, reaffirming its compliance with industry interoperability standards - good news for organizations that rely on that certification as part of their vendor assurance process. Other key enhancements include: * New V2 RADIUS provider with Message Authenticator support, giving admins a more secure option for two-factor authentication and RADIUS login methods. * Lucene Directory Type flag (Auto, NIO, or MMAP), offering more control over search indexing behavior, along with a smoother migration path from the legacy system property and better support for Windows UNC paths at startup. * Agent Transfer performance options, including opt-in thread caching and thread pooling for faster transfers. * Improved security controls across Web Client pages and REST APIs. * A reworked approach to generating Job and File Audit IDs, guaranteeing uniqueness without relying on database or cluster resources (note: ID values will appear larger, but ordering is preserved). On the fixes side, Fortra resolved a memory leak tied to queued transfer requests, a race condition affecting job cancellation during shutdown, and several SFTP/SSH issues - including a timestamp preservation bug and a proxy authentication failure in the Mina SSH provider. Clustered environments also benefit from a fix ensuring Active Transfers display activity across all nodes, not just the local one. Underlying components have also been refreshed: Apache Tomcat (9.0.120), Netty (4.2.15), and the PostgreSQL JDBC driver (42.7.11), now verified with an automated connectivity smoke test. GoAnywhere agents 3.5.0. A notable security enhancement in this release: Agent executables are now digitally signed with a trusted code-signing certificate, strengthening trust and integrity verification across deployed agents. Fortra has also made the client/server connection bridge optimization for reverse and forward proxying - previously opt-in - enabled by default, improving data transfer efficiency out of the box. Additional updates include a fix for UDP back-pressure in Gateway that should meaningfully reduce packet loss, plus updates to the Azul Java 11 runtime (11.0.31) and log4j (2.25.4). GoAnywhere Gateway 2.6.1. Gateway's release centers on transfer setup performance, with an improved threading model that speeds up Agent transfer initialization. It also carries over several fixes shared with MFT - including the SSH command timeout issue, the SFTP timestamp preservation fix, and the Mina SSH proxy authentication fix - along with the PostgreSQL JDBC driver upgrade and its new connectivity smoke test. Outlook Plugin 3.3.1 - security update. This release is smaller in scope but important: Fortra has upgraded the log4net package from 2.0.15 to 3.3.2, resolving CVE-2026-40021. HANDD Business Solutions Ltd strongly encourage all Outlook Plugin users to prioritize this update. HANDD's recommendation. Given the security-relevant changes across this release cycle - the renewed Drummond Certification, RADIUS Message Authenticator support, tightened Web Client/REST API controls, digitally signed Agent executables, and the CVE-2026-40021 fix in the Outlook Plugin - HANDD Business Solutions Ltd recommend planning your upgrade across your GoAnywhere estate as soon as practical. As always, back up your environment before upgrading and review Fortra's full release notes for any configuration details relevant to your setup. If you'd like support planning or carrying out your upgrade, HANDD's team is on hand to help - get in touch with HANDD Business Solutions Ltd today. Need more information or assistance? If you have any questions about these updates or require help with your GoAnywhere upgrade, please contact its support team at [email protected].

Fortra Access Manager vulnerability enables remote command injection attacks. 6 min. read Published on June 18, 2026 Fortra has disclosed a critical command injection vulnerability in Core Privileged Access Manager, also known as BoKS, that can let a remote attacker run operating system commands on affected systems. The flaw is tracked as CVE-2026-9862 and affects the boks_autoregisterd service. According to Fortra advisory FI-2026-007, an attacker with network access to the service may execute commands with the privileges of the service during autoregistration processing. BEST SPRING 2026 DEALS The issue carries a critical 9.8 CVSS 3.1 score because exploitation requires network access, low attack complexity, no authentication, and no user interaction, according to the NVD entry for CVE-2026-9862. What CVE-2026-9862 affects. Core Privileged Access Manager is Fortra's privileged access management platform for Linux and UNIX environments. Fortra describes Core Privileged Access Manager as a way to centralize security policy, account management, access control, and privileged access enforcement across multi-vendor server environments. The vulnerable component is boks_autoregisterd, which supports host autoregistration in BoKS deployments. Fortra says the service listens on TCP port 6507 by default, which means exposure depends heavily on firewall rules and network segmentation. NVD lists the affected versions as boks-server 8.1.0.0 through 8.1.0.22 and boks-server 9.0.0.0 through 9.0.0.4. Why the vulnerability is critical. CVE-2026-9862 is classified as CWE-78, which covers improper neutralization of special elements used in an operating system command. The MITRE CWE-78 definition explains that this weakness occurs when externally influenced input can modify the intended command before it reaches the operating system. In practical terms, a remote attacker who can reach boks_autoregisterd may be able to inject commands into the autoregistration workflow. Those commands would run with the privileges assigned to the service, which can create a serious path to system compromise. The risk rises further because BoKS controls privileged access. A compromised privileged access management component can expose sensitive administration workflows, disrupt authentication controls, or help an attacker move deeper into a Linux or UNIX server environment. Fortra recommends restricting access to port 6507. Fortra's immediate workaround is to restrict network access to boks_autoregisterd until fixed builds are deployed. Administrators should limit TCP port 6507 to trusted management networks and block access from untrusted internal segments and the public internet. Where autoregistration is not required, Fortra also recommends disabling the service through the BoKS Master configuration. The Fortra security advisory says administrators can comment out the autoregisterd line in the boksinit configuration and then reload boks_init or restart BoKS. Disabling the service prevents exploitation through boks_autoregisterd, but it also stops autoregistration until the configuration is restored. Organizations should plan that change carefully in environments where automated host onboarding is still active. Affected versions and exposure checklist. The National Vulnerability Database says the flaw affects specific BoKS server 8.1 and 9.0 builds and maps the weakness to CWE-78. NVD also records CISA ADP data that marks the vulnerability as automatable with total technical impact. That does not mean every BoKS deployment is equally exposed. The most urgent cases are systems where boks_autoregisterd listens on a reachable network interface and where port 6507 can be reached from untrusted networks. Administrators should answer these questions immediately: * Are VPNCentral running boks-server 8.1.0.0 through 8.1.0.22? * Are VPNCentral running boks-server 9.0.0.0 through 9.0.0.4? * Is boks_autoregisterd enabled on the BoKS Master? * Is TCP port 6507 reachable from outside the management network? * Do firewall logs show unexpected traffic to port 6507? * Do BoKS logs show unusual autoregistration activity? * Can autoregistration be disabled until fixed builds are installed? Why boks deployments need fast mitigation. Fortra's BoKS platform is used to manage accounts, access, privilege enforcement, sudo controls, and administration across Linux and UNIX environments. That makes the product a high-value target when a critical network-reachable flaw appears. An attacker who can run commands through a privileged service may attempt to alter files, deploy malware, create persistence, tamper with access controls, or use the affected host as a staging point for lateral movement. Security teams should treat port 6507 exposure as an emergency configuration issue. Even before fixed builds are available, network-level restrictions can sharply reduce the attack surface. How security teams should respond. Organizations should start with containment. Limit access to boks_autoregisterd, disable the service where possible, and confirm whether affected BoKS server versions are present in production, staging, and backup environments. Teams should then review logs for suspicious activity. Look for unexpected autoregistration attempts, unfamiliar source IP addresses, abnormal process execution, changed configuration files, or signs of shell command execution around the BoKS service. The CWE guidance for command injection also highlights the value of least privilege, sandboxing, strict input handling, and firewall controls. For customers waiting on fixed builds, those defensive layers can help limit both exploitability and impact. No public exploitation confirmed yet, but risk remains high. Fortra's advisory and NVD listing do not currently state that CVE-2026-9862 has been exploited in active attacks. However, the vulnerability is network-reachable, unauthenticated, low-complexity, and affects privileged access infrastructure. That combination makes delayed mitigation risky. Organizations should not wait for public exploit activity before restricting access to the vulnerable service. The safest response is to assume that exposed boks_autoregisterd services will attract scanning. Restrict port 6507, disable autoregistration where possible, monitor for suspicious activity, and deploy Fortra's fixed builds as soon as they are released. Faq. What is CVE-2026-9862? CVE-2026-9862 is a critical OS command injection vulnerability in Fortra Core Privileged Access Manager (BoKS). It affects the boks_autoregisterd service and can allow a remote unauthenticated attacker with network access to execute commands with the service's privileges. Which Fortra BoKS versions are affected? NVD lists boks-server 8.1.0.0 through 8.1.0.22 and boks-server 9.0.0.0 through 9.0.0.4 as affected by CVE-2026-9862. Is CVE-2026-9862 being exploited in the wild? Fortra's advisory and the NVD entry do not currently state that CVE-2026-9862 has been exploited in active attacks. Even so, the flaw is critical because it is remotely reachable, unauthenticated, and can have total technical impact. What port does the vulnerable BoKS service use? Fortra says boks_autoregisterd listens on TCP port 6507 by default. Administrators should restrict this port to trusted management networks or disable the service if autoregistration is not required. How can organizations mitigate CVE-2026-9862? Organizations should restrict network access to boks_autoregisterd, block untrusted traffic to TCP port 6507, disable autoregistration where possible, review logs for suspicious activity, and install Fortra's fixed builds as soon as they become available. Readers help support VPNCentral. VPNCentral may get a commission if you buy through its links. Improve this guide User forum 0 messages