GHSA-xjvc-pw2r-6878 is a medium-severity (CVSS 4.9) vulnerability in flarum/core. O3 Security confirms whether GHSA-xjvc-pw2r-6878 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Flarum: Path traversal in LESS parser via theme color settings (incomplete fix for CVE-2023-27577)
Real-World Exposure
flarum/core🐘flarum/coreReal-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
Flarum's patch for CVE-2023-27577 restricted the @import and data-uri() LESS features in the custom_less setting, but the same restriction was never applied to other settings registered as LESS config variables (for example theme_primary_color and theme_secondary_color, as well as any key registered via Extend\Settings::registerLessConfigVar()).
Those values are interpolated verbatim into the LESS source at compile time, allowing an authenticated administrator to craft a theme-color value that injects an arbitrary @import directive into the compiled forum.css. Because the underlying LESS parser honours @import (inline) '<path>', an attacker can read arbitrary files reachable by the PHP process (local file inclusion) or trigger outbound HTTP(S) requests (server-side request forgery).
Impact
An attacker who has compromised — or legitimately obtained — an administrator account can:
- Read arbitrary local files reachable by the PHP process (e.g.
/etc/passwd,.env, config files containing database credentials, OAuth secrets, API keys). - Trigger outbound HTTP/HTTPS requests from the Flarum host, enabling SSRF against internal services and cloud metadata endpoints such as
http://169.254.169.254/(AWS IMDSv1, GCP, Azure).
The contents of the attacker-controlled import are embedded into the compiled forum.css, which is publicly served — so the attacker can retrieve whatever was read simply by fetching the CSS file.
This is a privilege-escalation vulnerability: a forum administrator is not intended to have host-level file read or access to internal network resources.
Example payload
Submitted via POST /api/settings with an admin session:
{ "theme_primary_color": "#4D698E;@import (inline) '/etc/passwd';" }
The setting is stored verbatim, interpolated into the LESS source on the next CSS compile, and the target file's contents appear in /assets/forum.css.
Patches
flarum/core1.8.16 — fix for the 1.x branch.flarum/core2.0.0-rc.1 — fix for the 2.x branch.
The fix extends the existing @import / data-uri() validation in Flarum\Forum\ValidateCustomLess::whenSettingsSaving to every dirty setting whose key is registered as a LESS config variable, not just custom_less.
Workarounds
If upgrading is not immediately possible:
- Ensure administrator accounts are protected with strong, unique passwords and (where supported) two-factor authentication.
- Restrict administrator access to trusted users only.
- Review the forum's public
forum.cssfor unexpected content that could indicate prior exploitation.
There is no configuration-level mitigation on affected versions — the fix requires the upgraded code.
Resources
- CVE-2023-27577 — the original vulnerability whose patch was incomplete.
- GHSA-vhm8-wwrf-3gcw — the original advisory.
Credit
Reported to the Flarum Foundation by William (Liam) Snow IV (@LiamSnow), discovered during a graduate-level network security lab at Worcester Polytechnic Institute.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | flarum/core | all versions | 1.8.16 |
| 🐘Packagist | flarum/core | ≥ 2.0.0-beta.1&&< 2.0.0-rc.1 | 2.0.0-rc.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flarum/core. 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/core to 1.8.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xjvc-pw2r-6878 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-xjvc-pw2r-6878 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-xjvc-pw2r-6878. 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-xjvc-pw2r-6878 in your dependencies?
O3 detects GHSA-xjvc-pw2r-6878 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.