Baikal CalDAV Servers Need a DAV Authentication Inventory
Baikal is a lightweight CalDAV and CardDAV server with a web administration interface. It is often deployed to synchronize contacts and calendars across phones, desktop clients, and office applications. The product exposes more than one access path: the DAV endpoints that clients use, the discovery endpoints under /.well-known, and the administrative interface.
The ZoomEye query on 15 November 2026 found 17 matches for app="Baikal", 313 for title="Baikal", and 498,201 for http.body="Baikal" with sub_type=all, page 1, and page size 1. The body result is not a deployment count because "Baikal" is a place name and appears in unrelated pages. Use the application fingerprint and exact title as the product-specific signals.
Discovery is not authorization
Baikal's installation documentation includes redirects from /.well-known/caldav and /.well-known/carddav to the DAV endpoint. The troubleshooting guide notes that some clients, including Windows 10, do not support Digest authentication. A deployment may therefore choose Basic authentication over TLS or move authentication to a reverse proxy.
Each choice changes where credentials are checked. Confirm that the proxy does not pass an externally supplied identity header to the DAV application, that TLS is enforced at the public boundary, and that the administrative interface has its own access rule. A DAV client can be authenticated while a browser session to the admin page is not, or the reverse. The owner should document both.
Check the configured base path. A deployment installed below /baikal needs the well-known redirects and the proxy paths to agree with the externally visible URL. A mismatch can break clients or expose an unintended path. Do not infer the full configuration from a title match; verify it with the owner.
Review users and shared collections
List DAV users, administrators, shared calendars, address books, and public links. Test a user against a collection they should not see, a disabled account, and a share that has been revoked. Review password reset and invitation paths, and confirm that backups contain the same authentication data in a protected form.
The server may be small, but calendar and contact data includes schedules, relationships, phone numbers, and internal meeting details. A discovery endpoint that is intentionally public should reveal only the service location, not user collections. Logging should record authentication failures without storing passwords or full request bodies.
Top comments (0)