How severe is GHSA-37pm-83g7-r22v?

GHSA-37pm-83g7-r22v has a CVSS score of 5.3/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-37pm-83g7-r22v?

GHSA-37pm-83g7-r22v affects the following packages: jleehr/canto-saas-api (Packagist). Ecosystems affected: Packagist.

How do I fix GHSA-37pm-83g7-r22v?

Update jleehr/canto-saas-api to 3.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-37pm-83g7-r22v is resolved across your whole dependency graph.

How do I detect GHSA-37pm-83g7-r22v in my Packagist dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for jleehr/canto-saas-api, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-37pm-83g7-r22v if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is GHSA-37pm-83g7-r22v actively exploited in the wild?

No public exploit code has been indexed for GHSA-37pm-83g7-r22v yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-37pm-83g7-r22v?

GHSA-37pm-83g7-r22v has an EPSS (Exploit Prediction Scoring System) score of 0.4%, placing it in the 31th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-37pm-83g7-r22v?

GHSA-37pm-83g7-r22v is classified as CWE-209 (CWE-209), CWE-598 (CWE-598). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-37pm-83g7-r22v published, and has it been updated?

GHSA-37pm-83g7-r22v was published on June 19, 2026 and was last updated on September 10, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐘

🐘 Packagist

Not in CISA KEV

MEDIUM severity

canto-saas-api: OAuth credentials exposed in URL query string and exception messagesGHSA-37pm-83g7-r22v

MEDIUM

GHSA-37pm-83g7-r22v is a medium-severity (CVSS 5.3) CWE-209 vulnerability in jleehr/canto-saas-api. A fix is available for jleehr/canto-saas-api — see the affected versions and patch details below.

Also known asCVE-2026-55375

Published

Jun 19, 2026

Updated

Sep 10, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 24, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-37pm-83g7-r22v.

EPSS Exploitation Probability

via FIRST.org ↗

0.4%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs31th percentile — riskier than 31% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-37pm-83g7-r22v by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 395,249 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected

🐘jleehr/canto-saas-api

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

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.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐘Packagist	`jleehr/canto-saas-api`	all versions	3.0.0`composer require jleehr/canto-saas-api:^3.0.0`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for jleehr/canto-saas-api, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update jleehr/canto-saas-api to 3.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-37pm-83g7-r22v is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

## 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 `Authorizati