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).
An attacker who has compromised — or legitimately obtained — an administrator account can:
/etc/passwd, .env, config files containing database credentials, OAuth secrets, API keys).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.
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.
flarum/core 1.8.16 — fix for the 1.x branch.flarum/core 2.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.
If upgrading is not immediately possible:
forum.css for unexpected content that could indicate prior exploitation.There is no configuration-level mitigation on affected versions — the fix requires the upgraded code.
Reported to the Flarum Foundation by William (Liam) Snow IV (@LiamSnow), discovered during a graduate-level network security lab at Worcester Polytechnic Institute.
{
"cwe_ids": [
"CWE-22",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-22T20:34:52Z",
"nvd_published_at": "2026-05-08T17:16:30Z",
"severity": "MODERATE"
}