Summary
Grav's Clockwork profiler can be accessed without authentication when it trusts a loopback REMOTE_ADDR value supplied through a same-host HTTP proxy. An attacker who can reach the profiler in this deployment context may read records containing system details, plugin configuration, secrets, request metadata, and database queries.
Grav's Clockwork profiler can be accessed without authentication when it trusts a loopback REMOTE_ADDR value supplied through a same-host HTTP proxy. An attacker who can reach the profiler in this deployment context may read records containing system details, plugin configuration, secrets, request metadata, and database queries.
Affected context
The issue occurs in Grav deployments that enable the Clockwork profiler and determine client locality from request address information that may be influenced or rewritten by a same-host HTTP proxy. It becomes risky when the profiler endpoint is reachable without authentication and its records contain sensitive operational or application data.
The issue occurs in Grav deployments that enable the Clockwork profiler and determine client locality from request address information that may be influenced or rewritten by a same-host HTTP proxy. It becomes risky when the profiler endpoint is reachable without authentication and its records contain sensitive operational or application data.
Exploit preconditions
- Attack surface: The Clockwork profiler endpoint exposed by a Grav application
- Required access: Network access to the profiler endpoint; authentication may not be required
- Deployment condition: Traffic passes through a same-host HTTP proxy or similar component that causes the application to trust a loopback
REMOTE_ADDRvalue - Trigger point: A request to retrieve profiler records
- Why exploitation is possible: Access control relies on an insufficiently trustworthy client-address signal rather than robust authentication and authorization
- Attack surface: The Clockwork profiler endpoint exposed by a Grav application
- Required access: Network access to the profiler endpoint; authentication may not be required
- Deployment condition: Traffic passes through a same-host HTTP proxy or similar component that causes the application to trust a loopback
REMOTE_ADDRvalue - Trigger point: A request to retrieve profiler records
- Why exploitation is possible: Access control relies on an insufficiently trustworthy client-address signal rather than robust authentication and authorization
Why this happens
The vulnerability results from treating a loopback REMOTE_ADDR value as sufficient proof that a request originates from a trusted local client. In deployments involving a same-host proxy, that trust decision can incorrectly classify an unauthenticated request as local and permit access to profiler data. This maps to CWE-200: Exposure of Sensitive Information, because diagnostic records can disclose secrets, configuration, request details, and query data to an unauthorized party.
The vulnerability results from treating a loopback REMOTE_ADDR value as sufficient proof that a request originates from a trusted local client. In deployments involving a same-host proxy, that trust decision can incorrectly classify an unauthenticated request as local and permit access to profiler data. This maps to CWE-200: Exposure of Sensitive Information, because diagnostic records can disclose secrets, configuration, request details, and query data to an unauthorized party.
Potential impact
- An attacker may obtain application and system configuration details
- Secrets or sensitive plugin settings could be disclosed
- Request metadata and database queries may be exposed
- Exposed information could support further attacks or privilege escalation
- Operational and application behavior may become easier to profile
- An attacker may obtain application and system configuration details
- Secrets or sensitive plugin settings could be disclosed
- Request metadata and database queries may be exposed
- Exposed information could support further attacks or privilege escalation
- Operational and application behavior may become easier to profile
General mitigation guidance
Mitigation generally focuses on treating proxy-provided client-address information as untrusted and protecting diagnostic interfaces independently of network locality.
Common defensive patterns include:
- Requiring strong authentication and authorization for profiler and debugging endpoints
- Allowing trusted proxy headers only from explicitly configured proxy identities
- Keeping diagnostic interfaces disabled or isolated outside controlled development workflows
- Redacting secrets, tokens, credentials, and sensitive query data from profiler records
- Restricting profiler access through network policy and least-privilege administrative roles
- Applying secure-by-default settings that do not expose diagnostic data to unauthenticated clients
Mitigation generally focuses on treating proxy-provided client-address information as untrusted and protecting diagnostic interfaces independently of network locality.
Common defensive patterns include:
- Requiring strong authentication and authorization for profiler and debugging endpoints
- Allowing trusted proxy headers only from explicitly configured proxy identities
- Keeping diagnostic interfaces disabled or isolated outside controlled development workflows
- Redacting secrets, tokens, credentials, and sensitive query data from profiler records
- Restricting profiler access through network policy and least-privilege administrative roles
- Applying secure-by-default settings that do not expose diagnostic data to unauthenticated clients
How teams detect issues like this
Organizations can look for this class of issue through:
- Static and configuration analysis for profiler endpoints protected only by loopback checks
- Code review of
REMOTE_ADDR, forwarded headers, and trusted-proxy handling - Tests that send requests through local proxies and verify authentication remains mandatory
- Web-server and application logs showing unauthenticated access to diagnostic routes
- Policy checks that prohibit publicly reachable debugging or profiling interfaces
- Automated security review tools that flag sensitive data exposure and weak network-based authorization
Organizations can look for this class of issue through:
- Static and configuration analysis for profiler endpoints protected only by loopback checks
- Code review of
REMOTE_ADDR, forwarded headers, and trusted-proxy handling - Tests that send requests through local proxies and verify authentication remains mandatory
- Web-server and application logs showing unauthenticated access to diagnostic routes
- Policy checks that prohibit publicly reachable debugging or profiling interfaces
- Automated security review tools that flag sensitive data exposure and weak network-based authorization
