CVE-2026-109326 is a high severity information disclosure (CVSS 7.5) in Grav. Bundled nginx, lighttpd, IIS and Caddy 2 configurations block .git only at the document root, so a nested repository such as user/.git can be fetched. The record says the fix is in Grav 2.1.7.
What's affected
Source conflict. The record says Grav before 2.1.7 is affected, with a score of 7.5 (High). The GitHub advisory GHSA-5vx9-x8f2-f55w, published on 23 September 2026, labels the severity Critical, lists the Composer package getgrav/grav with affected versions up to 2.1.2 and a patched version of 2.1.3, and, in its text, says supported releases through 2.1.6 and a maintenance release 1.7.53.2 include at least one affected configuration. The advisory also says to set patched versions after releases exist and shows no CVE identifier and no CWE.
The versions in the sources do not line up, so do not rely on a version number alone. The record's 2.1.7 is the safest target, because it is later than every version the advisory names as affected. Confirm in the Grav release notes.
The weakness in the record is CWE-527, exposure of a version control repository to an unauthorised control sphere. The vector is network reachable, no privileges, no interaction, high confidentiality impact only.
The advisory explains that nginx, lighttpd and IIS anchor their deny rule to the root, Caddy 2 rejects a dotted final segment but not files below a dotted directory, and Apache already matches dotted segments at any depth. It also warns that updating package examples may not replace a copied active server configuration.
How to check if you're exposed
The important check is your running web server rules, not the Grav version. Find any nested repository inside the web root:
find /var/www/your-site -name .git -maxdepth 6 -not -path "*/node_modules/*"
A site that keeps user/ under version control will show user/.git. Then test your own site from outside, against your own domain only, with a request for a file inside such a directory and see whether the server refuses it:
curl -sI https://your-site.example/user/.git/config
A 403 or 404 means blocked. A 200 means the repository is exposed.
Also read your active server configuration for the rule that denies dotted paths and see whether it applies to any depth or only to the root.
What to do now
- Update Grav to 2.1.7 or later, as the record says, and read the release notes for your line.
- Replace your active web server rules with the updated example for your server. The advisory says updating the package may not change a configuration you copied earlier.
- Add a rule that denies any path segment starting with a dot, at any depth, before static file handlers run.
- Remove .git directories from the web root where you do not need them, or move the repository outside the document root.
- Rotate any secret that was ever committed to a repository inside the web root, and treat unpublished content in the history as exposed.
Why it matters
Git stores a project's full history in a .git directory, including configuration, references and every committed object. If a web server will serve that directory, anyone can download the history and rebuild the repository, including old files, unpublished drafts and secrets that someone committed and later deleted.
The cause here is a deny rule that is too narrow. It protects the one location people thought of, the root, and misses repositories that live deeper, which is exactly where a CMS user folder often sits. The rule has to match a dotted directory at every depth.
The lesson reaches beyond Grav. Rules written for one path layout break when a project uses another. Test with the layout you really run. The record does not mark this CVE as known exploited, though this class of exposure is easy to check for from outside.
Quick check
Is updating Grav enough?
The advisory says updating package examples may not replace a server configuration you copied. Check and update your active rules too.
Why do the sources disagree on versions?
The record says before 2.1.7, while the advisory lists up to 2.1.2 with a patched 2.1.3 yet also mentions releases through 2.1.6. Use 2.1.7 or later and confirm in the release notes.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.
