GHSA-32wx-4gxx-h48f
Fix: flarum/tags@c8fcd00GHSA-32wx-4gxx-h48f is a security vulnerability in flarum/tags. O3 Security confirms whether GHSA-32wx-4gxx-h48f is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Users can edit the tags of any discussion
Real-World Exposure
flarum/tagsReal-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
This advisory concerns a vulnerability which was patched and publicly released on October 5, 2020.
Impact
This vulnerability allowed any registered user to edit the tags of any discussion for which they have READ access using the REST API.
Users were able to remove any existing tag, and add any tag in which they are allowed to create discussions. The chosen tags still had to match the configured Tags minimums and maximums.
By moving the discussion to new tags, users were able to go around permissions applied to restricted tags. Depending on the setup, this can include publicly exposing content that was only visible to certain groups, or gain the ability to interact with content where such interaction was limited.
The full impact varies depending on the configuration of permissions and restricted tags, and which community extensions are being used. All tag-scoped permissions offered by extensions are impacted by this ability to go around them.
Forums that don't use restricted tags and don't use any extension that relies on tags for access control should not see any security impact. An update is still required to stop users from being able to change any discussion's tags.
Forums that don't use the Tags extension are unaffected.
Patches
The fix will be available in version v0.1.0-beta.14 with Flarum beta 14. The fix has already been back-ported to Flarum beta 13 as version v0.1.0-beta.13.2 of the Tags extension.
Workarounds
Version v0.1.0-beta.13.2 of the Tags extension allows existing Flarum beta 13 forums to fix the issue without the need to update to beta 14.
Forums that have not yet updated to Flarum beta 13 are encouraged to update as soon as possible.
References
For more information
If you have any questions or comments about this advisory, please start a new discussion on our support forum.
If you discover a security vulnerability within Flarum, please send an e-mail to [email protected]. All security vulnerabilities will be promptly addressed. More details can be found in our security policy.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | flarum/tags | all versions | 0.1.0-beta.13.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flarum/tags. 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 flarum/tags to 0.1.0-beta.13.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-32wx-4gxx-h48f 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-32wx-4gxx-h48f 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-32wx-4gxx-h48f. 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-32wx-4gxx-h48f in your dependencies?
O3 detects GHSA-32wx-4gxx-h48f across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.