CVE-2026-36610 in AC12G
Summary
by MITRE • 06/03/2026
Mercusys AC12G (EU) V1 with firmware AC12G(EU)_V1_200909 transmits DDNS credentials over plaintext HTTP with only Base64 encoding. The firmware contains no TLS implementation, allowing man-in-the-middle interception of DDNS service credentials.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 06/03/2026
The Mercusys AC12G (EU) V1 device represents a significant security vulnerability through its improper handling of Dynamic Domain Name System credentials within its firmware version AC12G(EU)_V1_200909. This vulnerability stems from the device's reliance on plaintext HTTP transmission for DDNS credential exchange without any form of encryption or secure transport mechanism. The implementation lacks TLS support entirely, creating a fundamental security gap that exposes sensitive authentication information to network-based attackers. The credentials are transmitted using only Base64 encoding which provides no cryptographic protection and can be easily decoded by anyone intercepting the network traffic. This design flaw directly violates security best practices and industry standards such as those outlined in CWE-312, which specifically addresses the exposure of sensitive information through improper encoding or encryption. The device's architecture demonstrates a critical failure in secure communication implementation, as it fails to establish any form of secure channel for transmitting authentication credentials.
The technical flaw manifests in the device's network communication stack where it defaults to plaintext HTTP protocols for DDNS service integration rather than implementing secure HTTPS or alternative encrypted communication channels. This vulnerability creates an attack surface that aligns with ATT&CK technique T1071.004, which covers application layer protocol communication over unencrypted channels. The absence of TLS implementation means that any network traffic interception can readily capture the Base64 encoded credentials, which when decoded reveal the actual DDNS authentication information. This weakness allows attackers to perform man-in-the-middle attacks without requiring advanced cryptographic capabilities or specialized tools. The device's firmware architecture shows no consideration for secure credential storage or transmission, creating a persistent security risk that remains active as long as the device operates with the vulnerable firmware version. The lack of any encryption or authentication mechanisms in the communication protocol stack represents a fundamental security architecture failure.
The operational impact of this vulnerability extends beyond simple credential exposure, as successful interception of DDNS credentials can lead to complete network compromise and unauthorized control of the device's network configuration. Attackers who intercept these credentials can modify DDNS settings, redirect traffic to malicious endpoints, or even gain persistent access to the network through the compromised device. The vulnerability affects not only the device's local security but also potentially impacts the broader network infrastructure that relies on the DDNS service for remote access or dynamic network addressing. This weakness can be exploited by attackers with minimal technical expertise since the Base64 encoding provides no real security barrier and can be easily reversed. The attack surface is further expanded by the fact that DDNS credentials often provide access to network resources that may not be properly secured, potentially allowing attackers to escalate privileges or access additional network segments.
Mitigation strategies for this vulnerability must address both immediate and long-term security concerns. The primary recommendation involves firmware updates from the vendor to implement proper TLS support and secure communication protocols for DDNS credential transmission. Organizations should also consider network segmentation and monitoring to detect unauthorized DDNS credential interception attempts. Implementing network-based intrusion detection systems can help identify suspicious traffic patterns associated with DDNS credential exposure. Security teams should also establish credential rotation procedures for DDNS services and consider implementing additional authentication layers beyond the basic username/password combinations. The vulnerability demonstrates the critical importance of secure communication implementation in embedded network devices, as outlined in industry standards such as NIST SP 800-53 and ISO/IEC 27001. Device administrators should also consider disabling DDNS functionality when not actively required, as this reduces the attack surface and minimizes the window of opportunity for credential interception attacks. Regular security assessments of networked devices should include verification of secure communication protocols and proper encryption implementation to prevent similar vulnerabilities from persisting in the network infrastructure.