11月10日漏洞：5个，3个认证绕过、1个未授权、1个信息泄露

原创

niuko
niuko

Ncko

2026年11月11日 09:00
安徽

去阅读

11 月 10 日，NVD 里 published 落在这个窗口的记录 614 条。最高分 10.0 的 6 条，9.0 以上的 37 条。

11 月 10 日简报：614 条里按认证绕过、未授权、信息泄露筛出 5 条。SAP NetWeaver 收进来的认证断言没验签名，匿名请求可以冒充任意用户；SuperTokens 的多租户授权少了一道来源检查，手里有一个应用的 API key 就能换掉兄弟应用的 key；Redpanda Connect 的 streams 管理口默认开在 0.0.0.0:4195，没有认证，POST 一个 pipeline 就能执行命令；Signal K 的 resourceId 直接拼进文件路径，%2F 编码的 ../ 读到 security.json，里面放着 JWT 签名密钥；INDOTALENT WHMS 的 appsettings.json 里写着 JWT 密钥、issuer 和 audience，管理员 token 可以自己签。

五条里四条不用账号。SuperTokens 要一个本来有效的应用 API key。SAP 和 SuperTokens 的细节在厂商公告里，Redpanda 和 Signal K 有完整 PoC，INDOTALENT 的密钥直接摆在公开仓库里。

五条分开看是五个产品，合起来两类问题。一类是把身份判断交给了请求内容：SAP 的断言、Signal K 的 resourceId、INDOTALENT 的 JWT。另一类是默认配置留了后门：Redpanda 的管理口不认证，SuperTokens 的父域更新不看来源。

PART 01

五条，先看门槛

时间一列是 NVD 记录的 published 换算到北京时间。

按类别分：

机制示意：五条各自的检查点与绕过位置。依据各家公告与公开 PoC 重绘，不是抓包截图。

PART 02

断言进来了，签名没验

09:17。SAP NetWeaver AS ABAP 和 ABAP Platform。

SAP 的 CVE 描述没有铺开技术细节，只说在某些配置下，系统对进来的认证断言验证不足。CWE-347，签名验证问题。

结果是未认证的攻击者可以提交构造好的数据，绕过认证，冒充任意用户，包括带管理权限的账号。CVSS 3.1 10.0，scope 是 changed，影响能延伸到同一套 ABAP 环境里的其他组件。

受影响的具体版本和 Support Package 写在 SAP Note 3849308 里，CVE 记录没有给版本区间。11 月 10 日是 SAP 的月度安全补丁日，这条跟着当天的补丁一起发。

公开时间：SAP 11 月 10 日发布补丁，NVD 在北京时间 09:17 写入记录。

修复就是打 Note 3849308 里的补丁。短期把到 ABAP 的认证入口收紧，只留必要的来源地址，日志里查认证断言的签名校验失败和身份映射异常。

复现情况：SAP Note 需要账号才能看，公开渠道没有 PoC。

没给模板。SAP 的认证断言走的是 SAP 自己的协议栈，不是一条普通的 HTTP 请求；断言格式、端点、签名算法都没公开。写一个 HTTP 模板只能扫到登录页，证明不了这条。

PART 03

一个应用的钥匙，能开兄弟应用的门

03:16。SuperTokens Core，6.0.0 起多个维护分支都受影响。

SuperTokens 是开源的认证服务，多租户版把多个应用挂在同一个 connection URI domain 下，每个应用有自己的 API key。

Multitenancy.checkPermissionsForCreateOrUpdate 在判断能不能更新父域时，只比对了 connection URI domain 字符串，没有要求发起请求的应用和租户是 public。于是租户 a1 的 key 可以改父域的配置。api\_keys 又不在受保护的配置列表里，同一个请求能把父域的 key 一起换掉。

拿到父域的 key 之后，第二步就能改兄弟应用 a2 的 key。再往后是读 a2 的用户、替任意用户签发 session、在 a2 里留一个 dashboard 用户做持久化，最后把 a2 自己的 key 顶掉，返回 401。

CVSS 3.1 9.9，CWE-639、CWE-863。公告在 v12.2.0 的 PostgreSQL 镜像上复现过。

公开时间：GitHub 安全公告 10 月 16 日发布，NVD 在北京时间 11 月 10 日 03:16 写入记录。

修复版本按分支走：6.0.24、7.0.23、8.0.7、9.0.6、9.1.6、9.2.7、9.3.5、10.0.8、10.1.9、11.0.9、11.1.4、11.2.4、11.3.8、11.4.8、12.0.11、12.1.2、12.2.1、12.3.1。升级后把所有应用的 api\_key 轮换一遍，父域的 key 也要换。

复现情况：公告写了调用链、两步利用和影响，修复 commit 也在仓库里，完整请求没放出来。

没给模板。要 licensed 多租户部署、一个有效的应用 API key，还要按目标自己的应用和租户结构分两步改配置。单请求模板判断不了。

PART 04

4195 端口，默认不设防

02:17。Redpanda Connect 4.39 到 4.110，默认配置下可打。

Redpanda Connect 以前叫 Benthos。跑在 streams 模式时，管理 HTTP API 监听 0.0.0.0:4195，http.basic\_auth.enabled 默认是 false，stream 的增删改查路由前面没有认证。

攻击者不需要账号。POST /streams/{id} 收一份 pipeline 配置，配置里的 command、subprocess、ffi、sql\_raw 处理器本来就是用来执行代码的，服务端不区分这份配置是运维在本地写的，还是匿名请求从网络上递进来的。

命令输出还能原路返回。配一个 http\_server 输入加 sync\_response 输出，同一条 HTTP 响应里就是 id 的结果，不用盲打，也不用回读文件。

CVSS 3.1 9.8，CWE-306。4.111 起管理 API 改成默认不注册，要手动加 --bind-http 才开；开了之后同样能打。

公开时间：CERT/CC 协调，11 月 9 日公开 CVE 和 PoC 仓库，NVD 在北京时间 11 月 10 日 02:17 写入记录。

修复版本 4.111 及以上，升级后确认没有加 --bind-http。升不了就把 4195 收到本机或内网，安全组里删掉对公网的放行，再打开 basic auth。

复现情况：PoC 完整公开，作者在 v4.109.0 官方二进制上跑通了盲打和回显两条路，id 输出是服务账号。

给了一个模板，只发 GET /streams，看管理口是不是匿名可达，不创建流，不执行命令。

id: CVE-2026-123270

info:
  name: Redpanda Connect streams 管理 API 未授权暴露（CVE-2026-123270）
  author: Ncko
  severity: critical
  description: |
    Redpanda Connect 4.39 到 4.110 在 streams 模式下把管理 API 监听在
    0.0.0.0:4195，默认不启用认证。GET /streams 不需要任何凭据即可返回
    流列表；同一端口上的 POST /streams/{id} 可以提交带 command 或
    subprocess 处理器的 pipeline，直接执行系统命令。
    模板只发一个 GET /streams，确认管理口是否匿名可达，不创建流，
    不执行任何命令。
  reference:
    - https://github.com/pagvac/redpanda-connect-unauth-rce
    - https://nvd.nist.gov/vuln/detail/CVE-2026-123270
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    cvss-score: 9.8
    cve-id: CVE-2026-123270
    cwe-id: CWE-306
  metadata:
    max-request: 1
    verified: false
    fofa-query: port=\"4195\"
  tags: cve,cve2026,redpanda,benthos,unauth,exposure

http:
  - method: GET
    path:
      - \"{{BaseURL}}/streams\"

matchers-condition: and
    matchers:
      - type: status
        status:
          - 200

- type: word
        words:
          - \"application/json\"
        part: header

- type: regex
        regex:
          - '(?s)^\s\*[\[{]'
        part: body

PART 05

路径拼错一次，密钥就出来了

06:18。Signal K Server 2.0.0 到 2.33.x，@signalk/resources-provider 1.0.0 到 1.5.2。

Signal K 是船上的数据中枢。v2 的资源接口 GET /signalk/v2/api/resources/:resourceType/:resourceId 把 resourceId 原样交给 FileStore.getResource()，后者用 path.join 拼路径，再 readFile 加 JSON.parse。中间没有校验。

把 resourceId 写成 ..%2F..%2F..%2F..%2Fsecurity.json，就能跳出资源目录，读到配置目录里的 security.json。这个文件里有 512 位十六进制的 JWT 签名密钥，还有用户口令哈希。

