如果您的组织使用Drupal，那么您可能会遇到严重的问题。10月15日，Drupal敦促用户进行更新，修复SQL注入漏洞。但是，除非那个补丁在七小时内安装，Drupal现在说最好假设这个网站已经完全被破坏了。
SQL注入漏洞存在于Drupal使用的API中，该API旨在阻止SQL注入。这是被德国安全公司SektionEins重新发现去年9月，一名Drupal用户雇他们检查漏洞。
Drupal在核心7中使用API来处理预处理语句。因此，Drupal 7的所有版本。版本7.32之前的X分支是脆弱的。如果被利用，远程的、未经身份验证的攻击者可以注入SQL查询、提升特权或以其他方式完全控制Drupal安装。代码执行也是可能的。
当这一漏洞被广泛地公诸于众后，犯罪分子就开始了在Web上搜索易受攻击的安装．
使用自动化技术，许多网站都成为了攻击目标，Drupal表示，很容易假定没有在7小时时间内修补的安装遭到了破坏。更糟糕的是，在某些情况下，被攻击的网站实际上被攻击者打了补丁，以防止进一步的利用。
“在Drupal 7发布后的几个小时内，自动攻击开始攻击那些没有修补或更新到Drupal 7.32的Drupal 7网站……你应该假设每个Drupal 7网站都被攻击了，除非在UTC时间10月15日晚上11点之前进行更新或打补丁，[这是]Drupal的最新咨询解释说．
当这个问题在Drupal的补丁中被解决后，专家们注意到了这个事实此前披露．
“自2013年11月以来，这个漏洞在Drupal的公共bug跟踪数据库中独立存在，这一事实很有趣。他们似乎忽视了问题的严重性，需要一个独立的研究人员单独发现并敲打安全鼓，以引起人们的注意，”NCC集团欧洲董事总经理罗伯特·霍顿评论道。
Drupal基础架构QA工程师Ryan Aslett就安全团队(由来自世界各地的40名志愿者组成)为何错过了早期报告提出了一些见解。
Drupal的志愿安全团队在发现和防止安全漏洞方面做得很好，但他们并非无所不知。虽然bug报告中提到了这个bug，但你也必须明白，没有一个人或一组人的工作或角色是阅读Drupal核心的每一期。”Aslett评论．
“这个问题没有提交，因为嘿，这是一个安全漏洞，”它也没有提交给安全团队的问题队列(那里有* *人的角色是解决这类事情)。目前Drupal核心的问题队列中有超过14000个问题。我敢打赌，有人也通过报告报告了另一个潜在的安全漏洞，但没有人看到它。这是谁的工作?你的。我的。每个参与开源项目的人。只有当你有很多眼睛时，虫子才会变浅。”
同样，任何使用没有更新到7.32版本的Drupal安装(或没有在目标窗口内打补丁的安装)的人都应该假设最坏的情况，并开始恢复过程。
Drupal有提供了一些基本步骤，但不同组织的事件响应过程是不同的，所以无论如何，最好坚持内部政策。对于自行操作的管理员，请与您的Web主机联系并讨论选项，其中可能包括协助响应潜在事件。
与此同时，第一步是让Drupal网站离线。将index.php文件替换为通用的HTML页面，并开始转换到10月14日或更早的网站备份的过程。
不要试图在没有备份的情况下进行恢复，或者只是对一个固定的安装打补丁。针对这个漏洞的攻击已经被发现安装了后门，这可能位于Drupal的核心代码之外。
不幸的是，如果备份存储在与受损网站相同的服务器上，那么最好删除整个安装并从头重新构建。
无论哪种方式，都需要检查整个服务器，以检查恶意代码和恶意活动的迹象。这是因为只需安装一个易受攻击的Drupal，就可以破坏服务器和服务器上的其他网站，这就加剧了在转售主机账户或共享主机环境上托管Drupal的管理员的问题。
这篇文章，“咨询说假设所有drupal7网站都被入侵了”最初是由方案 ．