Summary
Insecure Deserialization in File Cache
- Severity: High
- CWE: CWE-502
- Location:
system/src/Grav/Framework/Cache/Adapter/FileCache.php - Sink:
unserialize($value, ['allowed_classes' => true])
Affected version(s)
- Affected:
>= 1.7.44and<= 1.7.49.5(verified in current codebase and changelog-covered releases). - Fixed: No upstream fix identified in the reviewed branch at the time of analysis.
- Notes: Earlier
1.7.xreleases may also be affected, but were not fully back-traced in this review.
Notes
allowed_classes => true allows object instantiation and does not constrain classes.
PoC (Primitive Demonstration)
Preconditions
- Local PHP runtime.
- Goal is to validate the deserialization primitive used in cache retrieval.
Steps
php -r '
class CacheWakeup { public function __wakeup(){ file_put_contents("/tmp/grav_filecache_poc.txt", "wakeup"); } }
$payload = serialize(new CacheWakeup());
unserialize($payload, ["allowed_classes" => true]);
echo file_exists("/tmp/grav_filecache_poc.txt") ? "FILECACHE_UNSERIALIZE_TRIGGERED\n" : "FILECACHE_UNSERIALIZE_NOT_TRIGGERED\n";
'
Expected Result
- Output contains:
FILECACHE_UNSERIALIZE_TRIGGERED.
Interpretation
This reproduces the same unsafe primitive used by FileCache::doGet():unserialize($value, ['allowed_classes' => true]).
If cache files are attacker-tampered, object magic methods may execute.
Exploit Preconditions
- Cache file poisoning/tampering capability.
Maintainer note, fix applied (2026-04-24)
Fixed in Grav core on the 2.0 branch: commit c66dfeb5f, will ship in 2.0.0-beta.2.
What changed: Framework\Cache\Adapter\FileCache now HMAC-signs every cache payload with Security::getNonceKey() on write, and verifies the HMAC on read. Tampered, forged, or pre-upgrade files are treated as cache misses and unlinked instead of being unserialized. The on-disk format is now versioned:
v2
<expires>
<key>
<hmac-hex>
<serialized>
Existing caches rebuild transparently on first read. Note that Framework\Cache\Adapter\FileCache isn't wired into Grav's main cache path, Symfony's FilesystemAdapter is, but the class is reachable by plugin and downstream consumers, so the hardening applies defensively.
Files:
system/src/Grav/Framework/Cache/Adapter/FileCache.php.tests/unit/Grav/Common/Security/FileCacheSecurityTest.php, round-trip, tampered-payload rejection, wrong-key forgery rejection, pre-v2 file rebuild, key-field mismatch.
Impact
The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths. Typical impact: varies by context: data corruption, logic bypass, or denial of service.
CVE-2026-7317 has a CVSS score of 5.0 (Low). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.0.0-beta.2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
- Avoid object deserialization in cache payloads.
- Use non-object formats and integrity protection for cache files.
Frequently Asked Questions
- What is CVE-2026-7317? CVE-2026-7317 is a low-severity improper input validation vulnerability in getgrav/grav (composer), affecting versions < 2.0.0-beta.2. It is fixed in 2.0.0-beta.2. The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths.
- How severe is CVE-2026-7317? CVE-2026-7317 has a CVSS score of 5.0 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of getgrav/grav are affected by CVE-2026-7317? getgrav/grav (composer) versions < 2.0.0-beta.2 is affected.
- Is there a fix for CVE-2026-7317? Yes. CVE-2026-7317 is fixed in 2.0.0-beta.2. Upgrade to this version or later.
- Is CVE-2026-7317 exploitable, and should I be worried? Whether CVE-2026-7317 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-7317 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-7317? Upgrade
getgrav/gravto 2.0.0-beta.2 or later.