拿到密钥就能签一个 HS256 的管理员 token，{\"id\":\"admin\"} 就够。/skServer/loginStatus 会认，返回 userLevel: \"admin\"。再往 POST /skServer/providers 里加一个 Execute 类型的 provider，服务端用 spawn('sh', ['-c', command]) 执行命令，配置还会写进 settings.json，重启后继续跑。

匿名能读的前提是 allow\_readonly=true。默认部署下匿名请求返回 401，但任何一个 readonly 用户的 token 都能走通同一条路。

CVSS 3.1 9.8，CWE-22。

公开时间：GitHub 安全公告 10 月 18 日发布，NVD 在北京时间 11 月 10 日 06:18 写入记录。

修复版本 Signal K Server 2.34.0、@signalk/resources-provider 1.5.3。升完把 security.json 里的 JWT secret 换掉，之前签出去的 token 全部作废；allow\_readonly 没业务需要就关掉。

复现情况：公告给了完整的 Python PoC，从遍历读密钥、伪造 token 到创建 Execute provider 三步都有，作者在 master 340d5bb6 上复现过，重启后仍然生效。

给了一个模板，只确认遍历能不能读到 security.json，匹配 secretKey 字段，不提取密钥，也不拿它签 token。

id: CVE-2026-123807

info:
  name: Signal K Server 资源接口路径遍历（CVE-2026-123807）
  author: Ncko
  severity: critical
  description: |
    Signal K Server 2.0.0 到 2.33.x 的
    GET /signalk/v2/api/resources/:resourceType/:resourceId 没有校验
    resourceId。编码后的 ../ 可以跳出资源目录，读取服务端可读的 JSON
    文件。allow\_readonly=true 的部署允许匿名访问，security.json 里的
    JWT 签名密钥和口令哈希会一起暴露。
    模板只确认遍历是否可达，匹配 secretKey 字段，不提取密钥。
  reference:
    - https://github.com/SignalK/signalk-server/security/advisories/GHSA-4xm8-rg9h-jhq2
    - https://nvd.nist.gov/vuln/detail/CVE-2026-123807
    - https://github.com/SignalK/signalk-server/releases/tag/v2.34.0
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    cvss-score: 9.8
    cve-id: CVE-2026-123807
    cwe-id: CWE-22
  metadata:
    max-request: 1
    verified: false
  tags: cve,cve2026,signalk,lfi,traversal

http:
  - method: GET
    path:
      - \"{{BaseURL}}/signalk/v2/api/resources/notes/..%2F..%2F..%2F..%2Fsecurity.json\"

matchers-condition: and
    matchers:
      - type: status
        status:
          - 200

- type: word
        words:
          - '\"secretKey\"'
        part: body

PART 06

JWT 的钥匙写在配置文件里

08:17。INDOTALENT WHMS，10.20261109 之前。

这套 ASP.NET Core 的库存订单系统把 JWT 配置放在 appsettings.json 里。v9.20250118 的仓库里，Key 是 YourVeryStrongAndSecureSecretKeyWhichIs32Chars!，Issuer 是 YourIssuer，Audience 是 YourAudience，全是占位值，没有换。

Tokens/DI.cs 的校验器信这三个值。知道密钥的人可以给任意 user ID 和 role 签 token，不需要查库，也不需要知道任何账号。签一个管理员身份，整个 API 都开。

CVSS 3.1 9.8，CWE-321。

同一批修复里还有一条默认口令：UserAdminSeeder 建的管理员是 [email protected]，密码 123456，登录后不强制改，对应 CVE-2026-125384。两扇门都通向同一个后台。

公开时间：VulnCheck 发布公告，仓库里有修复 commit 和 issue #48，NVD 在北京时间 11 月 10 日 08:17 写入记录。

修复版本 10.20261109。升级后换掉 JWT Key、Issuer、Audience，已部署实例的管理员口令也要改。只改配置文件不升级不够，旧 token 仍能用到过期。

复现情况：密钥和默认口令都能从公开仓库直接看到，伪造 token 的请求结构没有完整 PoC。

没给模板。要签出目标认的 token，得知道它给哪个 user ID 和 role 发权限，还要找一个受保护的接口验证；这些是目标自己的数据，模板猜不出来，硬发只会打到别人的后台。

PART 07

怎么查，怎么修

今天先做三件事：Redpanda 的 4195 从公网拿掉，Signal K 换掉 security.json 里的 secret，INDOTALENT 换 JWT Key 和管理员口令。SAP 和 SuperTokens 按厂商补丁走，前者先确认 Note 3849308 覆盖到自己的 Support Package，后者升完记得轮换 key。

日志侧看这几处：

— SAP：认证断言的签名校验失败、同一来源短时间内的多身份映射

— SuperTokens：父域配置的更新请求、api\_keys 的变更、兄弟应用 key 突然 401

— Redpanda：4195 的连接记录、POST /streams/ 的请求体里带 command 或 subprocess

— Signal K：/signalk/v2/api/resources/ 里带 %2F 或 .. 的请求，后面紧跟 /skServer/providers

— INDOTALENT：同一个 IP 用不同 user ID 的 JWT 访问接口，或 [email protected] 的登录

PART 08

资料与说明

五条里给了两个模板。Redpanda 的模板只读 /streams，Signal K 的模板只确认遍历能读到 secretKey，都不执行命令、不拿密钥做后续操作。其余三条各自写了原因：SAP 走私有协议栈；SuperTokens 要 licensed 多租户和一个有效 API key；INDOTALENT 要目标自己的 user ID 和 role 才能签出可用的 token。

版本号、评分、修复版本和时间线来自 NVD 记录、SAP Note 3849308、SuperTokens 的 GHSA-4rf2-xqvf-8rcx、Redpanda 的 CVE-2026-123270 公告与 PoC 仓库、Signal K 的 GHSA-4xm8-rg9h-jhq2、VulnCheck 的 INDOTALENT 公告。

同一天还有几条在名单里但没写。SAP Gateway 的默认 ACL 问题（CVE-2026-89103，10.0）和 SAP ABAP 这条同一天发，缺技术细节，写进来只能重复公告；Craft CMS 的未认证 SQL 注入（CVE-2026-115934，9.8）利用已公开，但不在这五类里；D-Link M60 的 MQTT 硬编码凭据（CVE-2026-125086，10.0）要先进设备；Kubero 的 JWT 回退密钥（CVE-2026-125370，9.8）和 INDOTALENT 同类，篇幅有限只留了一条。

免责声明：由于传播、利用本公众号Ncko所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！