Summary
Grav contains an authorization bypass in its Debugger request authorization logic that may expose Clockwork profiler data to unauthenticated visitors. When Grav operates behind a same-host reverse proxy, remote requests can appear to originate from loopback, allowing attackers to read stored records that may include administrator passwords and configuration credentials.
Grav contains an authorization bypass in its Debugger request authorization logic that may expose Clockwork profiler data to unauthenticated visitors. When Grav operates behind a same-host reverse proxy, remote requests can appear to originate from loopback, allowing attackers to read stored records that may include administrator passwords and configuration credentials.
Affected context
The issue affects Grav installations that enable the Debugger and expose the /__clockwork/ profiler endpoint. Risk is greater when a reverse proxy or similar intermediary forwards requests in a way that causes the application to treat external clients as loopback or otherwise trusted origins. Profiler records may retain sensitive application and administrative data.
The issue affects Grav installations that enable the Debugger and expose the /__clockwork/ profiler endpoint. Risk is greater when a reverse proxy or similar intermediary forwards requests in a way that causes the application to treat external clients as loopback or otherwise trusted origins. Profiler records may retain sensitive application and administrative data.
Exploit preconditions
- Attack surface: The exposed
/__clockwork/profiler data endpoint - Required access: No authentication may be required when the authorization check is bypassed
- Trigger point: Processing a request through
Debugger::isDebuggerRequestAuthorized() - Deployment condition: A same-host reverse proxy or intermediary causes the remote address to appear as loopback
- Why exploitation is possible: The authorization logic relies on a trusted loopback address without reliably distinguishing proxy-originated requests from local requests
- Attack surface: The exposed
/__clockwork/profiler data endpoint - Required access: No authentication may be required when the authorization check is bypassed
- Trigger point: Processing a request through
Debugger::isDebuggerRequestAuthorized() - Deployment condition: A same-host reverse proxy or intermediary causes the remote address to appear as loopback
- Why exploitation is possible: The authorization logic relies on a trusted loopback address without reliably distinguishing proxy-originated requests from local requests
Why this happens
The underlying bug is an authorization decision based on an insufficiently trustworthy client-address signal. A loopback REMOTE_ADDR fallback is treated as proof that a request is local, but a reverse-proxy deployment can make remote traffic appear to originate from the loopback interface. This maps to CWE-200 because the resulting authorization bypass can disclose sensitive profiler records and embedded credentials.
The underlying bug is an authorization decision based on an insufficiently trustworthy client-address signal. A loopback REMOTE_ADDR fallback is treated as proof that a request is local, but a reverse-proxy deployment can make remote traffic appear to originate from the loopback interface. This maps to CWE-200 because the resulting authorization bypass can disclose sensitive profiler records and embedded credentials.
Potential impact
- Unauthenticated attackers may read stored profiler and Clockwork records
- Administrator plaintext passwords could be exposed
- Configuration credentials and other secrets may be disclosed
- Attackers could use recovered credentials to access administrative or backend systems
- Disclosure may support further compromise, lateral movement, or data tampering
- Unauthenticated attackers may read stored profiler and Clockwork records
- Administrator plaintext passwords could be exposed
- Configuration credentials and other secrets may be disclosed
- Attackers could use recovered credentials to access administrative or backend systems
- Disclosure may support further compromise, lateral movement, or data tampering
General mitigation guidance
Mitigation generally focuses on removing implicit trust in network-origin
indicators and protecting diagnostic endpoints by default.
Common defensive patterns include:
- Require explicit authentication and authorization for profiler and debugging endpoints
- Disable debugging and diagnostic data collection in production environments
- Avoid treating loopback source addresses as sufficient proof of user identity
- Define and validate trusted proxy boundaries explicitly
- Minimize sensitive data retained in profiler records and redact credentials before storage
- Apply least privilege to administrative and configuration credentials
- Use secure secret storage and rotate credentials that may have been captured
- Restrict diagnostic endpoints at the reverse proxy and network-policy layers
Mitigation generally focuses on removing implicit trust in network-origin
indicators and protecting diagnostic endpoints by default.
Common defensive patterns include:
- Require explicit authentication and authorization for profiler and debugging endpoints
- Disable debugging and diagnostic data collection in production environments
- Avoid treating loopback source addresses as sufficient proof of user identity
- Define and validate trusted proxy boundaries explicitly
- Minimize sensitive data retained in profiler records and redact credentials before storage
- Apply least privilege to administrative and configuration credentials
- Use secure secret storage and rotate credentials that may have been captured
- Restrict diagnostic endpoints at the reverse proxy and network-policy layers
How teams detect issues like this
Organizations can look for:
- Static analysis rules identifying authorization decisions based solely on REMOTE_ADDR or loopback checks
- Code review signals involving proxy headers, trusted-proxy configuration, and debugger endpoint exposure
- Integration tests that exercise diagnostic endpoints through both direct access and reverse-proxy paths
- Access logs showing unauthenticated requests to
/__clockwork/or unusual retrieval of profiler records - Policy checks requiring authentication, production debug disabling, and explicit proxy trust configuration
- Automated security review tools that flag publicly reachable debugging or profiling interfaces
Organizations can look for:
- Static analysis rules identifying authorization decisions based solely on REMOTE_ADDR or loopback checks
- Code review signals involving proxy headers, trusted-proxy configuration, and debugger endpoint exposure
- Integration tests that exercise diagnostic endpoints through both direct access and reverse-proxy paths
- Access logs showing unauthenticated requests to
/__clockwork/or unusual retrieval of profiler records - Policy checks requiring authentication, production debug disabling, and explicit proxy trust configuration
- Automated security review tools that flag publicly reachable debugging or profiling interfaces
