Grav: 2.0.13 Is No Longer Enough Either — Update to Core 2.0.15

A batch of vulnerabilities (software weaknesses) that could let attackers take over a website were disclosed in July 2026 for "Grav," a piece of software used to build homepages and blogs. Published jointly by the developer Trilby Media and the security firm VulnCheck, the set includes flaws rated at the most severe "critical" level.

The most dangerous of the batch is CVE-2026-65008 (9.8 out of 10). If exploited, a remote attacker could run arbitrary programs on the server. Disclosed at the same time were a flaw that lets someone impersonate an administrator (CVE-2026-65007) and one that lets a low-privileged user escalate to administrator (CVE-2026-65603). All of them affect older versions and can be prevented by updating. As of July 29 there are still no reports of exploitation in the wild, but working attack code for CVE-2026-65008 is now circulating.

What follows lays out, in plain terms, whether your site is affected, how far you need to upgrade, and what has been added since the first version of this article.

What kind of software is Grav?

Grav is software for building homepages, blogs, documentation sites and the like. Software that manages the contents of a site this way is generally called a CMS (content management system). The most widely used CMS in the world is WordPress, but Grav is a different type, favored by developers and technically inclined users.

Its big distinguishing feature is that it does not use a database. Many CMSs store articles and settings in a separate piece of software called a database, whereas Grav keeps everything as files. This design is called "flat-file," and it has the advantages of running lightly and being easy to install and move. It is often used for technical documentation sites, small company sites, and personal blogs.

Grav's core can be combined with add-on parts called "plugins." The flaws disclosed this time are a mix of ones in Grav's core and ones in add-ons such as the login plugin and the API plugin. Which parts you use determines whether you are affected.

The versions to be on now

Here is the destination for each part first. The left column is the current recommendation, the right one is what we pointed to in the first version. If you are still on the right-hand values, flaws remain.

The current core release can be checked against the developer's own distribution manifest. As of August 5 it reads 2.0.15, dated August 3, 2026. The login plugin has a 3.9.0, but that release is mostly feature work; 3.8.13 is enough as far as these flaws go. Seven fixed releases have shipped for this batch between July 22 and August 3. The interval is short, so keep checking the admin panel's notifications even right after an update.

The vulnerabilities disclosed together in July 2026

The four flaws covered in the first version were published in Grav's official security advisory and in VulnCheck's advisory. Here is a table of "which part, which versions are affected, and which release first fixed it." Severity is out of 10: 9 and above is "critical," 7–8 is "high." The second column from the right is the fix at the time, not the version to be on today.

When the first version went out, the core problems looked settled by 2.0.7 and 2.0.9. Two more routes past the same entry point turned up afterwards, and 2.0.11 and 2.0.13 carry additional fixes. The plugins moved too: the API plugin ran on to 1.0.13 and the login plugin to 3.8.13. A fix version that keeps moving over a short window is the defining feature of this Grav episode.

Who is after this, and what do they do?

CVSS numbers and jargon alone make it hard to tell whether this concerns you. Here we break down "who, for what purpose, and with what damage."

The people who go after these flaws are attackers who mechanically scan the internet for sites built with Grav. Rather than targeting a specific someone, the expected attack pattern is to find "sites running on old Grav" one after another and test whether any exploitable holes remain.

What the attacker tries to do with a hole they find is to impersonate an administrator and rewrite the site's contents, or run their own program on the server. When it reaches the stage of "running arbitrary programs on the server," as with CVE-2026-65008, they can use that site as a base for further attacks or steal the data stored there.

The damage runs in two directions. For ordinary visitors, there is the risk of viewing a defaced page or having their information skimmed by a fake input screen. For the company or individual running the site, there is direct harm—takeover, data leakage, recovery work—plus the lingering damage of lost trust. That is exactly why upgrading to the latest version before exploitation spreads matters more than anything.

Details of each vulnerability (technical)

From here we look at each of the four flaws individually. If you are not technically inclined, the summary table and the remediation section are enough.

CVE-2026-65008: server takeover via an input form (the most dangerous)

This is the centerpiece flaw. Grav's core (2.0.4–2.0.6) had a defect in its form processing that executes externally supplied values as part of a program (code injection, technically CWE-94). The NVD (the U.S. national vulnerability database) rates its severity at 9.8 out of 10.

