DEV Community

Yealink: 110,802 titles against 35,421 fingerprints, and the provisioning file behind both

Two ZoomEye queries were run against the same corpus on 28 October 2026. title="Yealink" returned 110,802 matches. app="Yealink" returned 35,421. The gap is about three to one, and it says something about how desk phones announce themselves.

Yealink builds IP desk phones, conference units and Teams-certified video devices. Those devices sit on the same access VLAN as laptops, they hold a SIP registration and, in most deployments, they fetch their entire configuration from a server on every boot.

What the two queries select

title="Yealink" matches the HTML title of the device web interface. Almost every desk phone ships with a local admin page, and most leave it enabled because the installer needs it once. That page is what the title query finds: a device that answers HTTPS (or plain HTTP) with a login form.

app="Yealink" matches protocol-level product recognition rather than the page title. The number is smaller because a device behind a reverse proxy, a device with the web server disabled, and a device whose page was rewritten by a custom template will not match.

Both counts refer to the same product family; neither is a count of exposed phones in total. The three-to-one ratio is the useful part. Roughly two-thirds of the hosts that present a Yealink page are not being classified as Yealink at the application layer. For an asset inventory that depends on fingerprints, that two-thirds is invisible.

Provisioning is the interface that matters

A Yealink phone does very little out of the box. On boot it looks for a provisioning server, typically over HTTPS, and downloads a configuration tree: network settings, SIP accounts, line keys, firmware references, and sometimes a phonebook. The location is set by DHCP option 66, by a redirection service keyed on the device MAC, or by hand.

Three consequences follow.

  • The provisioning server configures everything, including trust. If the certificate on that server is not validated, an attacker on the path can hand the phone a config with their own SIP registrar. Whether validation happens is a device setting, and on older firmware it is often a checkbox that ships unchecked.
  • The MAC address is the credential. Redirection services identify a device by its MAC rather than by a secret. A MAC is visible on the local segment and, in some deployments, in the web interface itself.
  • The local admin page is a configuration editor. Default credentials on these devices are documented and widely unchanged. Once authenticated, the page can read the SIP password, the provisioning URL, and the phonebook, and it can point the device at a different server.

A work list that starts with your own inventory

  • Query your own ranges, not the internet: title="Yealink" && ip="10.0.0.0/8" in ZoomEye, or the equivalent in your scanner. The 110,802 figure is context; your phones are the task.
  • On each phone, confirm the admin password is not the factory value. This is a manual or scripted check, and it is the single highest-value item on the list.
  • Confirm the provisioning URL uses HTTPS and that the device validates the certificate. Where the platform supports it, pin the provisioning host.
  • Disable the web interface where the platform allows it after provisioning, or restrict it to a management VLAN.
  • Treat a phone as a credential holder: the SIP account on it can place calls, and on many systems that account can also read voicemail.
  • Put phones on their own VLAN with an explicit rule set toward the call server and the provisioning server, and nothing else.

Why the number is not the finding

A desk phone with a login page is not a vulnerability. It is a device doing what its manual describes. The finding is the combination: a page that is reachable from a network segment with more hosts on it than the phone expects, a factory password, and a provisioning channel that can redirect the device to a different server without the phone noticing.

The 110,802 and 35,421 counts describe how much of the voice estate is visible to a title-based query versus an application-based one. The number an organisation should care about is how many of its own phones still accept the password printed in the box.

Sources

  • ZoomEye AI SDK queries title="Yealink" (110,802 matches) and app="Yealink" (35,421 matches), page size 1, sub_type all, executed 28 October 2026 Beijing time.
  • Yealink device administration documentation covering auto-provisioning, DHCP option 66 and the local web interface.
Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.