A deep dive into how BIN ranges, Luhn, and a design flaw revealed cardholder PIIs.

Summary

When testing a bank’s assets, I noticed something in a request that no one else had noticed, which disclosed all customers’ full names and national ID numbers. The team has already fixed the issue. However, the underlying problem shows how fundamental concepts in payment systems, such as the Luhn algorithm, BIN ranges, and the predictability of PAN structures, can lead to unexpected consequences when overlooked.

For most people, a credit card number is just a random 16-digit sequence. But the reality is quite different.

The card numbers are based on two key structures:

BIN (Bank Identification Number)

The first 6 to 8 digits of a card identify the issuing bank, and this information is publicly available through various payment network databases.

This structure sharply reduces the number of combinations an attacker can generate. Does it really work that way? Let’s see!

Luhn Algorithm

Hans Peter Luhn, the creator of the Luhn algorithm, created this algorithm to catch simple typing errors in identification numbers. At the time, card and account numbers were entered manually, so mistakes were common. His goal was to provide a quick, lightweight check that filters out invalid inputs before they reach the system. It was never meant for security, only for error detection.

Here’s a scheme that explains the Luhn algorithm:

• BIN (first 6-8 digits) identifies the bank. All banks’ BINs are public.
• Account number is structured and length-restricted.
• Last digit is calculated using the Luhn checksum.

Congratulations, you’ve learned how card numbers are generated! 🎉

Real World Playground

I was performing security testing on a major bank. During the assessment, I found a feature that allows users to transfer money by entering the recipient’s credit card number. When you enter a card number, if the recipient’s card belongs to the same bank, the system automatically fills in the recipient’s name in the designated field.

After I clicked the Continue button, the system made a POST request in the backend to send a verification SMS to me. However, the response included the recipient’s full name and national identity number.

Time To Dive Deeper

First, I tested the rate limit on this endpoint. I sent 100 requests, and the system still returned 200 OK. 💡

I then looked into the Luhn algorithm to see whether I could generate credit card numbers with it, allowing me to demonstrate real world impact. I asked an AI to write a script that could generate such numbers.

I’ve validated them in https://dnschecker.org/credit-card-validator.php page.

Time to Activate The Nuclear Bomb

Now that we have confirmed the endpoint has no rate limiting in place and we can generate valid credit card formats using the Luhn algorithm, I quickly switched to the Intruder tab in Burp Suite.

I started the attack, and out of the 20 randomly generated credit card numbers, we obtained one real user’s full name and national identity number. I can’t include a screenshot because the company asked me not to share it.

The real danger is the mass scraping of personally identifiable information (PII) through trivial automation, and the target bank has more than 100 million customers!! No funds were ever transferred. No alerts were triggered. Getting one piece of PII from only 20 requests is more than enough to send a report. The team quickly fixed the issue and awarded me a $X.XXX bounty.

Final Thoughts

The root cause wasn’t Luhn, BINs, or card formats. These structures have existed for decades.

The real issue was that a modern API trusted user input too much and returned data that should never have been exposed. The predictability of card structures simply made the exploitation effortless.

When a design oversight aligns with a predictable numbering system, security becomes a story of old math meeting new mistakes.

And that’s how a few digits, a BIN, a checksum, an account number ended up exposing some of the most sensitive information a user can have.

Am I safe when using my credit card?

The answer is mostly yes, you are safe because the Luhn algorithm by itself does not create any security vulnerabilities. Someone would still need information like the expiration date and the CVV to use your card. As I explained in this article, as long as the bank does not introduce a security issue based solely on the card number, you are completely safe.

Thanks for reading this article!

Presented by Alp
Independent Security Researcher
https://x.com/alp0x01

Disclaimer

This research was conducted responsibly and no harm was done to any users or systems. No transactions were performed and no data was stored, shared, or misused. All findings were reported directly to the bank in a responsible manner for security improvement. This article is written purely for educational and awareness purposes. Unauthorized testing on systems you do not own is illegal. Always follow responsible disclosure practices.