The attack goes like this: first a user with page-editing rights plants the trick, and that trick is then executed by a later visitor's access. What makes it nasty is that, once the payload is in place, a malicious program runs simply when an ordinary visitor who is not logged in opens the page. Because "the final trigger can be pulled by anyone," the NVD treats it as effectively exploitable without authentication and assigns the top-tier score. It was fixed in Grav 2.0.7.

CVE-2026-65007: anyone can freely issue API keys

This is a flaw in the API plugin (before 1.0.8). An API is a gateway for operating Grav from external programs, and a key called an "API key" is used to access it. The permission check on issuing and revoking these keys was insufficient, so functionality that should only be available to a limited few was in a state where any user who can log in could even create a key in someone else's name (missing authorization, CWE-862).

Get a key that impersonates another person, and you can operate the site with their privileges, leading on to seizing administrator rights or account takeover. Its severity is rated 9.6. This particular flaw was fixed in 1.0.8, but as covered below, more flaws kept surfacing in the API plugin afterwards, so the version you need is 1.0.13. Sites that do not have the API plugin installed are not affected by this family of flaws.

CVE-2026-65603: escalating to administrator from a profile update

This is a flaw in the login plugin (3.8.11 and earlier), and the one that served as the entry point for this news. In Grav, users can update their own profile, but that update process had a defect where even the "permission-determining fields" that should never be rewritten were saved as-is. Specifically, if a low-privileged user slips the instruction "make me the top administrator" into their profile update, they can behave as the top administrator from their next access (improper privilege management, CWE-269).

According to Grav's official advisory, the cause is that a previous fix added a safeguard to strip permission fields from the new-registration process, but the same safeguard was never applied to the very similar profile-update process. After escalating to administrator, one can also abuse Grav's scheduler or template features to run programs on the server. The severity is 8.8. This one was fixed in login plugin 3.8.12, but 3.8.13 — released July 14 — closes another defect on top of it, so 3.8.13 is the version to move to. Note that this flaw only works with the standard user-management setting; sites using the stricter "Flex" management method are said to be less exposed.

CVE-2026-57852: the scheduler's entry point is hit without authentication

This flaw spans Grav's core (2.0.8 and earlier) and the scheduler-webhook plugin (before 1.1.2). Grav has a "scheduler" mechanism that runs processes at set times, with an entry point (webhook) for sending a run signal from outside. The verification of the passphrase (token) here had a hole, so on a site left in its initial state without a passphrase set, a single unauthenticated request could run all the registered scheduled jobs.

This flaw was reported by a VulnCheck researcher and published as CVE-2026-57852 on July 9, 2026. Its severity is moderate, but combined with the other flaws it could widen the damage. The scheduler-webhook plugin was settled in 1.1.3, and the core side was closed in 2.0.9 (the core itself, as covered below, needs to go further still).

What has been added since the first version

A lot moved on the Grav side in the week after this article first went out on July 22. Taking it in order:

Core 2.0.11: a way around the same entry point as CVE-2026-65008

Released July 13, 2.0.11 is the main reason for the correction. CVE-2026-65008 was a defect where an instruction planted in a field's settings ("call this routine," a dynamic field) got executed as written. Guards that reject dangerous routines went in with 2.0.7 and 2.0.9, but writing the instruction a different way still slipped past them. Published as GHSA-7pgq-cr25-xvc8, it let a user with page-editing rights read files on the server and secrets held in configuration. The developer's changelog describes the fix as "closing a bypass of the guard added in 2.0.7 and 2.0.9." The same release also fixed arbitrary file reads through the image watermark feature (GHSA-w3f4-8pj2-599w).

Core 2.0.13: two code-execution flaws and a stored XSS

Released July 25, 2.0.13 closes a set of flaws affecting 2.0.12 and earlier: a configuration admin running code on the server by naming a dynamic field's data provider in a form the safety check did not inspect (GHSA-r94f-hx44-8jqf), the template engine's find and sort filters accepting a dangerous function name as their callback (GHSA-xx48-97m4-h7qm), a stored XSS that let a page editor run script in visitors' browsers (GHSA-269c-h76q-8cxw), and a backup profile that could be pointed outside the site folder (GHSA-fch7-cpv4-w7hg). Only at this point is the core where it currently needs to be.

API plugin 1.0.13: twelve advisories at once

