211,018 Zimbra and 62,630 Roundcube Assets: Choosing Which Webmail Surface to Defend First

Webmail is a small number of applications protecting a very large amount of content. When an organization runs both a groupware platform and a standalone webmail client, the exposure decision between them is not obvious, and measurement helps.

The measurements

On 20 October 2026, between 22:33 and 22:37 UTC, queries with sub_type="all" and a page size of one returned:

Zimbra is observed at roughly 3.4 times the Roundcube population. Both are far below the protocol counts, which describe every host answering those protocols rather than a specific product.

Why the comparison is not about relative security

Zimbra is a full groupware platform: mail, calendar, contacts and collaboration, usually serving an entire organization. Roundcube is a webmail client that connects to an existing mail infrastructure.

That difference determines the consequence of compromise. A Zimbra compromise reaches calendars capable of revealing meeting participants and locations, shared folders holding documents, and the full mail archive of every account on the platform. A Roundcube compromise reaches the session it serves, and through the underlying mail store's credentials, potentially more.

Neither is better or worse by design. They are different amounts of trust concentrated in one place, and the exposure decision should follow the concentration rather than the count.

The IMAP number explains the architecture question

23 million hosts answering IMAP, against 211,000 identifiable Zimbra instances, illustrates how much mail infrastructure exists outside recognizable groupware platforms. That population includes appliances, small mail servers and older deployments.

It also explains the persistence of webmail clients. Where the underlying mail store is an IMAP server of any vintage, a webmail front end provides a browser interface without replacing the back end.

For a defender, that means the webmail client is often the only modern authentication layer in front of an ageing mail store. Treating it as a peripheral component is a misreading of where the security boundary sits.

What to prioritize

The decision procedure for an environment with both:

1. Map authentication. Which system terminates authentication, and does it enforce MFA, SSO or password policy? The system that terminates authentication is the one whose compromise is total.
2. Map the data behind each. Calendars and shared drives raise the impact of a groupware compromise above a mail-only surface.
3. Check the version separately for each. Groupware platforms and webmail clients have independent release cycles, and neither is updated by the other's patches.
4. Review plugin and extension inventories. Both ecosystems support extensions, and both have suffered repeated extension-level vulnerabilities. This is the least visible part of the surface.
5. Verify that the client cannot be reached without the platform's authentication. A webmail client that accepts credentials directly bypasses whatever controls the groupware enforces.

Step five is a design question that is easy to get wrong during incremental deployment. It is also the question that determines whether identity controls apply to the mail surface at all.

The Exchange number as context

app="Exchange" at 2,370,255 is a different scale again, and it represents a platform with a long history of exploitation in internet-facing configurations. Its presence in this comparison is a reminder that mail platform exposure is not a niche problem: the three products measured here together describe several million observable mail surfaces.

For an organization, none of those global numbers change the local decision. The decision is which of your surfaces terminates authentication, which holds the most consequential data, and which is furthest behind on patching.

References

• ZoomEye, search interface, queried 20 October 2026 for the dorks listed above.
• Zimbra, security center.
• CISA, Known Exploited Vulnerabilities Catalog.