AuthPoint Gateway inventory should start with reachability
WatchGuard AuthPoint Gateway handles authentication for deployments that connect to LDAP or Active Directory providers. CVE-2026-121639 describes a missing authentication flaw that lets a remote unauthenticated attacker with network access disrupt authentication services and delete the local directory synchronization configuration. Versions from 1.0 before 7.6.0 are affected. Version 7.6.0 is fixed.
The service is not a generic web application. Its exposure depends on the gateway role, the directory configuration, and the network path from untrusted clients. Public search results can help identify visible pages, but the decisive inventory is the firewall and service topology around each gateway.
On November 13, 2026, at about 06:50 China Standard Time, I ran two count-only ZoomEye probes. Both used sub_type=all, page 1, and page size 1. The app query app="WatchGuard AuthPoint" returned 0 matches. The title query title="AuthPoint" returned 29 matches.
The app zero is a fingerprint gap, not a statement that no gateway exists. The 29 title matches may include documentation, portals, or login pages associated with AuthPoint. They do not prove that the gateway host is reachable or that it uses LDAP or Active Directory.
Reconcile the external view with the network path
Start with the identity team's gateway inventory. List each host, role, software version, directory provider, management network, and recovery owner. Compare the list with firewall rules, load balancer listeners, and cloud security groups.
Then review the public title matches. For each match, determine whether it is an AuthPoint service, a support page, or an unrelated mention. Do not probe an unrelated system or attempt authentication without authorization.
The highest priority is any gateway reachable from a broad network while configured with LDAP or Active Directory. Patch that host and restrict reachability. If patching must wait, use network controls as containment and monitor configuration changes.
Prepare for identity recovery
Keep an access-controlled copy of the approved directory synchronization configuration. Record the service account, directory endpoints, certificate dependencies, and validation steps. A deleted local configuration can interrupt synchronization even after the application is restored.
Review gateway and network logs for unexpected requests to administrative or synchronization paths. Watch for configuration changes that do not match a change record. The vendor has not reported exploitation in the wild, so teams should use their own baseline rather than inventing indicators.
The completion check should confirm the fixed version, the actual network reachability, the directory connection state, and a tested recovery path. The 0 app count is a reminder that a product can be absent from one index while still sitting in a critical authentication path. The 29 title matches are candidates for ownership review, not evidence of compromise.
Top comments (0)