客户端网站的安全扫描显示，由于他们运行的是PHP 5.3.3，他们很容易受到CVE-2011-1092的攻击(在5.3.6及更高版本中修复)。
通常我会说后移植会处理这个问题，因为他们的PHP多年来一直被后移植到5.3.27，但是在更改日志中没有迹象表明这个特定的CVE已经被解决了。
查看https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-1092和https://access.redhat.com/security/cve/CVE-2011-1092明确指出，这个问题在RHEL和Centos附带的PHP版本中还没有得到解决，因为RHEL不认为这是一个安全问题。
这让客户陷入两难境地-他们的PCI DSS合规扫描仪公司(Trustwave)不接受RHEL的声明"这不是一个安全问题"，说"访问[上面链接的RHEL页面]似乎表明RedHat没有解决CVE-2011-1092。由于这一发现会影响PCI DSS合规性，因此确实需要确认以某种方式解决它。"
谁有什么建议如何进行这个?是否有可能通过以某种方式修补文件来直接解决问题?
提前感谢您的建议
这就是PCI-DSS行业的工作方式——训练有素的猴子对应用程序运行自动扫描软件，如果它变成红色，就跳上跳下。试图和猴子讲道理是没有用的，因为它们只懂红色和绿色。不要误解我的意思——在大多数这些工具中编写代码的人都非常聪明——但他们不是你必须与之打交道的人。不幸的是，猴子被赋予了很多权力。问题的存在并不意味着问题是可利用的。
为了公平起见，NIST将风险定为"高"。但是我同意Redhat的观点——这可能被利用的唯一方法是有人访问php代码，或者如果你将用户提供的值直接传递给低级函数。如果我是你，那么我要做的第一件事就是检查代码是否使用共享内存-如果没有添加相关函数到php.ini中的disable_functions设置。虽然很难证明攻击者在启用该功能并在代码中使用该功能时无法利用该漏洞，但可以证明，如果该功能不可访问，则无法利用该漏洞。当然，这是否会安抚猴子是另一回事。
此漏洞仅影响shmop_read()功能。你可以在php.ini中禁用函数;如果您这样做并且没有抛出错误，则您的代码不会也不能使用该函数，因此您是安全的。