Apache Ant has released version 1.10.18 to fix CVE-2026-78254, a path traversal issue in the ftp and scp tasks that can allow files downloaded from a remote server to land outside the intended destination directory.

On paper, the advisory rates the issue as moderate. In real environments, the impact depends heavily on where Ant is used. If Ant jobs run inside developer workstations, CI runners, release automation, legacy build servers, or deployment scripts with broad filesystem permissions, an arbitrary file overwrite can become a meaningful foothold: poisoned build artifacts, modified scripts, overwritten configuration, or persistence in places defenders may not immediately inspect.

What happened

The Apache advisory explains that Ant's ftp and scp tasks can download files from remote servers. Prior to 1.10.18, a malicious server could return relative paths that escaped the configured target directory. Ant would then write files using the permissions of the user running the build.

Exploitation is not the same as a drive-by internet RCE. The attacker needs control of the remote server, or a machine-in-the-middle position. For scp and ftps, exploitation also depends on passing or bypassing server identity checks. Plain ftp is the weaker case because it does not provide the same protection against interception or malicious response tampering.

Source: Apache Ant CVE-2026-78254 disclosure on oss-sec.

Why it matters for SMBs and government contractors

Many smaller teams still rely on older build automation because it works, is deeply wired into release processes, and is rarely treated as internet-facing infrastructure. That is exactly why vulnerabilities in build tooling deserve attention. Build systems often hold signing keys, deployment credentials, artifact repository access, internal source paths, and trusted scripts. A file overwrite in that context may not look dramatic at first, but it can affect the integrity of software that later gets deployed across the business.

For government contractors, this also intersects with supply-chain assurance. If a build process retrieves files from third-party servers, internal mirrors, customer environments, or unmanaged FTP endpoints, defenders need to know whether those retrieval steps can alter anything outside the expected workspace. CMMC-style discipline is not only about endpoint antivirus and MFA; it also includes controlling how software, scripts, and artifacts move through the environment.

Defensive takeaways

  • Upgrade Apache Ant to 1.10.18 or later. The fixed version prevents the affected tasks from writing outside the destination directory by default.
  • Search build files for ftp and scp tasks. Pay special attention to jobs that download from external servers, vendor-hosted locations, temporary infrastructure, or legacy FTP endpoints.
  • Eliminate plain FTP where possible. If a build still uses unauthenticated or unencrypted FTP, treat that as a separate risk. Move to authenticated, integrity-protected transfer paths such as SFTP, FTPS with proper validation, or artifact repositories with access control and checksums.
  • Do not bypass server identity checks. Trust-on-first-use shortcuts, disabled host key checks, and weak certificate handling convert a limited vulnerability into a much more practical attack path.
  • Run builds with least privilege. CI workers should not be able to overwrite sensitive host paths, shared scripts, signing materials, or deployment configuration unless explicitly required.
  • Add file integrity monitoring around build runners. Watch for unexpected changes to build scripts, wrapper files, dependency manifests, deployment scripts, cron entries, service files, SSH configuration, and artifact output directories.
  • Validate downloaded artifacts. Use pinned checksums, signatures, or repository metadata instead of assuming that a successfully downloaded file is the correct file.

Bulwark Black assessment

CVE-2026-78254 is a good example of why vulnerability triage should consider business context, not just severity labels. A moderate path traversal bug in a forgotten build job can matter more than a high-severity bug in software you do not run. The practical question is simple: can an attacker influence what your automation downloads, and can that automation write somewhere valuable?

For most teams, the right response is straightforward: update Ant, inventory affected tasks, remove plain FTP, enforce server validation, and make build runners disposable and low-privilege. The bigger lesson is to treat CI/CD and legacy build automation as part of the attack surface. If it can fetch, write, sign, package, or deploy, it deserves monitoring and hardening.