CVE-2026-27752: Cleartext Credential Exposure in SODOLA SL902-SWTGW124AS Switches

The SODOLA SL902-SWTGW124AS is a 6-port 2.5G Web Managed Switch designed for high-speed network environments. Its primary administration method is a web-based management interface. This vulnerability stems from the device's failure to implement transport layer encryption (SSL/TLS) for this interface.

When an administrator logs into the switch to configure VLANs, QoS, or aggregation settings, the authentication mechanism operates over standard HTTP (TCP port 80). Consequently, the username and password used for authentication are transmitted across the network in plaintext. This flaw is cataloged as CWE-319 (Cleartext Transmission of Sensitive Information).

The vulnerability is present in firmware versions up to and including 200.1.20. While physical access or local network presence is typically required to exploit this, the impact is critical because compromising a switch grants an attacker significant control over the network traffic flowing through it.

The root cause of CVE-2026-27752 is the exclusive use of unencrypted HTTP for the administrative web server. In a secure implementation, management interfaces dealing with authentication should enforce HTTPS, utilizing TLS (Transport Layer Security) to create an encrypted tunnel between the client (administrator's browser) and the server (the switch).

In the affected firmware, the web server daemon binds to port 80 and accepts POST requests containing credentials without any prior key exchange or encryption handshake. The firmware likely lacks the necessary certificate management logic or simply has the HTTPS service disabled by default or unimplemented.

This architecture violates the principle of confidentiality. Any intermediate node or passive tap on the network path can read the application-layer data. Since HTTP is a stateless text-based protocol, the credentials appear as readable strings within the packet payload.

Due to the closed-source nature of the firmware, we examine the vulnerability via network protocol analysis rather than source code diffs. The following demonstrates the traffic captured during a login event.

Vulnerable Traffic Capture (HTTP):

POST /login.cgi HTTP/1.1
Host: 192.168.1.1
User-Agent: Mozilla/5.0 ...
Content-Type: application/x-www-form-urlencoded
Content-Length: 45
 
username=admin&password=SuperSecretPassword123

As shown above, the password parameter is visible in the HTTP body. A simple packet capture reveals the credentials immediately.

Secure Implementation (Expected Behavior):

In a patched or secure scenario, the connection would occur over port 443. The initial packets would be a TLS Handshake (Client Hello, Server Hello). The HTTP payload containing the credentials would be encapsulated within TLS Application Data records:

[TLS Record Layer]
  Content Type: Application Data (23)
  Version: TLS 1.2 (0x0303)
  Length: 64
  Encrypted Data: <unreadable binary blob>

The absence of this TLS layer in the SODOLA switch is the direct technical failure enabling exploitation.

Exploiting this vulnerability requires the attacker to have a position in the network path between the administrator and the switch. This is a classic "On-Path" or "Man-in-the-Middle" scenario.

1. Passive Sniffing (Promiscuous Mode): If the attacker is connected to a hub or a switch port configured for port mirroring (SPAN) that sees the management traffic, they simply run a sniffer like Wireshark or tcpdump.

2. Active Interception (ARP Spoofing): On a switched network, an attacker can broadcast forged ARP packets to associate the switch's IP address with the attacker's MAC address. This forces traffic destined for the switch to flow through the attacker's machine first.

3. Credential Extraction: The attacker filters the captured traffic for HTTP POST requests or Authorization headers destined for the switch IP. Tools like dsniff or Wireshark filters (http.request.method == "POST") can automate the extraction of the credential string.

The compromise of a network switch represents a critical infrastructure failure. Unlike a compromised endpoint, a compromised switch allows an attacker to manipulate the network topology itself.

Confidentiality Impact (High): The attacker gains valid administrative credentials. They can log in and view the entire configuration, including other sensitive data or SNMP community strings.

Integrity Impact (High): With admin access, an attacker can:

• Modify VLANs: Bypass network segmentation to access restricted subnets.
• Port Mirroring: Configure the switch to mirror all traffic from a victim port (e.g., the CEO's uplink) to a port controlled by the attacker, enabling massive data theft.
• Denial of Service: Administratively shut down uplinks or specific ports, causing network outages.

CVSS Context: The CVSS v4.0 score of 8.2 (High) reflects the high impact on the confidentiality of the vulnerable system (VC:H) and the low complexity of the attack (AC:L), despite the requirement for network access (AV:N).

As of the disclosure, firmware versions up to 200.1.20 are affected. Immediate remediation focuses on network architecture changes to compensate for the lack of encryption.

1. Management VLAN Isolation: Configure the switch so that the management interface is only accessible from a dedicated, restricted VLAN. Access to this VLAN should be tightly controlled via firewall rules, preventing general user traffic from reaching the management IP.

2. Jump Host / VPN Access: Do not expose the web interface to the general LAN. Require administrators to connect via a secure VPN or SSH tunnel to a jump host that resides on the management VLAN. This ensures the cleartext HTTP traffic only travels across a short, trusted link (from the jump host to the switch) rather than across the entire network.

3. Firmware Updates: Monitor the vendor (Sodola Networks) for a firmware release that implements HTTPS/TLS. If a newer version becomes available, test and deploy it immediately to permanently resolve the issue.

4. Browser Warnings: Modern browsers will often flag HTTP login forms as "Not Secure." Administrators should heed these warnings and refrain from logging in if they are on an untrusted network segment (e.g., over Wi-Fi).