Zulip API Keys and Exports Extend the Account-Removal Problem
Zulip is a team chat system with a web login, mobile clients, bots, API keys, and data export tools. A user who leaves an organization may lose the web login while an API key or bot credential remains active. Zulip's security model explicitly notes that changing a password or disabling an account in a single sign-on system does not remove access through the user's API key or bots. That statement makes account removal an inventory problem that extends beyond authentication settings.
The ZoomEye snapshot for November 8, 2026 used sub_type=all, page 1, and page size 1. app="Zulip" returned 2. title="Zulip" returned 883. http.body="Zulip" returned 451,724. The body count is far larger because it searches page content for the product name and can include documentation, comparisons, and hosted service pages. It is not a count of exposed Zulip servers. The app fingerprint is very small in this sample, while the title result gives a more useful product-level candidate set.
Zulip's authentication documentation describes JWT-based login and a JWT flow that can fetch a user's API key. The latter is powerful because it can support an application acting on behalf of a user. The deployment should therefore treat the JWT secret, algorithm, allowed issuers, and callback behavior as sensitive configuration. It should also limit which applications can request API-key retrieval and log the resulting administrative action.
Account lifecycle should include more than the primary login. When a user leaves, disable the account, revoke sessions and API keys, identify bots the user created, and transfer ownership of any integration that must continue. Review personal uploads and export privileges. Zulip's export documentation explains that an organization export is designed for migration and contains substantial organization data, while excluding secrets such as passwords and API keys. That distinction matters: the absence of a password in an export does not make the export harmless.
Organization owners should have a controlled export procedure. Record who requested the export, which organization was selected, where the file is stored, and when it is deleted. Encrypt the archive at rest, restrict access, and verify that a temporary export file cannot be downloaded by an ordinary user. If an export is used for migration, delete the source copy after the new system has passed its integrity checks.
Inventory the public surface separately. A Zulip title match may be a login page, a public organization page, documentation, or a hosted service. Confirm the deployment against DNS and application ownership. Do not attempt password guessing, API-key enumeration, or organization data requests. A safe review checks the login page, TLS, response headers, and authorized instance metadata.
The difference between 2 app matches and 883 title matches is a reminder that no single fingerprint answers the lifecycle question. The app match is strong for product identity but sparse in this sample. The title match widens the candidate list. The body match shows how easily a product name becomes a broad web search. The team should preserve all three queries and label their roles.
A Zulip removal checklist should end with evidence. The account is disabled, sessions are revoked, API keys are invalidated, bots are reassigned or disabled, and the owner confirms that no export remains accessible. Repeat the check after an SSO deprovisioning event. The security property is not that the account disappeared from the login page. It is that every credential path associated with that account has a current owner and state.
Query evidence
- Collection: 2026-11-08 00:44 UTC, ZoomEye SDK,
sub_type=all, page 1, page size 1. -
app="Zulip": 2. -
title="Zulip": 883. -
http.body="Zulip": 451,724.
Top comments (0)