SilverStripe Vulnerability on 'isDev', 'isTest' and 'flush' $_GET validation

published 2024-05-23 2y ago modified 2024-11-28 last yr.

cvss: 6.5; version 3.1, GitHub
cisa kev: Not listed; not in CISA's catalog
epss: —; no score, EPSS covers CVEs only
public exploits: 0; none known

When a secure token parameter is provided to a SilverStripe site (such as isDev or flush) an empty token parameter can be provided in order to bypass normal authentication parameters.

For instance, http://www.mysite.com/?isDev=1&isDevtoken will force a site to dev mode. Alternatively, "flush" could also be used in succession to cause excessive load on a victim site and risk denial of service.

The fix in this case is to ensure that empty tokens fail the validation check.

Patch / fix

fixed in 1 links 2

packagist silverstripe/framework 3.0.14, 3.1.13

Is GHSA-g4hp-pfvf-vm5w in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

CVSS scores

assigned by	version	score	vector
GitHub	3.1	6.5	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L

Affected packages

ecosystem	package	affected	fixed in
packagist	silverstripe/framework	>=3.0.0, <3.0.14 >=3.1.0, <3.1.13	3.0.14 3.1.13

Classification

Weakness

CWE-639 Authorization Bypass Through User-Controlled Key

References

Sources

GitHub Advisory GHSA-g4hp-pfvf-vm5w

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.