Port 62078 – lockdownd (Apple iOS Lockdown / usbmuxd Sync Service)

Port 62078 is the TCP port that Apple iOS devices — iPhones and iPads — open for lockdownd, the on-device lockdown service. lockdownd is the front door for everything iTunes, Finder, and Xcode do with a connected device: it handles pairing, reports device info, and, once a client is trusted, starts the individual services behind it — com.apple.afc for file access, com.apple.mobilebackup2 for backups, com.apple.mobile.installation_proxy for app management, syslog relay, screenshotr, and more. Classically the device is reached over USB, where the host’s usbmuxd (“USB multiplexing daemon”) tunnels a connection to the device’s 62078; but the service genuinely listens on TCP 62078, so when iTunes/Finder Wi-Fi sync is enabled the same port becomes reachable over the network. The one thing to get right up front: lockdownd is pairing-gated. An attacker who can merely reach 62078 but holds no valid pairing record is very limited — the interesting risk is what happens when a pairing record, a trust relationship, or a Wi-Fi-sync exposure hands that access over.

Why It’s Open

Port 62078 is open because the device is an iPhone or iPad — full stop. lockdownd starts at boot and listens on 62078 for the life of the device, whether or not anything is connected. That makes an open 62078 one of the most reliable fingerprints in a scan: a host answering on 62078 is almost certainly an iOS device.

How that port gets reached depends on the transport:

• Over USB, the host runs usbmuxd, which multiplexes one USB link into many logical connections and forwards them to the device’s lockdownd on 62078. Host tools (iTunes/Finder, Xcode, libimobiledevice) never touch USB directly — they speak to usbmuxd, which relays to 62078.
• Over Wi-Fi, if the user has enabled “Sync with this [device] over Wi-Fi,” the device advertises itself with mDNS/Bonjour on port 5353 and the paired computer connects straight to TCP 62078 across the local network — no cable required.

So on a home or office subnet, an exposed 62078 usually means an iPhone with Wi-Fi sync turned on. On a corporate network it can also be a device-management or forensic workstation reaching devices. Either way, the port itself is expected on iOS hardware; the questions are whether it should be reachable from where you’re scanning, and who holds the pairing keys.

Common Risks

• Pairing-record theft grants device access. The real crown jewel is the pairing record (an escrow keybag) that a trusted computer stores after you tap “Trust” — on macOS in /var/db/lockdown/, on Windows in C:\ProgramData\Apple\Lockdown\. Anyone who lifts that file from a computer can impersonate that computer to lockdownd on 62078 and pull backups, files, and app data. This is exactly how forensic and commercial extraction tools work.
• Trust-dialog / “juice jacking” abuse. A malicious charging kiosk or computer that gets you to tap “Trust This Computer” establishes a pairing that can then be used to read data or enable Wi-Fi sync for persistent access — the basis of the Trustjacking attack (see below).
• Wi-Fi sync exposes 62078 on the network. Once Wi-Fi sync is on, the lockdown service is reachable to anything on the same LAN, widening the attack surface from “physical USB” to “everyone on the Wi-Fi.”
• Host-side sync tooling exposed to the LAN. Bugs in the desktop side — usbmuxd and the libimobiledevice/libusbmuxd stack — have bound forwarding sockets to every interface instead of localhost, exposing on-device services to the network (see CVE-2016-5104).
• AFC file access after pairing. With a valid pairing, the com.apple.afc service reachable through lockdownd exposes the media partition (and historically, via jailbreak afc2, the whole filesystem), so a trusted attacker can browse and copy data.
• Device fingerprinting. Simply finding 62078 open tells an attacker “this is an iPhone/iPad,” which is useful reconnaissance for targeting the right device-specific exploits.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

The goal on 62078 is first to confirm it’s an iOS device, then to see how far lockdownd will let you go without a pairing record versus with one. Almost all real interaction happens through the libimobiledevice tool suite, which talks to lockdownd via usbmuxd.

Confirm the port and fingerprint the device

nmap -sV -p 62078 <target>

Nmap lists 62078 as iphone-sync in its services file, and -sV will often report Apple iOS lockdownd — or, because lockdownd ignores unauthenticated probes, simply tcpwrapped. Either result is a strong “this is an iOS device” signal. Sweep a subnet to enumerate every iPhone/iPad on it:

