## Summary In affected versions, the OAuth2 token request sends `app_id`, `app_secret`, `refresh_token` and `code` as URL query parameters of the POST request to `https://oauth.<domain>/oauth/api/oauth2/token`. Request URLs are commonly recorded in access logs, proxy logs and APM traces, so the application secret and refresh token can be persisted in plain text outside the application's control. In addition, when the token request fails, the Guzzle exception message — which contains the full request URI including the credentials — was passed unmodified into the `AuthorizationFailedException` thrown by `OAuth2::obtainAccessToken()`. Applications that log exceptions or forward them to error trackers (e.g. Sentry) may therefore have recorded the app secret in their logs. ## Impact An attacker with access to web server logs, proxy logs, APM tracing data or application error logs of a consumer of this library can obtain the Canto `app_secret`, `refresh_token` or authorization `code` and use them to obtain access tokens for the Canto tenant. ## Patches Fixed in 3.0.0: - OAuth credentials are sent in the form-encoded POST body instead of the URL query string (RFC 6749 §2.3.1). `OAuth2Request::getQueryParams()` now returns `null`; the parameters are available via `getFormParams()`. - Exception messages are sanitized before being rethrown: the values of `app_secret`, `refresh_token` and `code` are masked (including url-encoded, differently cased and JSON-embedded variants). ## Workarounds If you cannot upgrade: - Treat web server, proxy and APM logs of systems performing Canto OAuth requests as secret material and restrict access to them. - Catch `AuthorizationFailedException` in your application and strip the query string from the message before logging or forwarding it. If your logs may have been exposed, rotate the affected Canto app secret.
## Summary In affected versions, the OAuth2 token request sends `app_id`, `app_secret`, `refresh_token` and `code` as URL query parameters of the POST request to `https://oauth.<domain>/oauth/api/oauth2/token`. Request URLs are commonly recorded in access logs, proxy logs and APM traces, so the application secret and refresh token can be persisted in plain text outside the application's control. In addition, when the token request fails, the Guzzle exception message — which contains the full request URI including the credentials — was passed unmodified into the `AuthorizationFailedException` thrown by `OAuth2::obtainAccessToken()`. Applications that log exceptions or forward them to error trackers (e.g. Sentry) may therefore have recorded the app secret in their logs. ## Impact An attacker with access to web server logs, proxy logs, APM tracing data or application error logs of a consumer of this library can obtain the Canto `app_secret`, `refresh_token` or authorization `code` and use them to obtain access tokens for the Canto tenant. ## Patches Fixed in 3.0.0: - OAuth credentials are sent in the form-encoded POST body instead of the URL query string (RFC 6749 §2.3.1). `OAuth2Request::getQueryParams()` now returns `null`; the parameters are available via `getFormParams()`. - Exception messages are sanitized before being rethrown: the values of `app_secret`, `refresh_token` and `code` are masked (including url-encoded, differently cased and JSON-embedded variants). ## Workarounds If you cannot upgrade: - Treat web server, proxy and APM logs of systems performing Canto OAuth requests as secret material and restrict access to them. - Catch `AuthorizationFailedException` in your application and strip the query string from the message before logging or forwarding it. If your logs may have been exposed, rotate the affected Canto app secret.
Update jleehr/canto-saas-api to 3.0.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scancanto-saas-api: OAuth credentials exposed in URL query string and exception messages affects jleehr/canto-saas-api (composer). Severity is medium. ## Summary In affected versions, the OAuth2 token request sends `app_id`, `app_secret`, `refresh_token` and `code` as URL query parameters of the POST request to `https://oauth.<domain>/oauth/api/oauth2/token`. Request URLs are commonly recorded in access logs, proxy logs and APM traces, so the application secret and refresh token can be persisted in plain text outside the application's control. In addition, when the token request fails, the Guzzle exception message — which contains the full request URI including the credentials — was passed unmodified into the `AuthorizationFailedException` thrown by `OAuth2::obtainAccessToken()`. Applications that log exceptions or forward them to error trackers (e.g. Sentry) may therefore have recorded the app secret in their logs. ## Impact An attacker with access to web server logs, proxy logs, APM tracing data or application error logs of a consumer of this library can obtain the Canto `app_secret`, `refresh_token` or authorization `code` and use them to obtain access tokens for the Canto tenant. ## Patches Fixed in 3.0.0: - OAuth credentials are sent in the form-encoded POST body instead of the URL query string (RFC 6749 §2.3.1). `OAuth2Request::getQueryParams()` now returns `null`; the parameters are available via `getFormParams()`. - Exception messages are sanitized before being rethrown: the values of `app_secret`, `refresh_token` and `code` are masked (including url-encoded, differently cased and JSON-embedded variants). ## Workarounds If you cannot upgrade: - Treat web server, proxy and APM logs of systems performing Canto OAuth requests as secret material and restrict access to them. - Catch `AuthorizationFailedException` in your application and strip the query string from the message before logging or forwarding it. If your logs may have been exposed, rotate the affected Canto app secret.
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| jleehr/canto-saas-apicomposer | <=2.0.0 | 3.0.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate jleehr/canto-saas-api to 3.0.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scancanto-saas-api: OAuth credentials exposed in URL query string and exception messages affects jleehr/canto-saas-api (composer). Severity is medium. ## Summary In affected versions, the OAuth2 token request sends `app_id`, `app_secret`, `refresh_token` and `code` as URL query parameters of the POST request to `https://oauth.<domain>/oauth/api/oauth2/token`. Request URLs are commonly recorded in access logs, proxy logs and APM traces, so the application secret and refresh token can be persisted in plain text outside the application's control. In addition, when the token request fails, the Guzzle exception message — which contains the full request URI including the credentials — was passed unmodified into the `AuthorizationFailedException` thrown by `OAuth2::obtainAccessToken()`. Applications that log exceptions or forward them to error trackers (e.g. Sentry) may therefore have recorded the app secret in their logs. ## Impact An attacker with access to web server logs, proxy logs, APM tracing data or application error logs of a consumer of this library can obtain the Canto `app_secret`, `refresh_token` or authorization `code` and use them to obtain access tokens for the Canto tenant. ## Patches Fixed in 3.0.0: - OAuth credentials are sent in the form-encoded POST body instead of the URL query string (RFC 6749 §2.3.1). `OAuth2Request::getQueryParams()` now returns `null`; the parameters are available via `getFormParams()`. - Exception messages are sanitized before being rethrown: the values of `app_secret`, `refresh_token` and `code` are masked (including url-encoded, differently cased and JSON-embedded variants). ## Workarounds If you cannot upgrade: - Treat web server, proxy and APM logs of systems performing Canto OAuth requests as secret material and restrict access to them. - Catch `AuthorizationFailedException` in your application and strip the query string from the message before logging or forwarding it. If your logs may have been exposed, rotate the affected Canto app secret.
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| jleehr/canto-saas-apicomposer | <=2.0.0 | 3.0.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard