17370845950

searchsploit可直接离线查询PHP漏洞，无需搭建cve-search；支持模糊匹配如“php 7.4”，需注意大小写与空格；查到后应通过路径分类、文件后缀、源码中的Author/References/Tested on等判断适用性，并验证目标环境的函数禁用、open_basedir、Web服务器类型及扩展启用情况。

直接用 searchsploit 查 PHP 相关 CVE，别先跑 cve-search

很多人以为要先搭 cve-search 才能查 PHP 漏洞，其实没必要。Kali 自带的 searchsploit 已经同步了 Exploit-DB 数据库，查 PHP 版本、组件、CMS 的已知漏洞够用且快。

• searchsploit 默认不联网，查的是本地离线库，响应快、不依赖网络或 API 密钥
• 它支持模糊匹配和关键词组合，比如 php 8.1、wordpress xmlrpc、laravel deserialization
• 如果只搜 php，结果太多；建议加版本号或具体组件名，例如：searchsploit php 7.4 或 searchsploit "phpmyadmin 4.8"
• 注意大小写和空格：双引号包裹含空格的关键词，否则 shell 会拆开解析

查到结果后，怎么看哪个 exploit 真正可用

不是所有 searchsploit 列出来的 exploit 都适配你手上的目标环境。得快速判断可行性：

• 看路径里的分类：比如 webapps/php/... 是 Web 应用层，remote/php/... 是远程利用，local/php/... 是本地提权 —— 根据你的渗透阶段选
• 看文件后缀：.php 多为 PoC 或 webshell，.py 或 .rb 往往是完整利用脚本，但可能依赖额外模块（如 requests）
• 用 searchsploit -x [path] 直接查看 exploit 源码，重点扫三处：Author、R

  

  eferences（有没有对应 CVE 编号）、开头注释里写的 Tested on 版本
• 有些 exploit 标着 [php] 却是针对某 CMS 的插件，不是 PHP 解释器本身漏洞 —— 别混淆语言层和应用层

遇到 searchsploit --update 失败或结果陈旧怎么办

Kali 的 searchsploit 数据库不会自动更新，过时是常态。常见卡点和解法：

• 执行 searchsploit --update 报错 Permission denied：默认数据库在 /usr/share/exploitdb/，需 root 权限，加 sudo
• 更新慢或中断：改用国内镜像源，编辑 /etc/apt/sources.list，把 archive.kali.org 换成 mirrors.tuna.tsinghua.edu.cn/kali 后再 apt update && apt install exploitdb
• 仍找不到新披露的 PHP 漏洞（如 CVE-2025-3823）：Exploit-DB 收录有延迟，此时可临时补查：curl -s "https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=php" | grep -o 'CVE-[0-9]\+-[0-9]\+'，再拿 CVE 号去 exploit-db.com 手动搜

PHP 漏洞实战中，最容易忽略的验证环节

查到一个看似匹配的 exploit，别急着丢 payload。PHP 环境差异极大，几个关键点常被跳过：

• 目标是否禁用了危险函数？用 phpinfo() 或 ini_get('disable_functions') 确认 system、exec、proc_open 是否可用
• 是否开了 open_basedir？这会让文件读取类 exploit（如 LFI 转 RCE）直接失效
• Web 服务器是 Apache 还是 Nginx？某些 .htaccess 绕过或 FastCGI 配置漏洞只适用于特定服务
• 很多 PHP CVE（如 CVE-2018-19518）需要特定扩展开启（如 gd、exif），得先探测扩展列表：?a=

查 CVE 不是终点，验证 PHP 运行时上下文才是挖洞成败的关键。