On July 26, twelve security advisories for the API plugin were published in one go. All of them affect 1.0.12 and earlier and are fixed in 1.0.13. The common thread is that an API key issued with deliberately narrow scopes could act beyond them: a key handed out as read-only could rewrite user-group permissions, hand super-admin rights to an invited account, or mint a new key broader than itself. Most land in the "high" band. Each one is listed on the API plugin's advisory page.

Login plugin 3.8.13: sessions that never expired

Published July 14, GHSA-mj78-8gwc-vxjj affects 3.8.12 and earlier. The token issued by the "remember me" feature did not actually expire after the configured timeout (7 days by default) and stayed valid indefinitely. If such a token ever reaches a third party, they hold a logged-in session that never lapses.

CVE IDs registered after publication

CVE assignments have kept coming as well. Beyond the four covered in the first version, these landed in the NVD.

CVE-2026-65608 belongs to the same family as CVE-2026-65008 from the first version — a field's settings reaching a routine that then runs — this time on the Flex side. Its affected range starts at 1.7.0, which pulls in sites still on the old 1.7 line. Note also that the roughly fifteen advisories published on July 26 have no CVE numbers yet. A missing number says nothing about how serious the contents are.

2.0.14 shipped on July 30, and 2.0.15 on August 3

On July 29, the development changelog carried an entry for v2.0.14, dated July 27, but the release existed in no tag, no distribution file and not on Packagist — you could not get it. 2.0.14 then shipped on July 30, and 2.0.15 followed on August 3. The two flaws named in that changelog entry — an admin with account-management rights granting themselves super-admin through a user group's permissions, and a way to hide script past the content security scan — are closed in 2.0.14.

What matters more is what came after. On August 3 the developer published fourteen advisories at once, spanning the core, the API plugin and the form plugin. Six concern the core, two of them rated high. Most notably, another way around the same entry point as CVE-2026-65008 — the flaw we called the most dangerous — was still open. A branch handling dynamic values in blueprints was still gated by a denylist of forbidden functions, and anything not on that list slipped through. What we wrote on July 29 — that 2.0.11 closed the bypass — was true for what had been disclosed at that point, but the holes at that entry point were not all closed yet.

The remaining core fixes cover script that slips past the XSS check when a quote is left unpaired, an unauthenticated escape outside the file root, and script planted through the URL of audio or video embedded in a page. On the API plugin side, writing outside the file root during a page copy and importing arbitrary code through the translation feature were both fixed as high. Like the July 26 batch, none of the fourteen advisories from August 3 has a CVE number yet. The absence of a number does not make them a separate matter from what this article has been covering.

Is your site affected, and how do you check?

The first thing to check is the version of the Grav core you are using. When you log in to Grav's admin panel, the dashboard shows the current version. If it is earlier than 2.0.15, some flaw still remains. The ladder runs like this: earlier than 2.0.7 and CVE-2026-65008 itself applies; earlier than 2.0.9 and the scheduler flaw plus CVE-2026-65608 apply; earlier than 2.0.11 and the way around CVE-2026-65008 is still open; earlier than 2.0.13 and the code execution and stored XSS remain; earlier than 2.0.14 and the super-admin escalation and the scan bypass remain; and earlier than 2.0.15 and the second route around CVE-2026-65008's entry point is still open.

Next, check the plugins you have added. If you have the API plugin, confirm it is 1.0.15; if you have the login plugin, confirm it is 3.8.13; if you have the form plugin, confirm it is 9.1.19. Conversely, a site that does not use these plugins is not concerned with those flaws. By looking only at "the core version" and "the plugins you use," you can pin down whether you are affected.

Also, if you are on a much older generation of the Grav core with a version number like "1.7.x," it is likely already out of current support, and you should consider migrating to the current line sooner rather than later. CVE-2026-65608, registered on July 23, has an affected range starting at 1.7.0, so that older generation is caught up in this too.

What to do right now

The remediation is simple: it comes down to getting to core 2.0.15, API plugin 1.0.15, and login plugin 3.8.13 (plus form plugin 9.1.19 if you run it). Grav has a mechanism to update from the admin panel, and if a notification appears, you can update the core and plugins together from there. If you operate via the command line, running `bin/gpm selfupgrade` and `bin/gpm update` with Grav's package manager command (GPM) will bring the core and each plugin up to date. Afterwards, check that the version numbers have actually reached those three. "I already updated once" does not hold this time.

