CVE-2026-82451: stored XSS — MEDIUM

CISO Take

Formwork, a flat-file PHP CMS, fails to escape the HTTP Referer header before logging it for visit tracking, allowing an unauthenticated attacker to plant malicious markup that executes in an administrator's browser the moment they open the Statistics panel. There is no CVE in CISA KEV, no EPSS score published, and no public exploit or Nuclei template exists yet, so this looks opportunistic rather than actively weaponized today — but the attack requires no authentication and only low complexity (CVSS 6.1, AV:N/AC:L/PR:N), meaning any bot or crafted link can seed the payload without needing access to the target site. Because Formwork itself is not an AI/ML package (it does not appear in AI package trackers), the direct blast radius to AI pipelines is limited; the practical risk is to any admin dashboard or internal tooling site (including ML/AI internal documentation or dashboards) built on Formwork, where a compromised admin session could lead to full site takeover. Patch to the fixed release once available (track the GHSA-hpgc-57cm-66pc advisory), and in the meantime sanitize/HTML-encode the Referer value before rendering it in the Statistics panel or strip Referer-derived host data from stored logs entirely. Detection: monitor for anomalous or script-like values in Referer headers hitting public-facing pages and audit `panel/views/statistics/index.php` for unescaped output.

Sources: NVD GitHub Advisory

What is the risk?

Medium risk overall. Exploitability is straightforward (unauthenticated, low complexity, network vector) since the attacker only needs to make a request with a crafted Referer header — no credentials, no complex chaining. Impact is bounded by CVSS scope-changed but limited confidentiality/integrity impact (C:L/I:L, A:N): the payload executes in the administrator's browser session, enabling session/cookie theft, CSRF-style admin actions, or panel defacement, but does not directly compromise the server or underlying data at rest. Exposure is currently low signal — no KEV listing, no EPSS score, no public PoC or scanner template — suggesting this is not yet under active exploitation, but stored XSS in an admin panel is a well-understood, easily automated bug class that opportunistic scanners pick up quickly once public advisories circulate.

How does the attack unfold?

Initial Access

Attacker sends an unauthenticated request to a public Formwork page with a crafted Referer header containing an XSS payload.

Persistence (Stored Payload)

Formwork logs the unescaped Referer host into its visit-tracking data store, persisting the payload until viewed.

Execution

An administrator opens the Panel's Statistics view, triggering execution of the stored script in their authenticated browser session.

Impact

The attacker's script steals the admin session/cookies or performs unauthorized actions in the panel, leading to potential full admin account takeover.

Initial Access

Attacker sends an unauthenticated request to a public Formwork page with a crafted Referer header containing an XSS payload.

Persistence (Stored Payload)

Formwork logs the unescaped Referer host into its visit-tracking data store, persisting the payload until viewed.

Execution

An administrator opens the Panel's Statistics view, triggering execution of the stored script in their authenticated browser session.

Impact

The attacker's script steals the admin session/cookies or performs unauthorized actions in the panel, leading to potential full admin account takeover.

How severe is it?

CVSS 3.1

6.1 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Changed

C Low

I Low

A None

What should I do?

1 step

1) Upgrade Formwork to the version that fixes GHSA-hpgc-57cm-66pc as soon as it is released (currently affects through 2.3.14 — check the project's GitHub releases for the patched tag). 2) As an immediate workaround, patch panel/views/statistics/index.php to HTML-encode the Referer host before rendering it, or disable/strip Referer-based host logging in the Statistics feature until patched. 3) Apply a restrictive Content-Security-Policy on the admin panel to reduce the impact of any injected script (e.g., disallow inline script execution). 4) Detection: review web server / application logs for Referer headers containing HTML/script metacharacters (<, >, javascript:, onerror=) hitting tracked pages, and audit recent Statistics panel views by administrators for signs of unexpected behavior or session anomalies. 5) Rotate admin session tokens/cookies if compromise is suspected.

How is it classified?

Auth Bypass Data Leakage Framework

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.2 - Data and AI system security

Frequently Asked Questions

What is CVE-2026-82451?

Formwork, a flat-file PHP CMS, fails to escape the HTTP Referer header before logging it for visit tracking, allowing an unauthenticated attacker to plant malicious markup that executes in an administrator's browser the moment they open the Statistics panel. There is no CVE in CISA KEV, no EPSS score published, and no public exploit or Nuclei template exists yet, so this looks opportunistic rather than actively weaponized today — but the attack requires no authentication and only low complexity (CVSS 6.1, AV:N/AC:L/PR:N), meaning any bot or crafted link can seed the payload without needing access to the target site. Because Formwork itself is not an AI/ML package (it does not appear in AI package trackers), the direct blast radius to AI pipelines is limited; the practical risk is to any admin dashboard or internal tooling site (including ML/AI internal documentation or dashboards) built on Formwork, where a compromised admin session could lead to full site takeover. Patch to the fixed release once available (track the GHSA-hpgc-57cm-66pc advisory), and in the meantime sanitize/HTML-encode the Referer value before rendering it in the Statistics panel or strip Referer-derived host data from stored logs entirely. Detection: monitor for anomalous or script-like values in Referer headers hitting public-facing pages and audit `panel/views/statistics/index.php` for unescaped output.

Is CVE-2026-82451 actively exploited?

No confirmed active exploitation of CVE-2026-82451 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-82451?

1) Upgrade Formwork to the version that fixes GHSA-hpgc-57cm-66pc as soon as it is released (currently affects through 2.3.14 — check the project's GitHub releases for the patched tag). 2) As an immediate workaround, patch `panel/views/statistics/index.php` to HTML-encode the Referer host before rendering it, or disable/strip Referer-based host logging in the Statistics feature until patched. 3) Apply a restrictive Content-Security-Policy on the admin panel to reduce the impact of any injected script (e.g., disallow inline script execution). 4) Detection: review web server / application logs for Referer headers containing HTML/script metacharacters (`<`, `>`, `javascript:`, `onerror=`) hitting tracked pages, and audit recent Statistics panel views by administrators for signs of unexpected behavior or session anomalies. 5) Rotate admin session tokens/cookies if compromise is suspected.

What systems are affected by CVE-2026-82451?

This vulnerability affects the following AI/ML architecture patterns: ML/AI internal admin dashboards, self-hosted documentation/CMS portals adjacent to AI infrastructure.

What is the CVSS score for CVE-2026-82451?

CVE-2026-82451 has a CVSS v3.1 base score of 6.1 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

ML/AI internal admin dashboardsself-hosted documentation/CMS portals adjacent to AI infrastructure

Compliance Controls Affected

ISO 42001: A.6.2.2

What are the technical details?

Original Advisory

Formwork through 2.3.14 contains a stored cross-site scripting vulnerability in visit tracking that records the Referer header host unescaped. Unauthenticated attackers can craft malicious Referer headers to inject markup that executes in administrator browsers when viewing the Statistics panel.

Exploitation Scenario

An unauthenticated attacker crafts a link or automated request to a public page on the target's Formwork site, setting the Referer header to a value containing an XSS payload (e.g., `<script>...</script>` as the 'host'). Formwork's visit-tracking logic records this unescaped value into its statistics store. When a site administrator later opens the Panel's Statistics view to review traffic sources, the stored payload executes in their authenticated browser session — as a Same-Site-scoped script it can exfiltrate session cookies, perform actions as the admin (e.g., create a new admin user, modify site content), or pivot to further reconnaissance of the internal network the admin panel resides on.

Weaknesses (CWE)

CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Primary CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
[Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.