CVE-2026-8367: aria2c Certificate Validation Vulnerability

CVE-2026-8367 Overview

CVE-2026-8367 affects aria2c, a command-line download utility that supports HTTP, HTTPS, FTP, BitTorrent, and Metalink protocols. The vulnerability is an improper certificate validation issue [CWE-295] where aria2c accepts server certificates with an incorrect Extended Key Usage (EKU). An attacker who compromises a certificate and its associated private key, originally issued for a different purpose such as client authentication or code signing, can reuse it for TLS server authentication against aria2c clients. This weakens the trust boundary that TLS certificate validation is meant to enforce.

Critical Impact

Attackers holding a misused but legitimately issued certificate can impersonate HTTPS servers to aria2c clients, enabling traffic interception and content substitution during downloads.

Affected Products

• aria2c (specific affected versions not enumerated in NVD data)
• Applications and scripts embedding aria2c for HTTPS downloads
• Automated download pipelines relying on aria2c TLS validation

Discovery Timeline

• 2026-05-13 - CVE-2026-8367 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-8367

Vulnerability Analysis

The vulnerability stems from incomplete TLS certificate validation in aria2c. When validating a server certificate during an HTTPS connection, aria2c does not enforce that the certificate's Extended Key Usage extension contains the serverAuth (1.3.6.1.5.5.7.3.1) object identifier. RFC 5280 defines EKU as a constraint that restricts the purposes for which a certificate's public key may be used. A correctly behaving TLS client must reject any server certificate that lacks the serverAuth EKU or that asserts only unrelated EKUs.

Because aria2c skips this check, certificates issued for other purposes, such as client authentication, email protection, or code signing, are treated as valid for TLS server identity. This expands the population of certificates an attacker can abuse if they obtain the private key through theft, exposure, or insider access.

Root Cause

The root cause is missing EKU enforcement in the certificate verification path. The TLS library may report a chain as cryptographically valid, but aria2c does not additionally verify that the leaf certificate's EKU permits TLS server authentication. This is a classic improper certificate validation defect tracked under [CWE-295].

Attack Vector

Exploitation requires the attacker to already control a certificate and private key issued by a trusted Certificate Authority for a non-server purpose. The attacker must then position themselves on the network path between the aria2c client and the intended server, for example through ARP spoofing, rogue Wi-Fi, BGP hijack, or DNS poisoning. The attacker presents the misused certificate during the TLS handshake. aria2c accepts the certificate and establishes a session, allowing the attacker to serve modified payloads or capture transferred data. The high attack complexity reflects the prerequisite of obtaining a usable certificate and gaining network position.

Detection Methods for CVE-2026-8367

Indicators of Compromise

• Unexpected TLS handshakes from hosts running aria2c to IP addresses or domains that do not match the intended download source.
• Server certificates observed in aria2c sessions whose EKU extension omits serverAuth or lists only clientAuth, codeSigning, or emailProtection.
• Downloaded files whose hashes do not match published vendor checksums when aria2c is used over untrusted networks.

Detection Strategies

• Inspect TLS metadata in network telemetry and flag certificates presented to aria2c clients that lack the serverAuth EKU.
• Compare certificate Subject, Issuer, and Serial Number values seen on the wire against the expected certificate for each download endpoint.
• Enable verbose logging in aria2c and audit logs for repeated downloads from unexpected hostnames or IPs.

Monitoring Recommendations

• Forward host and network logs containing TLS certificate fields into a centralized analytics platform for correlation.
• Alert on aria2c processes initiating outbound HTTPS to destinations outside an approved allowlist.
• Track file integrity of artifacts retrieved by aria2c and compare against trusted hash sources after download completes.

How to Mitigate CVE-2026-8367

Immediate Actions Required

• Inventory all systems, container images, and build pipelines that invoke aria2c and identify versions in use.
• Restrict aria2c use to networks where the path to the target server is trusted, or tunnel traffic through a VPN until a patched version is deployed.
• Pin expected server certificates or hashes for critical download endpoints and verify downloaded artifacts against trusted checksums.

Patch Information

Refer to the Tenable Research Advisory TRA-2026-38 for upstream fix details and updated aria2c releases. Apply the vendor-supplied patched build once available and validate that the updated client rejects certificates without the serverAuth EKU.

Workarounds

• Replace aria2c with a download client that enforces EKU validation, such as curl or wget, for HTTPS retrievals from sensitive endpoints.
• Verify downloaded files using detached signatures or vendor-published hashes rather than relying solely on TLS for integrity.
• Limit outbound HTTPS from systems running aria2c to a known set of destinations through firewall egress rules.

# Configuration example: verify downloads with a published SHA-256 checksum
aria2c --check-integrity=true --checksum=sha-256=<expected_hash> https://example.com/artifact.tar.gz
sha256sum -c artifact.tar.gz.sha256