No real card data, at any point. The numbers it emits are synthetic: they satisfy the Luhn checksum and sit inside published IIN ranges, correspond to no account at any issuer, and cannot authorise a transaction.

The package also has:

• no runtime dependencies — composer require pulls in nothing but this,
• no network calls,
• no lifecycle scripts (nothing runs on install),
• no state — it reads nothing and writes nothing.

random_int() is used for uniformity, not secrecy; nothing here is a security boundary. SeededRandom is a plain xorshift32 and is explicitly not cryptographic — it exists so fixtures repeat, and it must never be used to generate anything that guards anything.

If you believe you have found a security issue — in the package itself or in its publishing chain — email bugs@ccgenerator.org. You will get a reply within a few days. Please do not open a public issue for anything you would not want exploited before it is fixed.

A finding along the lines of "this package generates credit card numbers" is working as documented, not a vulnerability — see What it is not in the README. The package cannot produce a number that authorises anywhere, and adding data that made its output resemble real card data more closely would be rejected on the same grounds.

Synthetic PANs are still card-shaped, and card-shaped strings in logs, error trackers and analytics events are exactly what PCI DSS audits flag. Treat them like the real thing in that one respect: keep them out of the places you would not put a real PAN. The reasoning is in PCI DSS for developers.