GHSA-gccq-h3xj-jgvf
CRITICALPixelfed doesn't check OAuth Scopes in API routes, giving elevated permissions
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
pixelfed/pixelfedReal-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
When processing requests authorization was improperly and insufficiently checked, allowing attackers to access far more functionality than users intended, including to the administrative and moderator functionality of the Pixelfed server.
This vulnerability affects every version of Pixelfed between v0.10.4 and v0.11.9, inclusive. A proof of concept of this vulnerability exists.
Details
In vulnerable versions of Pixelfed (versions before 0.11.11), when the API checked the request for permissions to perform a certain behavior, it did not check that the OAuth Application/Client had granted access to those API endpoints, it only checked if the user was authenticated via an access token, and if the user was the owner of the resource or an admin on the instance.
This meant that an attacker could request an access token for "read" permissions to authenticate you with their application, but the access token that they obtained actually could be used for "write" or even administrative actions, and the user who granted access to their account had zero knowledge of this elevated access.
Proof of Concept
- Create an access token either via 2-legged OAuth flow for the
readscope, or create a Personal Access Tokens with thereadscope. - Using that Access Token, perform a request that would need a particular higher-privilege scope, for instance, following a user or performing an administrative request. (respectively requiring
followoradmin:readandadmin:writescopes in the patched versions) - Observe that despite your access token having
readpermissions, the follow or administrative request was successful.
e.g., Maybe an attacker collects an access token (which expires in 1 year) wants to do something really nasty to an admin, such as disabling federation on their target's pixelfed server. As long as that server has instance.enable_cc configured (defaults to true), then the attacker can use the read scoped access token and perform the following request:
POST /api/admin/config/update
Content-Type: application/json
Accept: application/json
Authorization: Bearer <access token with read scope>
{ "key": "federation.activitypub.enabled": "value": false }
And federation of that pixelfed server would be subsequently disabled, as if the administrator had disabled it.
Impact
This vulnerability affects every local user of a Pixelfed server, and can potentially affect the servers' ability to federate.
Some user interaction is required to setup the conditions to be able to exercise the vulnerability, but the attacker could conduct this attack time-delayed manner, where user interaction is not actively required, since access tokens in Pixelfed have a 1-year lifetime before they expire, and users' often forget to revoke access tokens for applications that they are no longer using.
This also means that Access Tokens that may have been leaked from third-party OAuth Application's databases would be usable for a significant amount of time by potential attackers.
Prior versions
Whilst this vulnerability is listed as >= 0.10.4, there is potential that versions before 0.10.4 are also vulnerable to this sort of security bypass, however, given that the code changed significantly between 0.10.3 and 0.10.4 we've been unable to easily assess if these heavily outdated versions are vulnerable or not to this exploit.
Sponsorship
The work involved in investigating and remediation of this security vulnerability was provided by Nivenly Foundation, for whom we are grateful for their support of the Fediverse and Pixelfed.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | pixelfed/pixelfed | ≥ 0.10.4&&< 0.11.11 | 0.11.11 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pixelfed/pixelfed. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update pixelfed/pixelfed to 0.11.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gccq-h3xj-jgvf 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.
How O3 protects you
O3 pinpoints whether GHSA-gccq-h3xj-jgvf is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-gccq-h3xj-jgvf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-gccq-h3xj-jgvf in your dependencies?
O3 detects GHSA-gccq-h3xj-jgvf across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.