GHSA-9QFV-WGH2-M6P8
Vulnerability from github – Published: 2026-06-19 14:13 – Updated: 2026-06-19 14:13Summary
In affected versions, Request::buildRequestUrl() inserts path variables into
the request URL without URL encoding (implode('/', $pathVariables)). All
request classes implementing getPathVariables() are affected, e.g.
GetContentDetailsRequest (scheme, contentId).
If a consuming application passes untrusted input (such as an ID taken from
an HTTP request parameter) as a path variable, characters like ../, ? or
# are sent verbatim and can change the path of the resulting API request.
## Impact
An attacker who controls a path variable value can redirect the
library's authenticated request — the Bearer access token is attached in
AbstractEndpoint::sendRequest() — to a different API endpoint of the same
Canto instance, causing unintended reads or writes with the privileges of the
configured app. The impact depends on how the consuming application sources
path variable values; applications that only pass trusted, validated IDs are
not exploitable.
## Patches
Fixed in 3.0.0: every path segment is encoded with rawurlencode() before
being inserted into the request URL.
## Workarounds
If you cannot upgrade, validate untrusted values before passing them to
request classes, e.g. enforce an allowlist pattern such as
^[A-Za-z0-9_-]+$ for content IDs and schemes.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.0"
},
"package": {
"ecosystem": "Packagist",
"name": "jleehr/canto-saas-api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55374"
],
"database_specific": {
"cwe_ids": [
"CWE-74",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T14:13:55Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n In affected versions, `Request::buildRequestUrl()` inserts path variables into\n the request URL without URL encoding (`implode(\u0027/\u0027, $pathVariables)`). All\n request classes implementing `getPathVariables()` are affected, e.g.\n `GetContentDetailsRequest` (`scheme`, `contentId`).\n\n If a consuming application passes untrusted input (such as an ID taken from\n an HTTP request parameter) as a path variable, characters like `../`, `?` or\n `#` are sent verbatim and can change the path of the resulting API request.\n\n ## Impact\n\n An attacker who controls a path variable value can redirect the\n library\u0027s authenticated request \u2014 the Bearer access token is attached in\n `AbstractEndpoint::sendRequest()` \u2014 to a different API endpoint of the same\n Canto instance, causing unintended reads or writes with the privileges of the\n configured app. The impact depends on how the consuming application sources\n path variable values; applications that only pass trusted, validated IDs are\n not exploitable.\n\n ## Patches\n\n Fixed in 3.0.0: every path segment is encoded with `rawurlencode()` before\n being inserted into the request URL.\n\n ## Workarounds\n\n If you cannot upgrade, validate untrusted values before passing them to\n request classes, e.g. enforce an allowlist pattern such as\n `^[A-Za-z0-9_-]+$` for content IDs and schemes.",
"id": "GHSA-9qfv-wgh2-m6p8",
"modified": "2026-06-19T14:13:55Z",
"published": "2026-06-19T14:13:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jleehr/canto-saas-api/security/advisories/GHSA-9qfv-wgh2-m6p8"
},
{
"type": "PACKAGE",
"url": "https://github.com/jleehr/canto-saas-api"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "canto-saas-api: Authenticated API requests can be redirected via unencoded path variables"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.