Hi maintainers,
v2.7 still appears to carry the pre-fix unserialize() calls in src/Models/OAuth2.php that CVE-2026-29782 (insecure deserialization → RCE) addresses. Upstream commit d2e38cbd — "fix: Remote Code Execution via Insecure Deserialization in OAuth2" — turns:
unserialize($this->attributes['access_token'])
unserialize($this->access_token)
into the safer two-arg form that only allows AccessToken::class:
unserialize($this->attributes['access_token'], ['allowed_classes' => [AccessToken::class]])
unserialize($this->access_token, ['allowed_classes' => [AccessToken::class]])
I checked src/Models/OAuth2.php on v2.7 — both call sites are still the single-arg variant, the allowed_classes keyword does not appear, and git compare v2.7...d2e38cbd shows behind_by=162. Following the v2.5 / v2.6 reports (#1795, #1796) — is v2.7 still in the supported window for security cherry-picks? Glad to send a clean PR if it helps.
Cheers,
vulgraph
Hi maintainers,
v2.7still appears to carry the pre-fixunserialize()calls insrc/Models/OAuth2.phpthat CVE-2026-29782 (insecure deserialization → RCE) addresses. Upstream commitd2e38cbd— "fix: Remote Code Execution via Insecure Deserialization in OAuth2" — turns:into the safer two-arg form that only allows
AccessToken::class:I checked
src/Models/OAuth2.phponv2.7— both call sites are still the single-arg variant, theallowed_classeskeyword does not appear, andgit compare v2.7...d2e38cbdshows behind_by=162. Following the v2.5 / v2.6 reports (#1795, #1796) — is v2.7 still in the supported window for security cherry-picks? Glad to send a clean PR if it helps.Cheers,
vulgraph