nmap -p 62078 --open <target-range>

List devices reachable through usbmuxd

idevice_id -l          # UDIDs of USB-attached devices
idevice_id -n          # devices visible over the network (Wi-Fi sync)

Query lockdownd for device info

ideviceinfo -u <UDID>

Basic identifiers may return without a pairing; privileged domains and services require a valid pairing record.

Check the pairing/trust state

idevicepair -u <UDID> validate
idevicepair -u <UDID> list

A failed validate means no trust record — most services will be refused. A valid record means this host can start sensitive services on 62078.

Exercise services that lockdownd brokers (with a valid pairing)

ideviceinstaller -u <UDID> -l        # installed apps (installation_proxy)
idevicebackup2 -u <UDID> backup ./out # full device backup (mobilebackup2)
idevicesyslog -u <UDID>              # live device log (syslog_relay)

Forward a device service to a local port

iproxy 2222 22 <UDID>   # tunnel local :2222 to the device's SSH (e.g. jailbroken iOS)

iproxy rides usbmux to reach a service on the device; on jailbroken phones this commonly fronts SSH on port 22. Note that a bug once made these forwarding sockets listen on all interfaces (CVE-2016-5104), so always confirm what iproxy is bound to.

Record every host you positively identify as an iOS device, its pairing state, and anything you could pull with a trust record, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

There is no single blockbuster remote CVE for “port 62078.” By design, lockdownd refuses privileged requests from any client that lacks a valid pairing record, so the dominant risks here are design- and pairing-based — trust abuse, pairing-record theft, and Wi-Fi-sync exposure — rather than a memory-corruption bug you fire at the port. The verified CVEs that genuinely touch this ecosystem sit on the host side (usbmuxd and the libimobiledevice stack):

• CVE-2016-5104 — The socket_create function in common/socket.c in libimobiledevice (≤ 1.2.0) and libusbmuxd (≤ 1.0.10) bound a listening IPv4 TCP socket to INADDR_ANY instead of INADDR_LOOPBACK. Remote attackers on the same network could bypass the intended localhost restriction and communicate with services on iOS devices — i.e., forwarded device services intended to be local were exposed to the LAN. Fixed by binding to loopback.
• CVE-2025-66004 — A path-traversal (CWE-35) issue in usbmuxd (before commit 3ded00c…) lets a local user escalate to the service user. This is a host-daemon local-privilege-escalation bug, not a remote attack on the device’s 62078 — included here for completeness because usbmuxd is the daemon that fronts this port.

Beyond CVEs, the libimobiledevice suite (idevice_id, ideviceinfo, ideviceinstaller, idevicebackup2, iproxy) and commercial forensic tools are not exploits — they are legitimate clients of lockdownd. Their security relevance is that, given a stolen pairing record, they turn network reach to 62078 into a full data-extraction capability.

Removed from the previous version of this page: CVE-2021-30883 was cited as a 62078 risk “leveraged after usbmuxd access.” That is inaccurate — CVE-2021-30883 is an IOMobileFrameBuffer kernel out-of-bounds write (a local privilege-escalation / in-the-wild exploit chain component) with no relationship to lockdownd, usbmuxd, pairing, or the network service on port 62078. It has been removed. Always scope a CVE to the actual product before trusting it on a port page.

Mitigation

• Treat pairing records as secrets. They are keys to the device. Protect the lockdown directories on any trusted computer (/var/db/lockdown on macOS, C:\ProgramData\Apple\Lockdown\ on Windows), and wipe them on machines that no longer need to sync.
• Never tap “Trust” on a computer or charger you don’t control. Use a data-blocking “USB condom,” or charge from a wall adapter, at public kiosks. On the device, Reset Location & Privacy (or Reset Trusted Computers) periodically to purge stale pairings.
• Disable Wi-Fi sync unless you use it. With it off, lockdownd on 62078 is only reachable over a physically connected cable, not across the LAN. Turn it off in Finder/iTunes for each device.
• Patch the host side. Keep usbmuxd and libimobiledevice/libusbmuxd current so the loopback-binding (CVE-2016-5104) and path-traversal (CVE-2025-66004) fixes are in place, and confirm any iproxy/forwarding tool binds to 127.0.0.1, not 0.0.0.0.
• Segment forensic/MDM workstations. Machines that legitimately reach devices over 62078 should sit on restricted networks; don’t expose device-sync tooling to untrusted segments.
• Firewall and monitor. Where iOS devices live on a managed network, restrict who can reach 62078 and watch for unexpected pairing prompts or Wi-Fi-sync connections. The same care applies to other remote-access surfaces like VNC on 5900 and any TLS-fronted admin over HTTPS on 443.

