WatchGuard AuthPoint's callback trusted a signed header too much
Authentication gateways sit between an identity provider and the applications that depend on it. They are expected to reject forged login results even when an attacker can reach the callback endpoint. WatchGuard AuthPoint Gateway had a defect in exactly that location: the LDAP authentication callback validated a header signature but did not bind the signed result to the transaction fields in the request body.
WatchGuard's advisory for CVE-2026-121637 describes improper integrity validation in the LDAP authentication callback. An attacker who has obtained a valid header signature can forge the authentication result and transaction identifier in the request body, producing an unauthorized session outcome. A second issue, CVE-2026-121638, involves improper certificate validation and creates a man-in-the-middle risk.
The vendor lists AuthPoint Authentication Gateway versions from 1.0 before 7.6.0 as affected and 7.6.0 as the fixed release. The exact exposure depends on the deployment's callback path, network placement, and certificate configuration. The common mistake is to treat the gateway as an identity appliance that cannot be reached except by trusted components. A callback URL is still an internet-facing API.
A signature over the wrong scope
HMAC validation answers a narrow question: did the sender possess the shared secret and sign this header? It does not automatically prove that the body came from the same sender, belongs to the same transaction, or describes the same authentication outcome. If the receiver checks the header and then trusts body parameters independently, the signature becomes a ticket that can be replayed with modified fields.
The transaction identifier matters because it ties a challenge to a user session. If the identifier can be changed while the header remains valid, an attacker may redirect a result to another transaction or change its meaning. The authentication result matters because it is the final yes-or-no decision consumed by downstream systems. Those fields need to be inside the authenticated payload rather than left nearby.
The certificate-validation flaw creates a related trust problem. A gateway that accepts a certificate it should reject can be induced to communicate with an imposter. The consequence may be credential exposure, altered responses, or a false sense of successful authentication. MITM risk depends on where the attacker can sit in the TLS path, so not every instance has the same likelihood. The fix still belongs in the same upgrade.
What to inspect before and after patching
Inventory AuthPoint Gateway instances by version, management address, callback endpoint, and the systems that consume its authentication results. Include gateways that are behind a reverse proxy or load balancer. Confirm that the public callback path cannot be reached from arbitrary networks unless the deployment requires it.
Review certificates and trust anchors on the gateway and its LDAP dependencies. Replace certificates that were issued under a trust relationship the organization cannot explain. Check for unexpected certificate changes, private-key access, and proxy-terminated connections where the gateway cannot verify the original endpoint.
Upgrade to 7.6.0 or later. Then verify the configuration rather than assuming the installer changed it. Test that a modified body field with a valid header signature is rejected, that an invalid transaction identifier is rejected, and that an untrusted certificate fails the connection. Keep the negative tests in a controlled environment.
Detection opportunities
Authentication logs should correlate the header signature identifier, transaction ID, user identifier, source address, and final session result. Look for the same signed header used with multiple body payloads or transaction IDs. Also review successful authentications where the callback source changed unexpectedly or where a gateway accepted a certificate outside its normal issuer or fingerprint set.
Downstream applications may be the first place an unauthorized session becomes visible. Compare gateway decisions with application sessions, especially for privileged users or unusual source networks. A forged authentication result may look valid to the application because the gateway told it to proceed.
If compromise is suspected, rotate the callback shared secret, revoke affected sessions, and inspect the identity provider for changes to users, groups, and trust relationships. Preserve gateway logs before rebuilding. A version upgrade without credential rotation can leave an attacker with a previously obtained signature material.
The control lesson is simple. A signature is useful only when it covers the fields the application later trusts. Authentication callbacks need transaction binding, replay protection, strict certificate validation, and logs that connect the signed evidence to the resulting session. WatchGuard's two advisories show why those properties should be tested as one trust boundary.
Top comments (0)