Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The GraphQL controller lacked any CSRF protection, meaning authenticated users could be forced or tricked into visiting a URL that would send a GET request to the affected web server that could mutate or destroy data without the user knowing.
Recommended action: Upgrade to 2.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact canView permission checks are bypassed for ORM data in paginated GraphQL query results where the total number of records is greater than the number of records per page. Note that this also affects GraphQL queries which have a limit applied, even if the query isn’t paginated per se. This has been fixed by ensuring no new records are pulled in from the database after performing canView permission checks for each page of results. This may result in some pages in your query results having less than the maximum number of records per page even when there are more pages of results. This behaviour is consistent with how pagination works in other areas of Silverstripe CMS, such as in GridField, and is a result of having to perform permission checks in PHP rather than in the database directly. You can choose to disable these permission checks by disabling the CanViewPermission plugin following the instructions in overriding default plugins. Note that this vulnerability does not affect…
Recommended action: Upgrade to 5.1.3 or 4.3.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker could use a recursive graphql query to execute a Distributed Denial of Service attack (DDOS attack) against a website. This mostly affects websites with publicly exposed graphql schemas. If your Silverstripe CMS project does not expose a public facing graphql schema, a user account is required to trigger the DDOS attack. If your site is hosted behind a content delivery network (CDN), such as Imperva or CloudFlare, this may further mitigate the risk. The fix includes some new configuration options which you might want to tweak for your project, based on your own requirements. See the documentation in the references for details. Patches Patched in 3.8.2, 4.1.3, 4.2.5, 4.3.4, 5.0.3 References - CVE-2023-40180 on silverstripe.org - Documentation about protection against recursive or complex queries for silverstripe/graphql 4.x/5.x - Documentation about protection against recursive or complex queries for silverstripe/graphql 3.x Reported by Jason Nguyen from phew…
Recommended action: Upgrade to 5.0.3, 4.3.4, 4.2.5 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker could use a specially crafted graphql query to execute a Distributed Denial of Service attack (DDOS attack) against a website. This mostly affects websites with publicly exposed and particularly large/complex graphql schemas. If your Silverstripe CMS project does not expose a public facing graphql schema, a user account is required to trigger the DDOS attack. If your site is hosted behind a content delivery network (CDN), such as Imperva or CloudFlare, this will likely further mitigate the risk. Upgrade to silverstripe/graphql 4.2.3 or 4.1.2 or above to remedy the vulnerability.
Recommended action: Upgrade to 4.2.3 or 4.1.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SilverStripe 4.5.0 allows attackers to read certain records that should not have been placed into a result set. This affects silverstripe/recipe-cms. The automatic permission-checking mechanism in the silverstripe/graphql module does not provide complete protection against lists that are limited (e.g., through pagination), resulting in records that should have failed a permission check being added to the final result set. GraphQL endpoints are configured by default (e.g., for assets), but the admin/graphql endpoint is access protected by default. This limits the vulnerability to all authenticated users, including those with limited permissions (e.g., where viewing records exposed through admin/graphql requires administrator permissions). However, if custom GraphQL endpoints have been configured for a specific implementation (usually under /graphql), this vulnerability could also be exploited through unauthenticated requests. This vulnerability only applies to reading records; it does…
Recommended action: Upgrade to 3.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In SilverStripe/GraphQL prior to 2.0.5 and 3.1.2, the previous fix for SS-2018-007 does not completely mitigate the risk of CSRF in GraphQL mutations.
Recommended action: Upgrade to 3.1.2 or 2.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Default SilverStripe GraphQL Server (aka silverstripe/graphql) 3.x through 3.4.1 permission checker not inherited by query subclass.
Recommended action: Upgrade to 3.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GraphQL module accepts basic-auth as an authentication method by default. This can be used to bypass MFA authentication if the silverstripe/mfa module is installed, which is now a commonly installed module. A users password is still required though. Basic-auth has been removed as a default authentication method. If desired, it can be re-enabled by adding it to the authenticators key of a schema, or on SilverStripe\Graphql\Auth\Handler
Recommended action: Upgrade to 4.0.0-alpha2 (pre-release) or 3.5.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.