Top/Articles/Critical Grav CMS flaws (CVE-2026-65008 and more) risk site takeover — update now
grav-cve-cover-en

Critical Grav CMS flaws (CVE-2026-65008 and more) risk site takeover — update now

In July 2026, a batch of vulnerabilities that could let attackers take over a website was disclosed for Grav, the software used to build homepages and blogs. If exploited, an attacker could impersonate an administrator and deface the site. Older versions are affected; updating to the latest release prevents it. Here is how to check if your site is affected and what to do.

NewsPublished July 22, 2026 Updated today
Table of contents
Key takeaways

In July 2026, a batch of vulnerabilities that could let attackers take over a website was disclosed for Grav, the software used to build homepages and blogs. If exploited, an attacker could impersonate an administrator and deface the site. Older versions are affected; updating to the latest release prevents it. Here is how to check if your site is affected and what to do.

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 to the latest release. As of now, there are no reports of these being exploited in the wild.

This article explains, in plain terms, whether your site is affected, which version you need to move to, and what you should do right now.

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 vulnerabilities disclosed together in July 2026

This set of flaws was published in Grav's official security advisory and in VulnCheck's advisory. Since there are several, here is a table of "which part, which versions are affected, and how far you need to upgrade to fix it." Severity is out of 10: 9 and above is "critical," 7–8 is "high."

Vulnerability IDAffected partAffected versionsFixed inSeverityWhat happens
CVE-2026-65008Grav core
(form feature)
2.0.4–2.0.62.0.7 or laterCritical (9.8)Arbitrary program
execution on the server
CVE-2026-65007API pluginbefore 1.0.81.0.8 or laterCritical (9.6)Freely mint keys
to impersonate others
CVE-2026-65603Login plugin3.8.11 and earlier3.8.12 or laterHigh (8.8)Regular user escalates
to administrator
CVE-2026-57852Grav core /
scheduler-webhook plugin
core ≤2.0.8 /
plugin <1.1.2
core 2.0.9 /
plugin 1.1.3
ModerateScheduled jobs run
without authorization

The key takeaway from this table is that the affected versions are roughly up to one release behind the latest as of July 2026. Grav core is fixed in 2.0.7, with the remaining flaws addressed in 2.0.9. If you use plugins, you need to upgrade each of them individually.

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. Upgrading the API plugin to 1.0.8 or later resolves it. Sites that do not have the API plugin installed are not affected by this flaw.

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. Updating the login plugin to 3.8.12 or later fixes it. 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. It can be addressed by upgrading Grav core to 2.0.9 and the scheduler-webhook plugin to 1.1.3.

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.7, you are affected by CVE-2026-65008. If it is earlier than 2.0.9, the scheduler-related flaw also remains.

Next, check the plugins you have added. If you have the API plugin, confirm it is 1.0.8 or later; if you have the login plugin, confirm it is 3.8.12 or later. 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 separately from these particular IDs, you should consider migrating to the current line sooner rather than later.

What to do right now

The remediation is simple: it comes down to updating to the latest version. 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.

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 22, 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. This series of disclosures was made in the form of "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.

That said, now that the details of the flaws are public, some may start preparing attacks using them as clues. In particular, CVE-2026-65008 is top-tier in severity and has a nature that makes public-facing sites easy to target. Rather than scrambling once exploitation begins, quietly bringing your site up to the latest version while there are still no reports is the most reliable, lowest-effort defense. Stay calm, but do not put it off—update.

Sources

avatar-m-1

Makoto Horikawa

Backend Engineer / AWS / Django