CVE-2026-55375 in canto-saas-api
Summary
by MITRE • 09/15/2026
canto-saas-api is a PHP library for interacting with the Canto SaaS API. Prior to version 3.0.0, OAuth2Request::getQueryParams() places app_id, app_secret, refresh_token, and code in the URL query string of token POST requests, allowing access logs, proxy logs, and APM traces to persist the credentials in plaintext. When a token request fails, OAuth2::obtainAccessToken() also passes the credential-bearing Guzzle request URI into AuthorizationFailedException, so application logs and error trackers can record the same secrets. An attacker with access to affected telemetry can obtain Canto credentials and use them to request access tokens for the tenant. This issue is fixed in version 3.0.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified within canto-saas-api versions prior to 3.0.0 represents a critical information disclosure flaw rooted in improper handling of sensitive authentication credentials during API interactions. As a PHP library designed for interacting with the Canto SaaS API, this component is responsible for managing OAuth2 token requests which are fundamental to maintaining secure access between client applications and the service provider. The core technical deficiency lies within the implementation of the OAuth2Request::getQueryParams() method and the error handling logic in OAuth2::obtainAccessToken(). Specifically, when constructing POST requests for obtaining or refreshing tokens, these methods incorrectly append critical credentials such as app_id, app_secret, refresh_token, and code to the URL query string rather than utilizing secure request bodies. This deviation from standard security practices exposes sensitive data to multiple vectors of interception that are typically considered safe in modern web architectures.
The operational impact of this vulnerability is severe due to the widespread use of logging mechanisms for debugging, monitoring, and compliance purposes. Because the credentials are placed in the URL query string, they become visible in HTTP access logs maintained by web servers like Nginx or Apache, which routinely record full request URIs including query parameters. Furthermore, reverse proxies such as HAProxy or AWS Application Load Balancers often log these URLs for traffic analysis and security auditing. Modern Application Performance Monitoring tools and distributed tracing systems also capture the complete URI of outgoing requests to provide visibility into service latency and dependencies. In all these scenarios, the plaintext secrets are persisted in structured logs that may be stored for extended periods, increasing the window of opportunity for an attacker who gains access to any system with read permissions on these telemetry data stores.
Additionally, the vulnerability extends beyond standard operational logging through improper exception handling. When a token request fails due to network issues or server errors, the OAuth2::obtainAccessToken() method propagates the Guzzle request URI containing the credentials into an AuthorizationFailedException. This means that application-level error logs and third-party error tracking services like Sentry or Bugsnag will record these exceptions along with their associated context data. Consequently, even if infrastructure-level logging is secured, the application's own diagnostic outputs serve as a secondary vector for credential leakage. An attacker who compromises any system capable of reading these log files can extract the app_id and app_secret, which are typically long-lived secrets used to authenticate API requests.
From an attack perspective, this flaw aligns with CWE-209: Generation of Error Message Containing Sensitive Information and CWE-532: Insertion of Sensitive Information into Log File. The exposure allows for credential harvesting without requiring direct exploitation of the application logic itself, relying instead on passive observation of system telemetry. This activity is categorized under MITRE ATT&CK technique T1078: Valid Accounts, as it enables an attacker to obtain valid credentials that can be used to impersonate legitimate users or services. Once obtained, these credentials allow the adversary to request access tokens for the tenant associated with the compromised app_id and app_secret. This grants unauthorized access to Canto SaaS resources, potentially leading to data exfiltration, modification of content management systems, or further lateral movement within environments where this API integration is trusted.
The resolution involves upgrading canto-saas-api to version 3.0.0 or later, which corrects the implementation by removing credentials from URL query strings and ensuring they are transmitted securely via request bodies as per OAuth2 best practices. For organizations unable to immediately upgrade, mitigations include implementing strict log filtering rules to scrub sensitive parameters before persistence in access logs and application error trackers. Additionally, rotating any app_id and app_secret values that may have been exposed through existing logs is essential to mitigate the risk of retrospective exploitation. Ensuring that logging configurations do not capture full URIs with query strings for authenticated endpoints provides a defensive layer against similar vulnerabilities in other components of the software stack.