CVE-2025-57176 Unauthenticated File Uploads in Ceragon Siklu Backhaul Radios

A newly publicized vulnerability in Ceragon/Siklu microwave backhaul radios — tracked as CVE‑2025‑57176 — allows unauthenticated attackers to upload arbitrary files to affected EtherHaul and MultiHaul devices via a proprietary service listening on TCP port 555. The weakness, confirmed by multiple vulnerability databases and an advisory from a U.S. federal agency, is notable because uploaded file contents travel in cleartext, metadata protection is weak, and the service performs no authentication or path validation — creating a straightforward avenue for persistent compromise of critical communications equipment. Affected operators should treat this as a high-priority operational risk: install vendor firmware updates where available, apply network controls to isolate management interfaces, and implement compensating mitigations immediately while inventorying at‑risk units.

Background / Overview​

Ceragon Networks (including Siklu-branded EtherHaul and MultiHaul product families) supplies fixed wireless backhaul and point‑to‑multipoint radios widely used by carriers, municipal networks, and service providers. These radios frequently carry mobile backhaul, enterprise circuits, and other critical services, so vulnerabilities in their management or control plane can have outsized operational and national‑critical impact.
The vulnerability concerns the device component commonly referred to as rfpiped, which listens for file transfer packets on TCP/555. According to public advisories, rfpiped accepts file upload requests without authentication, transmits file bodies in plaintext, and does not validate destination paths — meaning an attacker who can reach the service can write arbitrary files anywhere the process has write permission. Vendor remediation guidance and firmware updates were published for the affected models; however, the vendor’s support portal is gated, and some operators reported delayed or staged rollouts, so many deployed units may still be exposed.

---

What the vulnerability actually does​

How the attack surface presents​

• The affected service listens on TCP port 555 (rfpiped).
• File upload packets include weakly protected metadata while the file contents themselves are transmitted in cleartext.
• There is no authentication required to perform an upload.
• There is no path validation: the service will write to any writable path provided in the upload request.
• The service has been reported to use a static or predictable encryption/encoding scheme for metadata in some variants, making it trivial to craft valid packets.

Immediate impact vectors​

Because the vulnerability allows arbitrary file writes, an attacker can:

• Drop configuration files to change routing, management access, or service behavior.
• Upload scripts or binaries to create persistent backdoors (where execution is possible).
• Stage firmware images or modified packages that enable later privilege escalation.
• Place files that exfiltrate or redirect traffic (for example, modified DHCP/artifacts or forwarding rules).
• Render devices inoperative by overwriting critical files, causing outages to carrier or enterprise services.

The ease of exploitation is amplified when management interfaces are reachable from untrusted networks (for example, when management IPs are publicly exposed or inadequately segmented).

---

Affected products and vendor response​

Affected families and models​

Vendor and advisory texts identify both Siklu MultiHaul and Ceragon/Siklu EtherHaul models in the exposure set. Representative affected models include MultiHaul MH‑B100, MH‑T200 variants, and an extensive list of EtherHaul models (for example, EH‑8010FX and multiple EH‑5xx/6xx/7xx/12xx/22xx/25xx/55xx variants). Operators must review their inventories against vendor lists and device software levels to ascertain exposure.

Vendor remediation and recommended firmware​

Ceragon has published firmware updates that address the weakness for the affected models. The vendor‑recommended upgrades quoted in public advisories are:

• Install R2.4.0 for the affected MultiHaul models.
• Install R10.8.1 for the EH‑8010FX model.
• Install R7.7.12 for the other affected EtherHaul models.

Operators should confirm exact build numbers and install methods in their vendor portal or support channel prior to rollout. The vendor’s management portal may require authentication to download images and consult release notes.

Public disclosure and researcher activity​

A public proof‑of‑concept was published and reported to the vendor prior to coordinated disclosure; advisory records indicate a PoC author under the handle semaja22. Multiple independent vulnerability trackers and national agencies recorded the issue and published guidance. At the time of disclosure, there were no confirmed reports of targeted exploitation in the wild specifically tied to this CVE; however, ease of exploitation and prior history of related rfpiped issues make rapid remediation prudent.

---

Technical analysis: why this is dangerous​

Unrestricted upload + no authentication = high utility for attackers​

File upload vulnerabilities are powerful when the target can execute, read, or otherwise use arbitrary files placed by an attacker. Even when direct execution isn't possible, attackers can often abuse file writes to modify configurations, replace binary artifacts on subsequent updates, or create scheduled tasks. The absence of authentication multiplies the risk since no credentials or pre‑existing access are required.

