We’ve identified a high impact vulnerability in a very recent patch to our
silverstripe/graphql module. Versions 4.1.1 and 4.2.2 are susceptible to a Distributed Denial of Service attack (DDOS attack). This could allow a malicious user to overload the server with bad requests, preventing legitimate users from accessing the site.
Read the CVE-2023-28104 - DDOS attack on graphql endpoints security advisory for all the technical details.
Fortunately, this bad patch has only been available for 2 days, so very few projects have applied it. If your site is running
silverstripe/graphql 4.1.1 or 4.2.2, we recommend you upgrade to version 4.1.2 or 4.2.3 as soon as possible.
If your site is NOT running
silverstripe/graphql 4.1.1 or 4.2.2, you do not need to take any action.
If your site does not expose a publicly facing graphql schema, an attacker would need to have access to a CMS account to trigger the attack. By default, Silverstripe CMS does not expose any public facing graphql schema.
If your site is hosted behind a content delivery network (CDN), such as Imperva or CloudFlare or RedShield, this will likely further mitigate the risk. Repeated requests to the same endpoint are likely to be flagged as malicious by your CDN and be blocked.
What was this patch trying to fix?
The patch was trying to address an intermittent schema corruption issue. We’ve completely rolled back the patch for now. So if you deployed the patch hoping to address schema corruption, that issue is likely to re-emerge.
We’ll aim to re-develop the patch in the near term.
Is this your regular security release process?
No it’s not. When proactively disclosing high impact security vulnerabilities, we usually aim to provide two weeks advance notice via our security pre-announcement list. We also normally line up those fixes with our regularly scheduled releases.
In this instance, we’ve determined that the number of Silverstripe CMS projects who had deployed the bad patch was very small since we fortunately caught our mistake reasonably quickly. In this context, we concluded it was preferable to roll back the bad patch as soon as possible before more sites upgraded to a vulnerable version of
Review our Security release process in the Silverstripe CMS documentation.
What steps will you take following this incident?
Our team is currently focused on minimising the impact of this vulnerability on our customers and on the Silverstripe CMS community.
Once the immediate risk has passed, we’ll review how we got into this situation as a team. We’ll share any lessons we learned with the Silverstripe CMS community to see how we can avoid this kind of incident in the future.
Post your comment
No one has commented on this page yet.
RSS feed for comments on this page | RSS feed for all comments