Drupal SQL注入漏洞（如CVE-2014-3704）需升级drupal/core至已修复版本，不可仅手动改代码；执行composer show drupal/core确认实际安装版本，并比对安全公告判断是否受影响。

Drupal 的 SQL 注入漏洞（如 CVE-2023-45819 或更早的 CVE-2022-3461）不能靠手动改代码“修复”，必须通过 Composer 升级到已打补丁的 drupal/core 版本，否则补丁无效、漏洞仍在。

确认当前版本是否受影响

执行 composer show drupal/core 查看实际安装版本。注意：不是 drupal/core-recommended 的声明版本，而是 drupal/core 在 vendor/ 中的实际解析版本。若输出类似 9.5.10 或 10.1.3，需对照 Drupal 安全公告确认是否在受影响范围内——例如 9.5.x

用 Composer 升级 drupal/core 到安全版本

升级不是简单运行 composer update，必须显式指定目标版本或使用推荐方式：

• 若项目基于 drupal/core-recommended：运行 composer update drupal/core-recommended --with-all-dependencies，它会连带更新 drupal/core 及其兼容依赖
• 若直接依赖 drupal/core：运行 composer require drupal/core:^9.5.17 --update-with-dependencies（按需替换为 10.x 安全版，如 ^10.1.7）
• 升级后务必检查 composer.lock 中 drupal/core 的 version 字段是否已变更，且 source.reference 指向含补丁的 commit

升级后必须清空缓存并验证

Composer 更新只改代码，不自动刷新 Drupal 运行时状态：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 执行 drush cr（或 php core/scripts/drupal.php cache:rebuild）强制重建所有缓存
• 访问后台 /admin/reports/status，确认“Drupal core”状态栏无警告，版本号与预期一致
• 重点测试曾使用 db_query() + 用户输入拼接 SQL 的自定义模块——这类地方最易触发未修复的注入路径

避免常见误操作

很多团队卡在这几步上：

• 仅修改 composer.json 中 drupal/core 版本但不运行 composer update，导致 vendor 未更新
• 运行 composer update drupal/core 而不加 --with-dependencies，引发 symfony/* 版本冲突，使 Drupal 启动失败
• 跳过 drush cr，仍用旧缓存中的预编译查询逻辑，漏洞表象消失但实际可被利用
• 在非生产环境验证后，直接 rsync vendor/ 到线上——Composer 安装应始终在目标环境执行，避免 autoloader 路径错乱

真正起作用的是 vendor/drupal/core/lib/Drupal/Core/Database/Driver/* 下驱动类中对 escapeLike()、escapeField() 等方法的补丁逻辑，它们只在升级后的代码中存在；任何绕过 Composer 的“热修复”都不可靠。