CVE-2026-55375: canto-saas-api: OAuth credentials logged via query params
GHSA-37pm-83g7-r22v MEDIUMThe jleehr/canto-saas-api PHP library (≤2.0.0) incorrectly transmits OAuth2 credentials — app_secret, refresh_token, and authorization code — as URL query parameters in POST requests to the Canto token endpoint, causing them to be written in plain text to web server logs, proxy logs, and APM traces. Any actor with read access to those log stores, including DevOps personnel, third-party APM vendors, or a compromised log aggregation platform, can extract these credentials and use them to obtain valid Canto access tokens indefinitely. There is no public exploit and the CVE is not in CISA KEV, but log-based credential exposure is a chronic blind spot in enterprise environments — APM and error-tracking integrations (e.g., Sentry) are rarely treated as secret material boundaries. Upgrade to 3.0.0 immediately, which moves credentials to the POST body per RFC 6749 §2.3.1; if you cannot upgrade, treat all logs from affected systems as confidential and rotate any exposed app secrets now.
What is the risk?
Medium technical severity (CVSS 5.3) but operationally higher than the score suggests. The confidentiality impact is rated High in the vector (C:H), meaning a successful attacker obtains the full app_secret enabling persistent impersonation of the application against the Canto tenant. Attack complexity is High (AC:H) because the attacker must first gain log access, but this barrier is lower than it appears: centralized log platforms, APM SaaS tools, and error trackers routinely ingest these logs and expose them to broad internal audiences. For AI pipelines that use Canto as a digital asset store for training data or inference inputs, tenant compromise could enable data exfiltration or silent asset replacement. No EPSS score is available and no active exploitation has been observed.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Microsoft APM | composer | <= 2.0.0 | 3.0.0 |
Do you use Microsoft APM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
6 steps-
Upgrade to canto-saas-api 3.0.0 — credentials move to the POST form body per RFC 6749 §2.3.1 and exception messages are sanitized before rethrowing.
-
If upgrade is blocked, immediately restrict access to web server, proxy, and APM logs on systems that perform Canto OAuth calls; treat them as secret material.
-
Catch AuthorizationFailedException in your application code and strip the query string before logging or forwarding to error trackers.
-
Audit historical Sentry (or equivalent) error captures for exceptions containing 'oauth/api/oauth2/token' with credential query params.
-
Search existing log archives for the pattern: requests to the Canto token endpoint containing 'app_secret=' or 'refresh_token=' in the URL.
-
Rotate the Canto app_secret for any tenant where logs may have been exposed, then re-verify that new token requests no longer appear in logs post-upgrade.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-55375?
The jleehr/canto-saas-api PHP library (≤2.0.0) incorrectly transmits OAuth2 credentials — app_secret, refresh_token, and authorization code — as URL query parameters in POST requests to the Canto token endpoint, causing them to be written in plain text to web server logs, proxy logs, and APM traces. Any actor with read access to those log stores, including DevOps personnel, third-party APM vendors, or a compromised log aggregation platform, can extract these credentials and use them to obtain valid Canto access tokens indefinitely. There is no public exploit and the CVE is not in CISA KEV, but log-based credential exposure is a chronic blind spot in enterprise environments — APM and error-tracking integrations (e.g., Sentry) are rarely treated as secret material boundaries. Upgrade to 3.0.0 immediately, which moves credentials to the POST body per RFC 6749 §2.3.1; if you cannot upgrade, treat all logs from affected systems as confidential and rotate any exposed app secrets now.
Is CVE-2026-55375 actively exploited?
No confirmed active exploitation of CVE-2026-55375 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-55375?
1. Upgrade to canto-saas-api 3.0.0 — credentials move to the POST form body per RFC 6749 §2.3.1 and exception messages are sanitized before rethrowing. 2. If upgrade is blocked, immediately restrict access to web server, proxy, and APM logs on systems that perform Canto OAuth calls; treat them as secret material. 3. Catch AuthorizationFailedException in your application code and strip the query string before logging or forwarding to error trackers. 4. Audit historical Sentry (or equivalent) error captures for exceptions containing 'oauth/api/oauth2/token' with credential query params. 5. Search existing log archives for the pattern: requests to the Canto token endpoint containing 'app_secret=' or 'refresh_token=' in the URL. 6. Rotate the Canto app_secret for any tenant where logs may have been exposed, then re-verify that new token requests no longer appear in logs post-upgrade.
What systems are affected by CVE-2026-55375?
This vulnerability affects the following AI/ML architecture patterns: AI tool integrations with cloud DAM platforms, Training data pipelines using external asset stores, OAuth-authenticated AI API client libraries.
What is the CVSS score for CVE-2026-55375?
CVE-2026-55375 has a CVSS v3.1 base score of 5.3 (MEDIUM).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0055 Unsecured Credentials AML.T0106 Exploitation for Credential Access Compliance Controls Affected
What are the technical details?
Original Advisory
## 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.
Exploitation Scenario
An attacker with access to a victim organization's centralized log platform — via a compromised DevOps credential, a misconfigured Elasticsearch/OpenSearch cluster, or through a third-party APM SaaS (Datadog, New Relic) with overly broad data access — queries for HTTP traffic to the Canto OAuth token endpoint. Because the library passes app_secret and refresh_token as URL query parameters, they appear in the request URL recorded by every intermediate logging layer. The attacker extracts the credentials and submits a token request to Canto, obtaining a valid access token. With this token, they authenticate as the victim application, browse and exfiltrate the organization's Canto tenant (including AI training data, proprietary media, or labeled datasets), and rotate the credentials to maintain persistence — all while the legitimate application continues operating, masking the intrusion.
Weaknesses (CWE)
CWE-209 Generation of Error Message Containing Sensitive Information
Primary
CWE-598 Use of GET Request Method With Sensitive Query Strings
Primary
CWE-209 — Generation of Error Message Containing Sensitive Information: The product generates an error message that includes sensitive information about its environment, users, or associated data.
- [Implementation] Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- [Implementation] Handle exceptions internally and do not display errors containing potentially sensitive information to a user.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N References
Timeline
Related Vulnerabilities
CVE-2026-46858 9.1 Oracle APM: unauthenticated write/DoS via JVM Diagnostics
Same package: apm CVE-2026-45539 7.4 Microsoft APM: symlink attack leaks host files in agent deps
Same package: apm GHSA-rf84-wr5g-m3rp 5.5 CAPM3: cross-namespace auth bypass exposes K8s secrets
Same package: apm CVE-2025-53767 10.0 Azure OpenAI: SSRF EoP, no auth required (CVSS 10)
Same attack type: Data Extraction CVE-2025-2828 10.0 LangChain RequestsToolkit: SSRF exposes cloud metadata
Same attack type: Data Extraction