CVE-2026-123196: Authorizer before 2.4.2 Password Reset Poisoning via x-authorizer-url gRPC metadata

Published Nov 5, 2026

Updated

Authorizer before 2.4.2 contains a password reset poisoning vulnerability that allows unauthenticated attackers to control emailed link hosts by supplying x-authorizer-url gRPC metadata. Attackers can send this metadata to the gRPC port or a Grpc-Metadata-X-Authorizer-Url header through the REST gateway to capture reset or magic-link tokens and take over accounts.

Event History

Nov 5, 2026

CVE Published

via MITRE·06:16 PM

Data Sourced

via MITRE·06:16 PM

DescriptionSeverityWeakness

Data Sourced

via NVD·07:17 PM

DescriptionSeverityWeakness

Frequently Asked Questions

Which deployments are exposed to this issue?

Authorizer deployments running a version before 2.4.2 are affected if an attacker can reach the gRPC port or the REST gateway endpoint that accepts the Grpc-Metadata-X-Authorizer-Url header.

Does exploitation require an account or other prior access?

No. The issue is exploitable by an unauthenticated attacker, although the attacker must induce a user to use a password-reset or magic link sent to an attacker-controlled host.

What is the practical impact of a successful exploit?

An attacker can control the host embedded in emailed password-reset or magic links, capture the associated tokens, and use them to take over accounts.

What should be done if the affected service cannot be upgraded immediately?

Restrict untrusted access to the gRPC port and REST gateway, particularly paths or proxies that permit clients to supply x-authorizer-url metadata or the Grpc-Metadata-X-Authorizer-Url header.

How can defenders look for exploitation attempts?

Review gRPC and REST gateway logs for requests carrying x-authorizer-url metadata or the Grpc-Metadata-X-Authorizer-Url header, especially around password-reset or magic-link requests.

CVE-2026-123196: Authorizer before 2.4.2 Password Reset Poisoning via x-authorizer-url gRPC metadata

Event History

Frequently Asked Questions

Which deployments are exposed to this issue?

Does exploitation require an account or other prior access?

What is the practical impact of a successful exploit?

What should be done if the affected service cannot be upgraded immediately?

How can defenders look for exploitation attempts?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed to this issue?

Does exploitation require an account or other prior access?

What is the practical impact of a successful exploit?

What should be done if the affected service cannot be upgraded immediately?

How can defenders look for exploitation attempts?