Why does one QSA pass me and another would not?
A question came up about a PCI audit that was performed for one of our customers. They just finished their PCI audit and passed. I am now working with them on a new software application and there is a vulnerability in their application that was ranked as a high. This was discovered on an application penetration test back in 2011 but was accepted by the company as a business risk; resulting in the vulnerability being marked closed because of this acceptance. The client wanted to include this same functionality within a new application, resulting in the new application containing the vulnerability.
The QSA who performed their last PCI audit should not have passed them because this vulnerability is in violation of Requirement 6.5.6. The requirement states:
Prevent common coding vulnerabilities in software development processes, to include all “High” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).
Please note, according to PCI Requirement 6.2, a CVSS score of 4 and above is considered to be a “High” risk vulnerability.
Because of this vulnerability and because the company has not fixed it, they could be fined by their bank. Furthermore, this vulnerability could pose financial liability and reputation risk for the company. If customers find out about this vulnerability, they may question the company’s ability as a trusted vendor.
So why did the previous QSA pass them? Without discussing this with the QSA, one can assume that since the issue was closed, it was fixed. You have to remember that when the auditor is performing the audit, they are presented with a lot of information. This is a lot like trying to drink from a fire hose. Things like this vulnerability could have been missed; it was one finding out of many or possibly the auditor assumed that since the finding was closed, that it had been remediated. Another reason may be the way an auditor interprets the PCI Requirements. This person may not have understood the requirement and made the wrong interpretation. In many cases, one auditor’s interpretation may be different from another auditor.
It does not really matter now, why the company passed their audit, even though they did not fix the vulnerability. The issue now is that they need to fix it before moving forward.
Explore More Blog Posts
“StyleSmuggler” – Adobe Commerce, Adobe Commerce B2B, and Magento RCE (CVE-2026-75650): Overview and Takeaways
Adobe disclosed CVE-2026-7565, dubbed “StyleSmuggler,” on September 7th, 2026. The vulnerability, which received a maximal initial CVSS score of 10.0, affects Adobe Commerce, Adobe Commerce B2B, and Magento Open Source. The flaw allows an unauthenticated network-based attacker to execute arbitrary code by injecting PHP through Magento's email template engine.
Modern Adventures in Azure Privilege Escalation
Azure has been growing rapidly over the past few years As of June 2026, there were over 200 services, 897 built-in Azure RBAC roles, and 22,018 different permissions. The attack surface of Azure has also increased with this growth. There are also a number of new and updated tools that give us insight into the […]
A New Era for Offensive Security
Today, NetSPI and Synack announced a definitive agreement to merge, backed by KKR, forming the industry’s leading offensive cybersecurity platform.