Real-World Example

The clearest illustration of the 62078 risk model is iOS Trustjacking, disclosed by Symantec researchers at RSA Conference 2018. The attack chains three things this page describes: the “Trust This Computer” pairing dialog, the pairing record it creates, and iTunes Wi-Fi sync. The victim connects their iPhone to an attacker-controlled computer (or one the attacker has compromised) and taps “Trust” just once — the sort of tap people make without thinking at a kiosk or on a borrowed cable. The attacker’s machine now holds a valid pairing record and quietly enables Wi-Fi sync. From then on, whenever the phone shares a network with that computer, the attacker can reach lockdownd on TCP 62078 over Wi-Fi with no further prompt and no cable — pulling backups, installing apps, reading app data, and even repeatedly triggering screenshotr to watch the screen in near real time. The lesson is precise: 62078 by itself is a benign, pairing-gated port, but a single misplaced “Trust” plus Wi-Fi sync converts it into a persistent, remote window into the device — which is why guarding the pairing decision and the pairing record matters far more than the port number.

FAQ

What is port 62078 used for?

Port 62078 is the TCP port an iPhone or iPad opens for lockdownd, its lockdown service. lockdownd is the entry point that iTunes, Finder, Xcode, and usbmuxd-based tools use to pair with the device and start on-device services — file access (AFC), backups, app installation, syslog, and more. Over USB it’s reached through the host’s usbmuxd; over Wi-Fi sync it’s reachable directly on the network.

Why is port 62078 open on a device I scanned?

Because the device is an iOS device. lockdownd runs from boot and listens on 62078 continuously, so an open 62078 is a reliable fingerprint that the host is an iPhone or iPad. If it’s reachable over Wi-Fi rather than only over USB, that host has iTunes/Finder Wi-Fi sync enabled.

Can an attacker who reaches port 62078 read my iPhone’s data?

Not on its own. lockdownd refuses privileged services to any client without a valid pairing record (the trust established when you tap “Trust This Computer,” and enter your passcode on modern iOS). The real danger is when an attacker obtains that pairing record — by stealing it from a trusted computer or tricking you into tapping “Trust” — after which tools like libimobiledevice can pull backups and app data over 62078.

Is port 62078 a security risk over Wi-Fi?

It can be. With Wi-Fi sync enabled, the lockdown service is reachable to everything on the same network instead of only over a physical cable, which is what makes attacks like Trustjacking persistent. If you don’t rely on Wi-Fi sync, disable it so 62078 is only reachable over USB.

How do I test what’s exposed on port 62078?

Confirm it with nmap -sV -p 62078 <target> (expect iphone-sync/lockdownd or tcpwrapped), then use the libimobiledevice suite: idevice_id -l/-n to list devices, idevicepair validate to check the trust state, and ideviceinfo/ideviceinstaller/idevicebackup2 to see what a paired client can reach. Anything that succeeds without your intending it is worth flagging.

How do I secure or close port 62078?

You can’t disable lockdownd on a stock iOS device, so harden around it: disable Wi-Fi sync, decline untrusted “Trust” prompts and reset trusted computers periodically, protect pairing records on your Macs/PCs, keep host-side usbmuxd/libimobiledevice patched, and on managed networks restrict who can reach 62078.

TL;DR

• Service: Apple iOS lockdownd (the device’s lockdown service), reached via usbmuxd/libimobiledevice for iTunes/Finder sync, backup, and app management
• Default port: 62078/TCP (over USB through usbmuxd, or directly over Wi-Fi when Wi-Fi sync is enabled)
• Biggest risk: it’s pairing-gated, so the danger is a stolen pairing record or an abused “Trust” prompt (Trustjacking) turning network reach to 62078 into full backup/file/app-data extraction — not a single remote CVE
• Mitigation: disable Wi-Fi sync, guard the “Trust” decision and pairing records, patch host-side usbmuxd/libimobiledevice (CVE-2016-5104, CVE-2025-66004), and restrict who can reach 62078