Memcached未授权访问漏洞高危，因默认无认证且常监听0.0.0.0:11211，导致敏感数据泄露、缓存污染及DDoS反射攻击；修复须绑定127.0.0.1、启用防火墙、TLS加密及SASL认证。
确认Memcached服务是否暴露在公网
登录服务器，执行 netstat -tuln | grep :11211 查看监听地址。如果显示 0.0.0.0:11211 或 *:11211，说明服务正监听所有网卡——【这是高危配置，必须立即整改】。
若输出为 127.0.0.1:11211 或 ::1:11211，则仅本地可访问，基础网络层风险可控。
检查PHP代码中Memcached客户端的初始化方式
搜索项目中所有 new Memcached() 或 new Memcache() 实例化语句，重点查看构造参数或 addServer() 调用。
方法一：直连未鉴权地址
若代码中出现 $mc->addServer('192.168.1.100', 11211) 且该IP不在本地回环范围，需人工确认该IP是否属于可信内网段；若为公网IP或域名解析不可控，【存在服务端口被探测、数据批量读取风险】。
立即学习“PHP免费学习笔记（深入）”；
方法二：使用环境变量注入地址
检查是否从 $_ENV['MEMCACHED_HOST'] 或 getenv('MEMCACHED_HOST') 动态加载——这本身安全，但必须验证 docker-compose.yml 或 .env 文件中该值是否硬编码公网地址或未设访问控制。
审计会话存储是否依赖Memcached且未启用SASL认证
第一步：定位PHP会话配置
查找 session.save_handler = memcached 或 memcache 的 php.ini 或运行时 ini_set() 调用。
第二步：确认认证机制
若配置中未设置 memcached.sess_sasl_username 和 memcached.sess_sasl_password，且服务端未启用 SASL（通过 memcached -S 启动），则会话数据以明文形式在网络上传输，攻击者截获流量即可还原 session_id→user_id 映射关系。
第三步：验证数据加密状态
Memcached 本身不提供传输加密，若未走 TLS 代理（如 stunnel）或未部署在受信内网，【所有存入的 session 数据等同于裸奔】。
检测是否存在未过滤的键名拼接漏洞
全局搜索 "mc_key_" . $user_input、$prefix . $_GET['id'] 等字符串拼接模式，尤其关注缓存键生成逻辑。
若键名直接拼接用户可控参数（如 URL 参数、POST 字段、Cookie 值），且未做白名单校验或正则过滤，攻击者可注入特殊字符（如空格、换行、控制字符）导致协议解析异常，甚至触发 Memcached 命令注入（例如构造 key\r\nset evil 0 0 5\r\nhello\r\n）。
正确做法是强制转义：对所有外部输入调用 str_replace([' ', '\r', '\n', '\0'], '_', $input) 或使用哈希摘要作为键后缀，杜绝原始输入直出。
