Say for example I know someone who runs an extremely shady business and has their credit card information exposed to web hosting customers (on the same machine as their billing), and they accept credit cards on their site (via ssl).

How can I anonymously report them for a PCI-DSS audit?

Just about every hosting provider here most likely colocrossings also is in violation of PCI-DSS some more so than others. But pretty much anyone using WHMCS, modernbill, ubermsith and other have their setups installed and configured incorrectly and are in blatant violation of PCI-DSS. People using WHMCS and the such on a reseller account or even a VPS have no hope of ever being PCI compliant. This is all of course they are storing the CC's in the database which 99% of the people do. So really Visa/MC could just fine and shutdown almost every host on WHT for non-compliance.

Form a competitors point of view it might be a great way to limit the competition in generally, however, if you want to report this you will need to do this directly to Visa or MC, but I doubt they will do any action, better idea is to report it to the Acquriing bank, but I guess most of them are hiding behind some 3.party processor, but it is a try worth also because I wouldn't be very happy if my CC information was in the hands of such companies....

Just about every hosting provider here most likely ********* also is in violation of PCI-DSS some more so than others.

Bold but unverifiable statement based in no way in fact.

But pretty much anyone using WHMCS, modernbill, ubermsith and other have their setups installed and configured incorrectly and are in blatant violation of PCI-DSS. People using WHMCS and the such on a reseller account or even a VPS have no hope of ever being PCI compliant. This is all of course they are storing the CC's in the database which 99% of the people do. So really Visa/MC could just fine and shutdown almost every host on WHT for non-compliance.

Currently PCI does not require existing merchants to use PA-DSS certified software and all are able to use the programs mentioned above. If placed in a proper network configuration, each program can be segmented and configured to meet PCI guidelines, even using virtualization.

Say for example I know someone who runs an extremely shady business and has their credit card information exposed to web hosting customers (on the same machine as their billing), and they accept credit cards on their site (via ssl).

How can I anonymously report them for a PCI-DSS audit?

PCI-DSS is a industry created regulatory body. Smaller merchants self report compliance using slightly more than the "honor" system and a scan report. Larger merchants require 3rd party validation. Unless there is an actual breach involving cardholder data, it is unlikely to get anyone's attention.

Any other method would probably cause unbelievable amounts of insanity. Everyone would be reporting competitors as violators and break any form of violation reporting system.

Thats exactly what I'm saying though, is that the provider has a breach of sorts, the root password to their MySQL is set to nothing. I installed vBulletin on accident via root on this shared web-hosting for a friend. Which also seems to be the same machine that hosts their billing.

Yes, I could say "hey host, look at this" but if they are that stupid to have no root password for MySQL they should not be in business. They should be audited and fined.

The best thing to do is to let both the merchant, hosting company, and their merchant account provider know that the information is exposed. If no one does anything, after that, you pretty much have to wait for a breach to occur before Visa steps in. At that point both the merchant and merchant account acquirer will be held up for fines as well as having to pay for forensic audits of the breech. If it is really just "hanging out there" just let them know. The merchant may be a shady character, but his customers would be innocent victims in case of a breech. As far as PCI compliance goes, here is a secret from a guy on the inside---if you get hacked, you were not compliant. Payment processing companies like Heartland were technically PCI compliant, and had gone through numerous audits. Never the less, they were hacked, and had to pay millions in fines. PCI is supposed to help security,--and it does--it is just some good basic guidelines, but it is not foolproof. If you get hacked, even if you went through the audit--you are liable as a merchant for the breech.

The PCI audit is a simple honor system style questionnaire combined with periodic remote scans for known vulnerable software. PCI compliancy seems to be more about encouraging good practices than about actually catching anybody doing anything wrong. Technically speaking, a web hosting company could do all kinds of things wrong and still be completely PCI compliant as long as they do not directly store any credit card details.

Additionally, PCI audits do not include local security testing. For example, if the MySQL root account allowed localhost to log in with no password, the remote PCI scan would never notice that. The PCI scan would notice if you were running MySQL since it would be listening on a standard port, but it would not notice that root account was not secured locally. Even though any local user could log into the root account locally, the server would look secure remotely. So while the host would be insecure, the PCI audit would not flag that problem.

Additionally, PCI audits do not include local security testing.

Incorrect, PCI requires internal and external penetration tests and internal network vulnerability scanning.

just dont store credit cards.

There currently exists back-end and front-end tokenization technologies from a few payment processing vendors. Properly implimented back-end tokenization removes the storage risk for the merchant and hosting provider. Front-end tokenization all but removes the merchant and hosting provider from PCI scope entirely. The hosting provider would still need enough security in place to prevent non-authorized users (hackers) from somehow bypassing the front-end tokenization layer on the merchants site. Merchant using front-end tokenization qualify for PCI SAQ A because the merchant and host never touches cardholder data, only tokens.