Transport and encryption shortcomings​

The packet metadata protection is reportedly weak and only covers descriptors — the file contents themselves are sent unencrypted. That means passive observers on the path (or an attacker who can intercept management VLAN traffic) can view uploaded payloads, and crafted packets can be replayed or modified without robust cryptographic protections. Where devices rely on the supposed confidentiality of this protocol, that reliance has been shown to be misplaced.

Legacy and repeat vulnerability patterns​

Public reporting indicates this component has been the locus of security problems previously, including failed or incomplete fixes dating back several years. The presence of static keys or weak encryption in prior reports points to design decisions that treat encryption as an access control, rather than as confidentiality. Reoccurrence suggests a need for architectural changes rather than patching a single code path.

---

Detection and threat hunting guidance​

Operators should assume that any device with an exposed management IP and listening on TCP/555 is potentially exploitable. Recommended detection steps:

• Inventory: enumerate all radios and check firmware versions. Record model, serial, IP addresses, and firmware builds.
• Network scans: scan management networks for devices with TCP/555 open. Use passive and active methods; avoid disruptive probing during busy production windows.
• Log review: search device logs for rfpiped activity, new file write entries, or sudden configuration changes. Correlate with SIEM logs and network flow records.
• File integrity: where possible, check checksums of critical device files or stored configs against known good baselines; note unexpected file creation times.
• IDS/IPS signatures: deploy or tune signatures to look for rfpiped packet characteristics (uploads, metadata headers on port 555), and alert on connections from non‑management IPs to management plane addresses.
• Network captures: capture network traffic to/from radios to inspect for plaintext file transfers on port 555; this is particularly useful to validate active exploitation.

Avoid executing public exploit code in production environments. If you must test, do so in an isolated lab using spare hardware and following safe proof‑of‑concept procedures.

---

Immediate mitigations (what to do now)​

While firmware updates are the definitive fix, many operators will need time to stage, test, and deploy patches across geographically distributed radios. Apply these compensating controls immediately:

• Block or restrict TCP/555 at the network edge and between untrusted networks and management networks. Use firewall rules to allow management workstation IPs only.
• Ensure management IPs use private RFC‑1918 address space and are reachable only from secured management networks (VPNs or bastion hosts).
• Deploy ACLs on upstream routers/switches to permit access on port 555 only from authorized management subnets or jump hosts.
• If the device supports it, disable the rfpiped/file transfer service until patched — confirm vendor guidance before disabling to avoid breaking legitimate workflows.
• Use network segmentation: separate operational management networks from service or user traffic so a compromised access point cannot easily pivot.
• Enable and monitor administrative session logging (syslog, TACACS+/RADIUS) to detect new or unusual admin accounts and login attempts.
• Where possible, employ a centrally managed firewall or NAC to prevent unknown devices from reaching the management plane.

These steps reduce the attack surface and buy time for careful firmware rollout.

---

Detailed remediation playbook (recommended steps)​

• Inventory and prioritize
• Create a definitive list of deployed EtherHaul and MultiHaul radios.
• Prioritize units by exposure (publicly reachable, carrying critical circuits) and operational risk.
• Test the firmware update in lab
• Obtain the vendor firmware images from the official support portal.
• Test upgrades on representative hardware in an isolated lab to validate behavior, rollback, and backup/restore procedures.
• Backup configuration
• Before any upgrade, export device configurations and verify integrity of backups.
• Document current versions and snapshot device states.
• Schedule maintenance windows
• Coordinate outage windows with stakeholders since firmware updates may require reboots and could disrupt service.
• Apply patches in stages
• Use a canary approach: update a small subset, validate, then proceed in waves.
• Monitor logs and service health metrics closely after each wave.
• Verify post‑patch
• Confirm that rfpiped is no longer accepting unauthenticated uploads (or that the vendor fix is effective).
• Re‑scan to ensure TCP/555 remains blocked from untrusted networks.
• Long‑term hardening
• Enforce least‑privilege access, centralized authentication, and routine vulnerability scanning.
• Implement automated firmware lifecycle tracking to avoid lag between vendor releases and operator installs.

---

Operational considerations and risks when patching radios​

