Crawl4AI Docker API 安全通告解读RCE 与 LFI 漏洞根因、修复验证与防护加固【免费下载链接】crawl4ai Crawl4AI: Open-source LLM Friendly Web Crawler Scraper. Dont be shy, join here: https://discord.gg/jP8KfhDhyN项目地址: https://gitcode.com/GitHub_Trending/craw/crawl4ai本篇文章以 Crawl4AI 仓库中官方安全通告草稿 docs/security/GHSA-DRAFT-RCE-LFI.md 为核心骨架深度剖析 Crawl4AI Docker API 部署模式中于 v0.8.0 修复的两个高危漏洞/crawl端点hooks参数导致的远程代码执行RCECVSS 10.0以及/execute_js、/screenshot、/pdf、/html端点接受file://URL 导致的本地文件包含LFICVSS 8.6。文章将逐一还原攻击载荷与影响面并对照当前仓库中的加固实现deploy/docker/server.py、hook_registry.py、egress_broker.py及安全回归测试验证修复是否落地最后给出面向自托管部署的防护清单。读者读完可完整掌握这两条漏洞的来龙去脉、如何验证修复以及升级与加固的实操方法。通告背景与适用范围该安全通告草稿记录了 Crawl4AIDocker API 部署形态即 deploy/docker/ 目录下的 FastAPI 服务在 v0.8.0 之前存在的两条漏洞。两条漏洞均由安全研究机构 ProjectDiscovery 的Neo发现并上报。通告中给出了标准的披露要素要素漏洞一Hooks 参数 RCE漏洞二file:// URL LFI严重等级Critical严重High高危CVSS 3.110.0AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H8.6AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:NCWECWE-94代码生成控制不当CWE-22受限目录路径名限制不当受影响版本 0.8.0 0.8.0修复版本0.8.00.8.0攻击前提无需认证无需认证说明通告草稿原文中 References 指向外部 GitHub 页面。在本文中请以仓库内文档为准v0.8.0 发布说明 与 v0.8.0 升级指南。仓库当前版本已迭代至 v0.9.0见 crawl4ai/version.py修复代码均已在当前代码库中生效。从攻击视角看两条漏洞的共同点是Docker API 面向网络公开、默认无认证而服务端把「用户提供的输入」当成了「可信代码/可信 URL」来执行。这是所有将爬虫能力封装成 HTTP 服务时都必须正视的信任边界问题。漏洞一通过 Hooks 参数实现远程代码执行RCE漏洞成因与攻击向量Crawl4AI SDK 的AsyncWebCrawler支持通过crawler_strategy.set_hook(...)在页面生命周期关键节点如on_page_context_created、before_goto等挂载 Python 回调用于注入认证 Cookie、拦截资源、滚动页面等场景仓库示例见 docs/examples/hooks_example.py。漏洞版本中Docker API 的/crawl端点接收一个hooks参数并直接对其中携带的Python 源代码调用exec()执行更致命的是该受限执行环境allowed_builtins中保留了__import__内建函数——攻击者因此可以突破“受限命名空间”导入任意模块并执行系统命令。通告给出的最小攻击载荷如下POST /crawl { urls: [https://example.com], hooks: { code: { on_page_context_created: async def hook(page, context, **kwargs):\n __import__(os).system(malicious_command)\n return page } } }请求体中没有任何需要认证的字段__import__(os)拿到os模块后直接调用.system(...)即可在服务端进程内执行任意 shell 命令。影响面通告明确指出未认证攻击者利用该漏洞可以执行任意系统命令读写服务器上的任意文件窃取敏感数据环境变量、API Key 等以服务进程身份向内网横向移动完全控制服务器。由于 Docker API 容器常被授予一定特权、且进程内往往持有 Redis、LLM Provider 凭据等敏感信息RCE 的实际破坏力等同于服务器沦陷。当前代码中的修复验证通告记载的修复分三步① 从allowed_builtins中移除__import__② 默认关闭 hooksCRAWL4AI_HOOKS_ENABLEDfalse③ 用户需显式开启才能使用 hooks。对照当前仓库源码可以确认修复不仅落地而且进一步深化1. Hooks 默认关闭未开启时直接拒绝。在 deploy/docker/server.py 顶部HOOKS_ENABLED os.environ.get(CRAWL4AI_HOOKS_ENABLED, false).lower() true而/crawl、/crawl/stream两个入口在接收含hooks的请求时会先做开关检查未开启直接返回 403if crawl_request.hooks and not HOOKS_ENABLED: raise HTTPException(403, Hooks are disabled. Set CRAWL4AI_HOOKS_ENABLEDtrue to enable.)相关逻辑位于 deploy/docker/server.py 的crawl/crawl_stream处理器中。2. 不再接受任意 Python 代码改为「声明式动作注册表」。当前仓库中通告提到的hook_manager.py已不再存在取而代之的是 deploy/docker/hook_registry.py。其模块 docstring 明确写道旧的hook_manager.py通过exec()执行用户 Python其沙箱“unsound”可通过__subclasses__的 MRO 遍历、注入的模块__globals__、栈帧检查等手段逃逸在进程内不存在安全运行攻击者 Python 的可行方案。因此新设计改为请求只能从固定的一组声明式 ACTION中选择参数用 Pydantic 模型做 schema 校验每个 ACTION 由服务端编写、只调用某一个特定的 Playwright API用户字符串永远不会到达解释器动作名绑定 hook 点允许参数含边界block_resourceson_page_context_createdresource_types仅允许 image/stylesheet/font/mediaadd_cookieson_page_context_created至多 20 个 Cookie字段长度受限set_headersbefore_goto至多 20 个 header名称正则校验、拒绝换行控制字符scroll_to_bottombefore_retrieve_htmlmax_steps≤ 50delay_ms≤ 5000wait_for_timeoutbefore_retrieve_htmltimeout_ms≤ 60000build_declarative_hooks()deploy/docker/hook_registry.py会拒绝未知动作HookValidationError→ HTTP 400并限制单个请求最多 10 条 hook 规格。例如“拦截图片资源”这一原本需要用自定义 Python 实现的诉求现在写成POST /crawl { urls: [https://example.com], hooks: { hooks: [ { action: block_resources, params: { resource_types: [image, media] } }, { action: scroll_to_bottom, params: { max_steps: 5, delay_ms: 300 } } ] } }动作与参数说明可通过GET /hooks/info见 deploy/docker/server.py 的get_hooks_info随时查询。真正需要任意 hook 代码的高级用户通告与代码注释给出的建议是改用自托管进程内 SDK 构建Python 侧crawler_strategy.set_hook(...)仍保留给受信任代码使用而不是把不受信代码暴露给 Docker API。配置侧与文档侧的一致性默认安全配置在 deploy/docker/config.yml 的安全区注释中明确提示Set CRAWL4AI_HOOKS_ENABLEDtrue only if you need hooks (RCE risk)升级指南 docs/migration/v0.8.0-upgrade-guide.md 提供了 docker-compose/环境变量开启 hooks 的完整迁移步骤安全运维基线见仓库根目录 SECURITY.mdhooks 默认关闭仅在确有必要时显式开启。特别提醒若你确实需要 hooks 功能请务必评估“调用该 API 的请求方是否全部可信”。因为一旦CRAWL4AI_HOOKS_ENABLEDtrue任何能打到该端点的请求都获得了声明式 hook 的执行能力此时必须叠加认证见下文加固清单。漏洞二通过 file:// URL 实现本地文件包含LFI漏洞成因与攻击向量Crawl4AI SDK 本身支持以file://读取本地 HTML 文件升级指南也明确建议本地文件处理走 Python 库。但漏洞版本的 Docker API 中/execute_js、/screenshot、/pdf、/html端点把用户提交的 URL直接交给浏览器内核去访问而没有做 URL scheme 白名单校验。这意味着攻击者可以让服务端浏览器代为读取宿主机文件系统上的任意文件。通告给出的最小攻击载荷POST /execute_js { url: file:///etc/passwd, scripts: [document.body.innerText] }通过file:///etc/passwd让浏览器加载本地文件再借/execute_js的脚本取回document.body.innerText一份系统账户文件就通过 API 响应被带了出来。影响面读取/etc/passwd、/etc/shadow、应用配置文件等敏感文件通过/proc/self/environ读取进程环境变量常含各类密钥摸清内部应用结构为进一步攻击做信息收集可能直接读取到凭据与 API Key。由于爬虫容器往往与 Redis、LLM Provider 等共用编排网络LFI 叠加环境变量泄露的破坏同样不容小觑。当前代码中的修复验证通告记载的修复为增加 URL scheme 校验阻止file://、javascript:、data:及其他非 HTTP scheme仅允许http://、https://与raw:。对照 deploy/docker/server.py 的实现校验函数与白名单如下ALLOWED_URL_SCHEMES (http://, https://) ALLOWED_URL_SCHEMES_WITH_RAW (http://, https://, raw:, raw://) def validate_url_scheme(url: str, allow_raw: bool False) - None: Validate URL scheme (LFI) and destination (SSRF). allowed ALLOWED_URL_SCHEMES_WITH_RAW if allow_raw else ALLOWED_URL_SCHEMES if not url.startswith(allowed): schemes , .join(allowed) raise HTTPException(400, fURL must start with {schemes}) validate_url_destination(url)其中/screenshot、/pdf、/execute_js默认调用validate_url_scheme(body.url)不允许 raw/html因业务需要支持内联 HTML调用validate_url_scheme(body.url, allow_rawTrue)即额外放行raw:/raw://该 scheme 指向内联 HTML 内容不触发任何网络或本地文件读取。screenshot/pdf/html/execute_js端点均位于 deploy/docker/server.py 的app.post(...)路由中。file://、javascript:、data:、ftp://、空 URL 与相对路径/etc/passwd、../../../etc/passwd都会在校验第一步被 400 拒绝。进一步加固除 scheme 校验外validate_url_scheme内部还会继续调用validate_url_destination()把 SSRF 保护串进链路见下文“纵深防御”。同时/execute_js端点在当前版本中默认整体禁用需设置CRAWL4AI_EXECUTE_JS_ENABLEDtrue才会开放见 deploy/docker/server.py 中execute_js处理器与 deploy/docker/tests/test_security_2026_04_b2.py 的断言从端点级进一步收窄攻击面。修复后的正确用法通告与 v0.8.0 发布说明 给出的迁移建议高度一致需要处理本地 HTML 的场景请使用 Python 库而非 Docker APIfrom crawl4ai import AsyncWebCrawler async with AsyncWebCrawler() as crawler: result await crawler.arun(urlfile:///path/to/file.html)Docker API 侧只面向http(s)网页或通过raw:直接传入 HTML 字符串二者职责边界清晰。安全回归测试修复如何被机器验证仓库在 deploy/docker/tests/ 目录下沉淀了大量针对这两条漏洞的安全回归用例是验证“修复是否真的生效、未来是否回退”的第一手证据deploy/docker/tests/test_security_fixes.py逐一断言file:///etc/passwd、file:///C:/Windows/...、javascript:、data:、ftp://、空串与相对路径均被拒绝http://、https://、localhost放行raw:仅在allow_rawTrue时放行——与通告“仅允许 http/https/raw”的修复描述完全对应。该文件还测试了CRAWL4AI_HOOKS_ENABLED环境变量默认关闭、显式true/false时开合行为正确。deploy/docker/tests/test_security_2026_04_b2.py校验/execute_js默认禁用、必须检查EXECUTE_JS_ENABLED开关且带 SSRF 检查。deploy/docker/tests/test_security_default_posture.py把/screenshot、/execute_js等端点的“默认关闭/默认拒绝”姿态固化为测试契约。deploy/docker/tests/test_security_ssrf_crawl.py断言 scheme 校验必须串联validate_url_destination做目标校验防止只查 scheme 不防 SSRF 的遗漏。deploy/docker/tests/test_security_authz.py校验请求必须携带 Bearer Token认证层。deploy/docker/tests/run_security_tests.py提供对运行中容器的端到端探测脚本其中明确包含“A2: file:// blocked on /execute_js (400)”“A3: file:// blocked on /screenshot (400)”等检查项。上述测试与 deploy/docker/SECURITY-VERIFY.md 可组合成一套完整的 Docker API 安全验收流程建议自托管用户将其纳入 CI 或发布前的安全门禁。纵深防御与修复配套的周边加固两条漏洞的修复并非孤立补丁而是被纳入了 Docker API 的整体信任边界体系。结合源码可以梳理出与本次通告直接相关的几层纵深防御1. SSRF 防护URL 目标校验。deploy/docker/utils.py 中的validate_url_destination负责拦截指向内网/私有网络的 URL并在 deploy/docker/egress_broker.py 中做“解析并固定目标 IPpin 强制出网”的双保险既拒绝非全局 IP含 IPv4-mapped IPv6、NAT64 等变体绕过又防止后台抓取被重绑定/重定向到内网。ALLOW_INTERNAL_URLS默认关闭。2. 不可信配置的溯源闸门。/crawl等端点对browser_config/crawler_config使用Provenance.UNTRUSTED加载见 deploy/docker/api.py 与 crawl4ai/async_configs.py凡请求体尝试设置危险能力字段都会抛UntrustedConfigError并被映射为 HTTP 400从源头杜绝“配置文件投毒”。3. 端点级能力裁剪。hooks 需CRAWL4AI_HOOKS_ENABLEDtrue、/execute_js需CRAWL4AI_EXECUTE_JS_ENABLEDtrue均默认关闭配置文件内还包含任务墙钟超时、内存阈值、每调用者配额等运行时约束见 deploy/docker/config.yml。4. 错误信息不泄露内部细节。deploy/docker/server.py 的全局异常处理器对 5xx 一律返回通用错误 correlation_id完整细节仅记录在服务端日志避免把内部路径、依赖版本、解析到的内网 IP 或密钥回显给客户端。5. 认证层。security.api_token与/token签发 JWT 的机制deploy/docker/server.pyget_token可在配置文件中显式开启jwt_enabled。加固与升级操作清单结合通告的 Mitigation 与仓库现状自托管 Docker API 的落地顺序建议如下立即升级到已修复版本通告标注 0.8.0仓库当前为 0.9.0不要停留在 0.8.0 的旧镜像上保持 hooks 与/execute_js默认关闭不要设置CRAWL4AI_HOOKS_ENABLEDtrue/CRAWL4AI_EXECUTE_JS_ENABLEDtrue除非所有 API 调用方完全可信如确需开启 hooks改用文章第一节展示的声明式 ACTION而非任何形式的原始代码字段启用认证在 deploy/docker/config.yml 中设置随机强api_token并开启jwt_enabled未配置api_token时/token会“fail closed”拒绝发号网络层收敛若短时间内无法升级可先行关闭/阻断/crawl、/execute_js等高风险端点并加装认证与网络级过滤通告给出的临时缓解措施本地 HTML 处理一律走 Python SDK不要通过 API 传file://跑一遍安全回归参照 deploy/docker/tests/test_security_fixes.py 与 deploy/docker/tests/run_security_tests.py确认 scheme 校验、hooks 开关与默认拒绝姿态均符合预期。关于通告本身的组织与发布原文档末尾给出了将草稿发布为正式安全通告的操作流程填表字段EcosystemPyPI、包名crawl4ai、Affected 0.8.0、Patched 0.8.0、Severity 分别取 Critical/High。其核心要点可归纳为发布后系统会分配 GHSA ID、可选申请 CVE、并向开启安全告警的订阅用户推送通知因此协调披露节奏与修复版本发版时间至关重要。这一点与仓库中 CHANGELOG.md、docs/blog/release-v0.8.0.md 记录的安全修复条目相互印证。小结Crawl4AI v0.8.0 修复的这两条漏洞本质上是**“把不可信输入交给代码解释器”与“把不可信 URL 交给浏览器”**两个经典信任边界错误的 Docker API 版本。对照仓库源码可以确认修复不仅如通告所述移除了__import__、默认关闭 hooks、白名单化 URL scheme更演进为「声明式 hook 注册表 参数 schema 校验 scheme/SSRF 双重校验 端点级默认关闭 统一错误处理」的多层防御体系。对于所有自托管用户最稳妥的策略是升级到已修复版本、保持高风险能力默认关闭、始终开启认证并让 deploy/docker/tests/ 下的安全回归测试成为发布流程的固定一环。相关升级细节还可继续参考 docs/migration/v0.8.0-upgrade-guide.md 与 v0.8.0 发布说明。【免费下载链接】crawl4ai Crawl4AI: Open-source LLM Friendly Web Crawler Scraper. Dont be shy, join here: https://discord.gg/jP8KfhDhyN项目地址: https://gitcode.com/GitHub_Trending/craw/crawl4ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Crawl4AI Docker API 安全通告解读：RCE 与 LFI 漏洞根因、修复验证与防护加固
Crawl4AI Docker API 安全通告解读RCE 与 LFI 漏洞根因、修复验证与防护加固【免费下载链接】crawl4ai Crawl4AI: Open-source LLM Friendly Web Crawler Scraper. Dont be shy, join here: https://discord.gg/jP8KfhDhyN项目地址: https://gitcode.com/GitHub_Trending/craw/crawl4ai本篇文章以 Crawl4AI 仓库中官方安全通告草稿 docs/security/GHSA-DRAFT-RCE-LFI.md 为核心骨架深度剖析 Crawl4AI Docker API 部署模式中于 v0.8.0 修复的两个高危漏洞/crawl端点hooks参数导致的远程代码执行RCECVSS 10.0以及/execute_js、/screenshot、/pdf、/html端点接受file://URL 导致的本地文件包含LFICVSS 8.6。文章将逐一还原攻击载荷与影响面并对照当前仓库中的加固实现deploy/docker/server.py、hook_registry.py、egress_broker.py及安全回归测试验证修复是否落地最后给出面向自托管部署的防护清单。读者读完可完整掌握这两条漏洞的来龙去脉、如何验证修复以及升级与加固的实操方法。通告背景与适用范围该安全通告草稿记录了 Crawl4AIDocker API 部署形态即 deploy/docker/ 目录下的 FastAPI 服务在 v0.8.0 之前存在的两条漏洞。两条漏洞均由安全研究机构 ProjectDiscovery 的Neo发现并上报。通告中给出了标准的披露要素要素漏洞一Hooks 参数 RCE漏洞二file:// URL LFI严重等级Critical严重High高危CVSS 3.110.0AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H8.6AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:NCWECWE-94代码生成控制不当CWE-22受限目录路径名限制不当受影响版本 0.8.0 0.8.0修复版本0.8.00.8.0攻击前提无需认证无需认证说明通告草稿原文中 References 指向外部 GitHub 页面。在本文中请以仓库内文档为准v0.8.0 发布说明 与 v0.8.0 升级指南。仓库当前版本已迭代至 v0.9.0见 crawl4ai/version.py修复代码均已在当前代码库中生效。从攻击视角看两条漏洞的共同点是Docker API 面向网络公开、默认无认证而服务端把「用户提供的输入」当成了「可信代码/可信 URL」来执行。这是所有将爬虫能力封装成 HTTP 服务时都必须正视的信任边界问题。漏洞一通过 Hooks 参数实现远程代码执行RCE漏洞成因与攻击向量Crawl4AI SDK 的AsyncWebCrawler支持通过crawler_strategy.set_hook(...)在页面生命周期关键节点如on_page_context_created、before_goto等挂载 Python 回调用于注入认证 Cookie、拦截资源、滚动页面等场景仓库示例见 docs/examples/hooks_example.py。漏洞版本中Docker API 的/crawl端点接收一个hooks参数并直接对其中携带的Python 源代码调用exec()执行更致命的是该受限执行环境allowed_builtins中保留了__import__内建函数——攻击者因此可以突破“受限命名空间”导入任意模块并执行系统命令。通告给出的最小攻击载荷如下POST /crawl { urls: [https://example.com], hooks: { code: { on_page_context_created: async def hook(page, context, **kwargs):\n __import__(os).system(malicious_command)\n return page } } }请求体中没有任何需要认证的字段__import__(os)拿到os模块后直接调用.system(...)即可在服务端进程内执行任意 shell 命令。影响面通告明确指出未认证攻击者利用该漏洞可以执行任意系统命令读写服务器上的任意文件窃取敏感数据环境变量、API Key 等以服务进程身份向内网横向移动完全控制服务器。由于 Docker API 容器常被授予一定特权、且进程内往往持有 Redis、LLM Provider 凭据等敏感信息RCE 的实际破坏力等同于服务器沦陷。当前代码中的修复验证通告记载的修复分三步① 从allowed_builtins中移除__import__② 默认关闭 hooksCRAWL4AI_HOOKS_ENABLEDfalse③ 用户需显式开启才能使用 hooks。对照当前仓库源码可以确认修复不仅落地而且进一步深化1. Hooks 默认关闭未开启时直接拒绝。在 deploy/docker/server.py 顶部HOOKS_ENABLED os.environ.get(CRAWL4AI_HOOKS_ENABLED, false).lower() true而/crawl、/crawl/stream两个入口在接收含hooks的请求时会先做开关检查未开启直接返回 403if crawl_request.hooks and not HOOKS_ENABLED: raise HTTPException(403, Hooks are disabled. Set CRAWL4AI_HOOKS_ENABLEDtrue to enable.)相关逻辑位于 deploy/docker/server.py 的crawl/crawl_stream处理器中。2. 不再接受任意 Python 代码改为「声明式动作注册表」。当前仓库中通告提到的hook_manager.py已不再存在取而代之的是 deploy/docker/hook_registry.py。其模块 docstring 明确写道旧的hook_manager.py通过exec()执行用户 Python其沙箱“unsound”可通过__subclasses__的 MRO 遍历、注入的模块__globals__、栈帧检查等手段逃逸在进程内不存在安全运行攻击者 Python 的可行方案。因此新设计改为请求只能从固定的一组声明式 ACTION中选择参数用 Pydantic 模型做 schema 校验每个 ACTION 由服务端编写、只调用某一个特定的 Playwright API用户字符串永远不会到达解释器动作名绑定 hook 点允许参数含边界block_resourceson_page_context_createdresource_types仅允许 image/stylesheet/font/mediaadd_cookieson_page_context_created至多 20 个 Cookie字段长度受限set_headersbefore_goto至多 20 个 header名称正则校验、拒绝换行控制字符scroll_to_bottombefore_retrieve_htmlmax_steps≤ 50delay_ms≤ 5000wait_for_timeoutbefore_retrieve_htmltimeout_ms≤ 60000build_declarative_hooks()deploy/docker/hook_registry.py会拒绝未知动作HookValidationError→ HTTP 400并限制单个请求最多 10 条 hook 规格。例如“拦截图片资源”这一原本需要用自定义 Python 实现的诉求现在写成POST /crawl { urls: [https://example.com], hooks: { hooks: [ { action: block_resources, params: { resource_types: [image, media] } }, { action: scroll_to_bottom, params: { max_steps: 5, delay_ms: 300 } } ] } }动作与参数说明可通过GET /hooks/info见 deploy/docker/server.py 的get_hooks_info随时查询。真正需要任意 hook 代码的高级用户通告与代码注释给出的建议是改用自托管进程内 SDK 构建Python 侧crawler_strategy.set_hook(...)仍保留给受信任代码使用而不是把不受信代码暴露给 Docker API。配置侧与文档侧的一致性默认安全配置在 deploy/docker/config.yml 的安全区注释中明确提示Set CRAWL4AI_HOOKS_ENABLEDtrue only if you need hooks (RCE risk)升级指南 docs/migration/v0.8.0-upgrade-guide.md 提供了 docker-compose/环境变量开启 hooks 的完整迁移步骤安全运维基线见仓库根目录 SECURITY.mdhooks 默认关闭仅在确有必要时显式开启。特别提醒若你确实需要 hooks 功能请务必评估“调用该 API 的请求方是否全部可信”。因为一旦CRAWL4AI_HOOKS_ENABLEDtrue任何能打到该端点的请求都获得了声明式 hook 的执行能力此时必须叠加认证见下文加固清单。漏洞二通过 file:// URL 实现本地文件包含LFI漏洞成因与攻击向量Crawl4AI SDK 本身支持以file://读取本地 HTML 文件升级指南也明确建议本地文件处理走 Python 库。但漏洞版本的 Docker API 中/execute_js、/screenshot、/pdf、/html端点把用户提交的 URL直接交给浏览器内核去访问而没有做 URL scheme 白名单校验。这意味着攻击者可以让服务端浏览器代为读取宿主机文件系统上的任意文件。通告给出的最小攻击载荷POST /execute_js { url: file:///etc/passwd, scripts: [document.body.innerText] }通过file:///etc/passwd让浏览器加载本地文件再借/execute_js的脚本取回document.body.innerText一份系统账户文件就通过 API 响应被带了出来。影响面读取/etc/passwd、/etc/shadow、应用配置文件等敏感文件通过/proc/self/environ读取进程环境变量常含各类密钥摸清内部应用结构为进一步攻击做信息收集可能直接读取到凭据与 API Key。由于爬虫容器往往与 Redis、LLM Provider 等共用编排网络LFI 叠加环境变量泄露的破坏同样不容小觑。当前代码中的修复验证通告记载的修复为增加 URL scheme 校验阻止file://、javascript:、data:及其他非 HTTP scheme仅允许http://、https://与raw:。对照 deploy/docker/server.py 的实现校验函数与白名单如下ALLOWED_URL_SCHEMES (http://, https://) ALLOWED_URL_SCHEMES_WITH_RAW (http://, https://, raw:, raw://) def validate_url_scheme(url: str, allow_raw: bool False) - None: Validate URL scheme (LFI) and destination (SSRF). allowed ALLOWED_URL_SCHEMES_WITH_RAW if allow_raw else ALLOWED_URL_SCHEMES if not url.startswith(allowed): schemes , .join(allowed) raise HTTPException(400, fURL must start with {schemes}) validate_url_destination(url)其中/screenshot、/pdf、/execute_js默认调用validate_url_scheme(body.url)不允许 raw/html因业务需要支持内联 HTML调用validate_url_scheme(body.url, allow_rawTrue)即额外放行raw:/raw://该 scheme 指向内联 HTML 内容不触发任何网络或本地文件读取。screenshot/pdf/html/execute_js端点均位于 deploy/docker/server.py 的app.post(...)路由中。file://、javascript:、data:、ftp://、空 URL 与相对路径/etc/passwd、../../../etc/passwd都会在校验第一步被 400 拒绝。进一步加固除 scheme 校验外validate_url_scheme内部还会继续调用validate_url_destination()把 SSRF 保护串进链路见下文“纵深防御”。同时/execute_js端点在当前版本中默认整体禁用需设置CRAWL4AI_EXECUTE_JS_ENABLEDtrue才会开放见 deploy/docker/server.py 中execute_js处理器与 deploy/docker/tests/test_security_2026_04_b2.py 的断言从端点级进一步收窄攻击面。修复后的正确用法通告与 v0.8.0 发布说明 给出的迁移建议高度一致需要处理本地 HTML 的场景请使用 Python 库而非 Docker APIfrom crawl4ai import AsyncWebCrawler async with AsyncWebCrawler() as crawler: result await crawler.arun(urlfile:///path/to/file.html)Docker API 侧只面向http(s)网页或通过raw:直接传入 HTML 字符串二者职责边界清晰。安全回归测试修复如何被机器验证仓库在 deploy/docker/tests/ 目录下沉淀了大量针对这两条漏洞的安全回归用例是验证“修复是否真的生效、未来是否回退”的第一手证据deploy/docker/tests/test_security_fixes.py逐一断言file:///etc/passwd、file:///C:/Windows/...、javascript:、data:、ftp://、空串与相对路径均被拒绝http://、https://、localhost放行raw:仅在allow_rawTrue时放行——与通告“仅允许 http/https/raw”的修复描述完全对应。该文件还测试了CRAWL4AI_HOOKS_ENABLED环境变量默认关闭、显式true/false时开合行为正确。deploy/docker/tests/test_security_2026_04_b2.py校验/execute_js默认禁用、必须检查EXECUTE_JS_ENABLED开关且带 SSRF 检查。deploy/docker/tests/test_security_default_posture.py把/screenshot、/execute_js等端点的“默认关闭/默认拒绝”姿态固化为测试契约。deploy/docker/tests/test_security_ssrf_crawl.py断言 scheme 校验必须串联validate_url_destination做目标校验防止只查 scheme 不防 SSRF 的遗漏。deploy/docker/tests/test_security_authz.py校验请求必须携带 Bearer Token认证层。deploy/docker/tests/run_security_tests.py提供对运行中容器的端到端探测脚本其中明确包含“A2: file:// blocked on /execute_js (400)”“A3: file:// blocked on /screenshot (400)”等检查项。上述测试与 deploy/docker/SECURITY-VERIFY.md 可组合成一套完整的 Docker API 安全验收流程建议自托管用户将其纳入 CI 或发布前的安全门禁。纵深防御与修复配套的周边加固两条漏洞的修复并非孤立补丁而是被纳入了 Docker API 的整体信任边界体系。结合源码可以梳理出与本次通告直接相关的几层纵深防御1. SSRF 防护URL 目标校验。deploy/docker/utils.py 中的validate_url_destination负责拦截指向内网/私有网络的 URL并在 deploy/docker/egress_broker.py 中做“解析并固定目标 IPpin 强制出网”的双保险既拒绝非全局 IP含 IPv4-mapped IPv6、NAT64 等变体绕过又防止后台抓取被重绑定/重定向到内网。ALLOW_INTERNAL_URLS默认关闭。2. 不可信配置的溯源闸门。/crawl等端点对browser_config/crawler_config使用Provenance.UNTRUSTED加载见 deploy/docker/api.py 与 crawl4ai/async_configs.py凡请求体尝试设置危险能力字段都会抛UntrustedConfigError并被映射为 HTTP 400从源头杜绝“配置文件投毒”。3. 端点级能力裁剪。hooks 需CRAWL4AI_HOOKS_ENABLEDtrue、/execute_js需CRAWL4AI_EXECUTE_JS_ENABLEDtrue均默认关闭配置文件内还包含任务墙钟超时、内存阈值、每调用者配额等运行时约束见 deploy/docker/config.yml。4. 错误信息不泄露内部细节。deploy/docker/server.py 的全局异常处理器对 5xx 一律返回通用错误 correlation_id完整细节仅记录在服务端日志避免把内部路径、依赖版本、解析到的内网 IP 或密钥回显给客户端。5. 认证层。security.api_token与/token签发 JWT 的机制deploy/docker/server.pyget_token可在配置文件中显式开启jwt_enabled。加固与升级操作清单结合通告的 Mitigation 与仓库现状自托管 Docker API 的落地顺序建议如下立即升级到已修复版本通告标注 0.8.0仓库当前为 0.9.0不要停留在 0.8.0 的旧镜像上保持 hooks 与/execute_js默认关闭不要设置CRAWL4AI_HOOKS_ENABLEDtrue/CRAWL4AI_EXECUTE_JS_ENABLEDtrue除非所有 API 调用方完全可信如确需开启 hooks改用文章第一节展示的声明式 ACTION而非任何形式的原始代码字段启用认证在 deploy/docker/config.yml 中设置随机强api_token并开启jwt_enabled未配置api_token时/token会“fail closed”拒绝发号网络层收敛若短时间内无法升级可先行关闭/阻断/crawl、/execute_js等高风险端点并加装认证与网络级过滤通告给出的临时缓解措施本地 HTML 处理一律走 Python SDK不要通过 API 传file://跑一遍安全回归参照 deploy/docker/tests/test_security_fixes.py 与 deploy/docker/tests/run_security_tests.py确认 scheme 校验、hooks 开关与默认拒绝姿态均符合预期。关于通告本身的组织与发布原文档末尾给出了将草稿发布为正式安全通告的操作流程填表字段EcosystemPyPI、包名crawl4ai、Affected 0.8.0、Patched 0.8.0、Severity 分别取 Critical/High。其核心要点可归纳为发布后系统会分配 GHSA ID、可选申请 CVE、并向开启安全告警的订阅用户推送通知因此协调披露节奏与修复版本发版时间至关重要。这一点与仓库中 CHANGELOG.md、docs/blog/release-v0.8.0.md 记录的安全修复条目相互印证。小结Crawl4AI v0.8.0 修复的这两条漏洞本质上是**“把不可信输入交给代码解释器”与“把不可信 URL 交给浏览器”**两个经典信任边界错误的 Docker API 版本。对照仓库源码可以确认修复不仅如通告所述移除了__import__、默认关闭 hooks、白名单化 URL scheme更演进为「声明式 hook 注册表 参数 schema 校验 scheme/SSRF 双重校验 端点级默认关闭 统一错误处理」的多层防御体系。对于所有自托管用户最稳妥的策略是升级到已修复版本、保持高风险能力默认关闭、始终开启认证并让 deploy/docker/tests/ 下的安全回归测试成为发布流程的固定一环。相关升级细节还可继续参考 docs/migration/v0.8.0-upgrade-guide.md 与 v0.8.0 发布说明。【免费下载链接】crawl4ai Crawl4AI: Open-source LLM Friendly Web Crawler Scraper. Dont be shy, join here: https://discord.gg/jP8KfhDhyN项目地址: https://gitcode.com/GitHub_Trending/craw/crawl4ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
