pH7Builder CVE-2026-108904

Exploitation requires the attacker to hold a valid private API key for the target pH7Builder instance and to reach the member API's UserController::users()/user() endpoints, which return unfiltered database rows on versions before 18.5.0. The limiting factors are: (1) a valid private API key is mandatory (PR:L) - anonymous attackers cannot exploit this; (2) the target must expose the member API to the attacker; and (3) only unpatched versions prior to 18.5.0 are affected. The leaked hashValidation reset tokens being non-expiring removes any time-window limit on token replay, amplifying the post-disclosure impact.

This is a credible but bounded risk best characterized as medium-severity requiring authentication. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation with no user interaction, but PR:L means an attacker must already hold a valid private API key - this is not an anonymous, internet-wide exposure. The impact is concentrated on confidentiality (VC:H) with no integrity or availability effect (VI:N/VA:N), which aligns with CWE-522 (Insufficiently Protected Credentials): the API returns bcrypt password hashes, non-expiring hashValidation reset tokens, and TOTP secrets. The real-world danger is the secondary effect - leaked reset tokens and TOTP secrets enable account takeover and 2FA bypass, so confidentiality loss cascades into integrity compromise even though the base vector scores VI:N. No EPSS score, no CISA KEV listing, and no public exploit were provided, so there is no evidence of active or automated exploitation; the patch and root cause are, however, firmly confirmed by the vendor commit. Net: prioritize patching for any internet-facing pH7 deployment that issues API keys, but this is not a drop-everything emergency on the level of an unauthenticated RCE - the PR:L barrier and niche product footprint temper urgency. Note one signal-vs-text nuance: the vector says PR:L (a valid private API key), which is weaker than full user authentication, so a leaked or over-provisioned key materially widens exposure.

An attacker who has obtained a valid private API key (e.g., a low-trust integration partner, a compromised third-party app, or a leaked key) calls the member API's users()/user() endpoints and receives raw database rows including bcrypt hashes, hashValidation reset tokens, and TOTP secrets. Using the non-expiring reset tokens and TOTP secrets, the attacker takes over targeted member accounts and bypasses two-factor authentication. No public exploit code was identified at time of analysis, but the vulnerable code path and fix are confirmed in the vendor's GitHub commit.