• Distributed field equipment: radios are often rooftop or tower‑mounted; staffing and logistics for scheduled reboots and firmware updates can be substantial.
• Interdependency: a firmware change may affect interoperability, timing (PTP/1588), or link stability. Test on non‑critical links first.
• Dual‑unit or HA deployments: follow vendor guidance for rolling upgrades to avoid link downtime.
• Rollback plans: ensure you can revert to prior firmware if the update introduces issues; in some cases vendors may require specific downgrade paths.
• Compliance and regulatory: confirm that firmware changes do not disrupt timing or lawful intercept obligations for service providers.

Operators should weigh the immediate security benefit against potential service impact and plan accordingly.

---

Longer‑term security recommendations for wireless backhaul​

• Treat management interfaces as a high‑value target: restrict, monitor, and harden access.
• Use mutual authentication and avoid relying on proprietary encryption alone for access control.
• Implement certificate‑based management plane authentication, role‑based access control, and central audit logging.
• Enforce hardware and firmware supply chain validation: verify firmware signatures and provenance where supported.
• Maintain a rapid‑response update process: track vendor advisories and schedule regular vulnerability reviews.
• Adopt network segmentation, micro‑segmentation, and zero‑trust principles for management and orchestration domains.
• Conduct regular adversary simulation and red‑team exercises that include infrastructure components like radios and edge devices.

---

Detection signatures and what to log​

• Alert on any inbound connection attempts to TCP/555 from non‑management networks.
• Log any file creation events in device storage areas that should only be modified by updates.
• Alert on unexpected configuration changes or user additions to administrative groups.
• Correlate NMS/SNMP traps and syslog entries for sudden reboots or firmware updates outside scheduled windows.

These monitoring activities reduce dwell time and improve the chance of detecting an unauthorized upload or subsequent lateral activity.

---

Why telecom and critical infrastructure operators must treat this as urgent​

Microwave backhaul radios form backbone links for mobile networks, fixed services, and critical communications. A successful attack that enables file upload and potential persistence could:

• Introduce backdoors allowing an attacker to control traffic or extract sensitive configuration.
• Disrupt service availability by corrupting files or configurations.
• Allow attackers to use compromised devices as pivot points into management networks.
• Temporarily or permanently break provisioning, monitoring, or alarm functions that operators rely upon to maintain service.

Because the attack vector is network‑accessible and requires no credentials, the time to remediate should be minimized. Operators serving critical services should adopt a high‑urgency posture.

---

Caveats, verification notes, and outstanding uncertainties​

• Public records and vulnerability trackers show some variation in CVSS scoring and exact product lists. A federal advisory lists a CVSS score in the mid‑range while other aggregators have recorded slightly different ratings. Operators should rely on the vendor advisory and national‑agency guidance for official prioritization and remediation instructions.
• The vendor support portal that contains firmware images and specific release notes may require authenticated access. If you do not have an active support contract or portal access, contact your vendor SAFELY through official channels to obtain images and deployment guidance.
• Some third‑party writeups describe an associated remote command execution issue in the same component (a related CVE). If both vulnerabilities affect your devices, remediation should address both code paths. Confirm all applicable CVE numbers against your device model and firmware.
• Where public proof‑of‑concept code is circulating, avoid reuse in production networks. Use vendor or certified lab environments for testing and validation.

Flag any claim you cannot validate against the vendor advisory as requiring confirmation; when in doubt, prioritize isolation and access controls.

---

Final recommendations — checklist for immediate action​

• [ ] Inventory radios and record firmware versions for MultiHaul and EtherHaul families.
• [ ] Block TCP/555 from untrusted networks; restrict access only to authorized management hosts.
• [ ] Back up configurations and test vendor firmware updates in an isolated lab.
• [ ] Apply vendor‑published firmware updates per vendor guidance (validate rollback).
• [ ] Implement monitoring rules for port 555 traffic, unexpected file writes, and admin account changes.
• [ ] Segment and harden management networks; enforce least privilege and centralized authentication.
• [ ] Coordinate with vendor support for extended guidance and confirm that all related CVEs are addressed.

---

This vulnerability shines a light on a recurring problem in embedded network equipment: when proprietary management protocols lack robust authentication and proper cryptographic design, the resulting weaknesses can be trivially exploited by network attackers. Operators must move beyond ad‑hoc hardening and build operational practices — inventory, segmentation, timely patching, and continuous monitoring — that treat every management interface as a potential compromise vector. Taking swift, staged action now will materially reduce the risk of service disruption and long‑term compromise across EtherHaul and MultiHaul deployments.

---

Source: CISA Ceragon Siklu MultiHaul and EtherHaul Series | CISA