Summary
pH7Builder before 18.6.0 contains a hard-coded private API key and weak host-based access control in its API handling logic. An unauthenticated attacker may spoof the Host header and provide the embedded key to bypass API checks and retrieve sensitive member information.
pH7Builder before 18.6.0 contains a hard-coded private API key and weak host-based access control in its API handling logic. An unauthenticated attacker may spoof the Host header and provide the embedded key to bypass API checks and retrieve sensitive member information.
Affected context
The vulnerability occurs in pH7Builder deployments where the affected API logic in Tool.class.php remains enabled and relies on a built-in private API key together with the request Host header to authorize access. Risk is increased when the API is externally reachable and member records contain contact, network, or financial fields.
The vulnerability occurs in pH7Builder deployments where the affected API logic in Tool.class.php remains enabled and relies on a built-in private API key together with the request Host header to authorize access. Risk is increased when the API is externally reachable and member records contain contact, network, or financial fields.
Exploit preconditions
- Attack surface: The pH7Builder API exposed by the web application
- Required access: No authenticated account is generally required
- Trigger point: API authorization processing involving the Host header and private API key
- Why exploitation is possible: A hard-coded credential and spoofable host-based condition can allow requests to pass access checks without legitimate authorization
- Attack surface: The pH7Builder API exposed by the web application
- Required access: No authenticated account is generally required
- Trigger point: API authorization processing involving the Host header and private API key
- Why exploitation is possible: A hard-coded credential and spoofable host-based condition can allow requests to pass access checks without legitimate authorization
Why this happens
The underlying issue is the storage and use of a reusable API credential directly in application source code. This maps to CWE-798: Use of Hard-coded Credentials, because a secret intended to protect privileged functionality is fixed in the software and can be recovered or reused by unauthorized parties. Reliance on a client-controlled Host header as part of authorization further weakens the trust boundary.
The underlying issue is the storage and use of a reusable API credential directly in application source code. This maps to CWE-798: Use of Hard-coded Credentials, because a secret intended to protect privileged functionality is fixed in the software and can be recovered or reused by unauthorized parties. Reliance on a client-controlled Host header as part of authorization further weakens the trust boundary.
Potential impact
- Attackers may retrieve member email addresses
- Attackers could obtain IP addresses and phone numbers
- Exposed records may include bank account fields
- The application may experience unauthorized API access and privacy violations
- Leaked data could support phishing, fraud, or further account-targeted attacks
- Attackers may retrieve member email addresses
- Attackers could obtain IP addresses and phone numbers
- Exposed records may include bank account fields
- The application may experience unauthorized API access and privacy violations
- Leaked data could support phishing, fraud, or further account-targeted attacks
General mitigation guidance
Mitigation generally focuses on removing embedded secrets from authorization logic and ensuring that request metadata cannot independently establish trust.
Common defensive patterns include:
- Replacing hard-coded credentials with securely managed, rotatable secrets or scoped tokens
- Using server-side authorization tied to authenticated identities and explicit permissions
- Treating the Host header and similar request headers as untrusted input
- Applying strict API allowlisting, rate limits, and response-field minimization
- Preventing sensitive financial and personal fields from being returned unless specifically required
- Running the application with least-privilege access to data stores and services
- Rotating any credentials that may have been exposed through source code or deployed artifacts
Mitigation generally focuses on removing embedded secrets from authorization logic and ensuring that request metadata cannot independently establish trust.
Common defensive patterns include:
- Replacing hard-coded credentials with securely managed, rotatable secrets or scoped tokens
- Using server-side authorization tied to authenticated identities and explicit permissions
- Treating the Host header and similar request headers as untrusted input
- Applying strict API allowlisting, rate limits, and response-field minimization
- Preventing sensitive financial and personal fields from being returned unless specifically required
- Running the application with least-privilege access to data stores and services
- Rotating any credentials that may have been exposed through source code or deployed artifacts
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis searches for credential-like literals in PHP source files
- Code review checks for API keys embedded in application logic
- Tests that alter Host and related forwarding headers to verify authorization boundaries
- API gateway or web server logs showing unauthenticated requests with unusual Host values or private-key parameters
- Data-access monitoring for unexpected bulk retrieval of member contact or financial fields
- Policy enforcement that blocks secrets in source repositories and build artifacts
Organizations can look for this weakness through:
- Static analysis searches for credential-like literals in PHP source files
- Code review checks for API keys embedded in application logic
- Tests that alter Host and related forwarding headers to verify authorization boundaries
- API gateway or web server logs showing unauthenticated requests with unusual Host values or private-key parameters
- Data-access monitoring for unexpected bulk retrieval of member contact or financial fields
- Policy enforcement that blocks secrets in source repositories and build artifacts
