A loopback-only authorization gate is satisfied by a forged HTTP header, exposing privileged internal operations

Summary

A group of operations on the MFPsecure SOAP service are intended to be reachable only from the machine itself. The check that enforces this asks whether the request’s destination address is a loopback address. Because the service uses a binding with no signed addressing header, that destination is derived from the HTTP request itself rather than from anything the caller cannot control. A remote caller who presents the expected value satisfies the check.

The gate is the only control on these operations. Once it opens, they are reachable unauthenticated from anywhere the service is reachable.

Impact

Demonstrated: the same request, from the same remote source, is refused or served depending only on the forged header. Behind the gate, an unauthenticated remote caller obtained:

• A privileged access token for the Gateway API, carrying the service’s full scope set. The token was accepted by the Gateway’s administrative API, and the same requests without it were refused.
• User and group enumeration through the Gateway API using that token, returning names, addresses, distinguished names, security identifiers and organisational structure for the accounts in the directory.
• A write of a proximity-card identifier and PIN onto an arbitrary account. This was exercised against a disposable test account and reverted. A control account left untouched confirmed the write was attributable. Existing card values are redacted on read, so this is an overwrite rather than a disclosure. The attacker’s own card identifier and PIN end up stored against another person’s account, and because the stored values are redacted on read, the enrollment history is the only place the change is visible.

The impact falls on systems other than the one carrying the defect, namely the directory server and the Gateway credential store. The vector therefore scores subsequent-system confidentiality and integrity rather than placing the whole impact on the vulnerable component.

Affected

Vendor-stated fix

I have not verified these builds. HP named them but has not provided them to me, so I cannot confirm the issue is closed in either one. The versions above are HP’s statement, not my finding.

Mitigation

Apply the vendor update. Network isolation is worth doing generally, but it does not cleanly apply here. The affected surfaces share their endpoints and ports with traffic that the devices and end users require, so restricting by address or by port removes scanning or print release without removing the exposure. A homegrown control would have to filter each affected request individually and be maintained as the product changes, which is a stopgap rather than a fix.

Technical detail

Held, in line with the other disclosures published in this set. See CVE-2026-89082 for why.

Timeline

Credit

Reported by Joseph Chiarchiaro, Independent Security Researcher. CVE assigned and scored by HP Inc. as CNA; the vector HP assigned matches the one submitted.