On October 22nd I signed Grav up for Anthropic's OSS Scanner. It's an opt-in program: Anthropic builds an open source project in an isolated machine, points its models at the code, and emails the maintainers whatever it finds. Each finding comes with a write-up, a script that reproduces the problem, and usually a proposed patch. Grav core was accepted on October 30th.
The first report was big. 99 findings, with 1 rated critical and 35 rated high. Five more matched issues we already knew about, and eight were ordinary bugs with no security impact at all.
I opened it on Saturday morning. Grav 2.2.18 shipped that afternoon, along with Grav 1.7.53.7 and updates to six plugins. If you run Grav, please update now.
What we did to get in
Enrolling takes more than a form. You give the scanner a Dockerfile that builds your project into a running site, and (optionally, but you really should) a threat model that explains what you consider a security problem.
The threat model mattered most. Ours follows our SECURITY.md, which rates a report by the trust boundary it crosses. An anonymous visitor reading files off your server is critical. An admin who can already install plugins doing something an admin can do is not a vulnerability. Giving the scanner those rules up front meant the report was ranked the way we'd rank it ourselves, rather than treating every theoretical issue as an emergency.
Working through 99 findings
The report says it plainly: nobody had reviewed any of it before us. These are machine-generated leads with evidence attached. So the first job was to check every one.
I worked through it with AI agents doing the heavy lifting, and every call on what to fix and what to publish was mine. We ran all 112 reproducer scripts against two builds: the exact commit the scanner tested, and our current development branch. 106 of them reproduced on both. Only one had been fixed in the meantime.
Then we grouped the confirmed findings by root cause, because several findings were often the same bug reached through different doors. That's how 99 findings became 22 security advisories: 1 critical, 18 high and 3 moderate. Most of the rest were real but lower risk, and we fixed them as hardening without a separate advisory, which is what our security policy says to do. A handful weren't vulnerabilities by our policy at all.
The critical one was nasty. On 2.x and on 1.7, an anonymous visitor could read any file on the server, including account files and site secrets, through a public form. It took a specific trick with media metadata files, and the scanner found it.
It also caught a mistake of ours. An advisory we published back in August (GHSA-3jhr-mxmx-38cx) said the problem was fixed in Grav 2.0.16. It wasn't. No fix had ever landed. That one is now actually fixed in 2.2.18, and we've corrected the advisory to say so and raised its severity.
Testing before shipping
A security release that breaks sites isn't much of a fix. Before anything was tagged:
- The scanner's own reproducers were re-run against the fixed build, and every finding we fixed came back clean.
- The full core test suite passed, all 2,638 tests.
- We crawled more than 500 pages on two of our biggest test sites, once on the old code and once on the new code, and compared the output. Only one page changed, and it changed on purpose (see the Twig note below).
- Then we went through the admin and the front end in a browser: logging in, saving pages, accounts and settings, file uploads, forms that send email, two-factor setup, and what happens to a signed-in account the moment an admin disables it.
The releases
October 31st, the security release:
- Grav 2.2.18 and Grav 1.7.53.7
- API 1.1.6, Form 9.1.38, Email 5.3.4, Login 3.11.2, Flex Objects 1.4.18 and Migrate 1.0.20
Same evening, the follow-up:
- Grav 2.2.19 and Grav 1.7.53.8
- API 1.1.7 and Migrate 1.0.21
The follow-up is mostly about the sample web server configs we ship in webserver-configs/. Two of the findings were in the Caddy and IIS configs, and while fixing those we found more: the lighttpd.conf sample didn't even load on current lighttpd, and the 1.7 configs had never received the hardening 2.x got over the past year. Every config now blocks the same files and folders, and the 1.7 line is caught up.
The full list of advisories is on GitHub.
Things you might notice
Most of these fixes are invisible. A few aren't:
- Twig in page content is held to the sandbox's rules even inside the theme and plugin templates it includes. The Form plugin's templates still work from content as before. If a page includes some other partial and now shows its Twig as plain text, add the template to
security.twig_sandbox.trusted_partials, or move the include into your theme. - Sessions are tied to the site that created them, and the session cookie no longer goes to subdomains unless you set
system.session.domain. Anyone signed in when you update stays signed in. - Saving an account that someone else changed after you loaded it is refused, instead of quietly undoing their change. A disabled account can no longer re-enable itself from an old session.
- nginx, Caddy, lighttpd and IIS sites need to copy the updated rules from
webserver-configs/by hand. Upgrades only update Apache's.htaccess.
Updating
From the command line:
bin/gpm selfupgrade
bin/gpm update
Or use the update buttons in the admin. And as always, back up your site first.
Thanks
Thanks to Anthropic for running the OSS Scanner and opening it up to open source projects. A report like this would take a human auditor weeks, and it came with a working reproducer for every claim, which made checking it far faster. Thanks also to rng70, alham-rizvi and wyx200612, who reported related issues to us directly and are credited on their advisories.
Two lower-risk findings are still being worked on, and they'll ship with the next regular release.
If you have questions about any of this, come find us on Discord.
— Andy