Executive brief
The canto-saas-api library, used to interact with Canto digital asset management services, incorrectly transmits sensitive OAuth credentials in web addresses (URLs) rather than secure request bodies. This means that sensitive information like application secrets and refresh tokens may be recorded in plain text within server logs, proxy records, or error tracking systems. An attacker who gains access to these logs could use the stolen credentials to access a company's Canto account and data.
Technical details
The jleehr/canto-saas-api library (versions <= 2.0.0) transmits OAuth2 credentials as URL query parameters during POST requests to the token endpoint, violating RFC 6749 §2.3.1. This behavior causes sensitive tokens and secrets to be persisted in web server access logs, proxy logs, and APM traces. Additionally, the library fails to sanitize Guzzle exception messages in the OAuth2::obtainAccessToken() method, passing the full request URI (including credentials) into the AuthorizationFailedException. An attacker with read access to application logs or error trackers (like Sentry) can extract these credentials to obtain unauthorized access tokens for the Canto tenant. Version 3.0.0 fixes this by moving credentials to the form-encoded POST body and masking sensitive values in exception messages.
Affected products
- jleehr canto-saas-api <= 2.0.0
Timeline
- 2026-06-18: disclosed
- 2026-06-19: advisory