Before updating, always take a full backup of your files. Because flat-file Grav keeps everything as files, if you keep a copy of the whole folder, you can revert should the update ever stop things from working.

If circumstances prevent you from updating immediately, you can reduce exposure with stopgap measures such as restricting the admin panel and API entry points so they are only reachable from internal or specific IP addresses, and making sure a passphrase (token) is set on the scheduler webhook. But these are only ways to buy time; the fundamental fix is to update.

In cases like this one, where the core and multiple plugins each have separate flaws, it pays to always know "which parts you use, and at which versions." The mindset of cross-checking the parts you use against known weaknesses is also laid out in our article on a system for surfacing weaknesses in open-source components. The more plugins a site has, the more this inventory helps.

Is it being exploited in the wild?

As of July 29, 2026, there are no confirmed reports of these flaws being used in actual attacks. None of them are listed in the "catalog of vulnerabilities being actively exploited" (KEV) published by the U.S. government agency CISA, and no large-scale scanning or defacement campaign against public Grav sites has been reported. The disclosures were made as "coordinated disclosure," where the developer and a security firm fix the issues and then announce them, rather than chasing after an attack that has already happened.

The situation has moved a step on from the first version, though. A working proof-of-concept exploit for CVE-2026-65008 has been published. It is a polished piece of work: a script that runs commands and opens a shell back to the attacker, shipped with a Docker environment and instructions for reproducing it, updated as recently as July 28. The instructions note that once the payload is planted, it runs with the web server's privileges as soon as a visitor who is not logged in opens the page. In short, the research an attacker would have had to do themselves is now done for them. (We are not naming where it is hosted, since that would amount to a how-to.)

"No exploitation observed" and "this could start any day" are both true at once. While a public PoC, a stream of new CVE assignments, and fix releases arriving days apart all overlap, do not push the update to next week. The work itself takes minutes from the admin panel.

Update history

Sources

• ▸ GitHub Security Advisory - Coordinated Vulnerability Disclosure, Trilby Media / Grav CMS (GHSA-xwv3-2mv2-w33x)
• ▸ GitHub Security Advisory - Privilege escalation via profile self-update (GHSA-h33v-82r9-v8pm / CVE-2026-65603)
• ▸ VulnCheck Advisory - Grav Multiple Remote Code Execution Vulnerabilities
• ▸ NVD - CVE-2026-65008 (Grav core, code injection, CVSS 9.8)
• ▸ NVD - CVE-2026-65007 (API plugin, missing authorization, CVSS 9.6)
• ▸ NVD - CVE-2026-65603 (login plugin, privilege escalation, CVSS 8.8)
• ▸ CVE.org - CVE-2026-57852 (scheduler webhook authentication bypass)
• ▸ getgrav.org - downloads.json (current shipped core release: 2.0.15, August 3, 2026)
• ▸ Grav CHANGELOG (GitHub, develop branch - 2.0.11 and 2.0.13 fixes, plus the unreleased v2.0.14 entry)
• ▸ GitHub Security Advisory - GHSA-7pgq-cr25-xvc8 (fixed in 2.0.11, bypass of the 2.0.7/2.0.9 guard)
• ▸ GitHub Security Advisory - GHSA-r94f-hx44-8jqf (fixed in 2.0.13, RCE via a dynamic field)
• ▸ GitHub Security Advisory - GHSA-mj78-8gwc-vxjj (fixed in login plugin 3.8.13, insufficient session expiration)
• ▸ Grav core security advisories (GitHub)
• ▸ Grav API plugin security advisories (GitHub - 12 published at once on July 26)
• ▸ NVD - CVE-2026-65608 (Grav core, RCE via a Flex dynamic field, CVSS 8.8)
• ▸ NVD - CVE-2026-65897 (API plugin, privilege escalation via invitations, CVSS 8.8)
• ▸ NVD - CVE-2026-65895 (API plugin, rate-limit and CORS settings writable, CVSS 8.5)
• ▸ NVD - CVE-2026-65896 (API plugin, path traversal in page move, CVSS 7.1)
• ▸ NVD - CVE-2026-64628 (shortcode-core plugin, stored XSS, CVSS 5.4)
• ▸ Grav official site (getgrav.org)
• ▸ Grav Security Overview (GitHub)