Introduction
When it comes to consumer fintech, attackers do not need to steal credentials or plant malware. They need a poorly protected endpoint with something valuable behind it.
That is what unfolded with TCN – The Card Network, a popular multi-retailer gift card brand sold across Woolworths, Coles, Big W, Target and other national chains.
A vulnerability identified by Simon Dean, an ordinary consumer with a technical background, exposed a design flaw that would be simple to automate with basic Python code and a laptop.
Background
TCN gift cards are available across major Australian retailers including Woolworths Group, Coles Group, and BIG W. They’re activated at the point of sale and accessed via a 4-digit PIN, which is concealed under scratch-off foil.
In mid-July 2025, Simon Dean purchased two TCN gift cards, drawn in by a promotional points offer. But when he attempted to use them, one had already been drained.
Strangely, the PIN code on the back of the card was still concealed.
This left Simon confused as to how someone could have used the value of the cards.
After failed attempts to work with support and trying to understand the error himself technically, he ended up discovering a vulnerability that he suspects may have been used to drain the value from his previously purchased cards.
He attempted to report the issue through three separate channels. One generic escalation email was received.
He then published a YouTube video disclosing the vulnerability. The video included live footage of the redemption page and demonstrated that no rate-limiting was in place.
Shortly after publication, TCN posted a message stating that the relevant functionality was offline for 24 to 48 hours. This was the first visible sign of remediation.
A realistic attack path
To understand how this might could be exploited by fraudsters, consider the workflow from an operator’s point of view, where the online redemption process that validates a card number and a four digit PIN is the primary objective because it offers a direct path to turning observed data into money before a legitimate buyer even visits the site.
1. Harvesting numbers on the shop floor
An operator begins by visiting high traffic stores and quietly photographing the fronts of hanging gift cards, capturing the visible card numbers in a way that looks like ordinary browsing to anyone nearby, then logging each image with the store location, time of day, and rack position so the set can be revisited in a consistent pattern.
Over several passes the operator builds an inventory of candidate numbers spanning multiple retailers and denominations, which creates enough volume to make later polling efficient without needing any physical interference with the packaging.
This simple collection routine is repeatable, low cost, and hard for store staff to distinguish from normal customer behaviour.
2. Detecting activation without touching a register
Back at a laptop, a basic monitoring script checks the state of each harvested card at scheduled intervals to determine when a real customer has paid at the register and the backend has marked the card as active, using whatever public responses or error states the system exposes as a proxy for activation.
The polling cadence tightens during periods when activations are most likely, such as evenings and weekends, which improves the chance of catching new value within minutes of purchase and reduces wasted effort on cards that have not been sold.
The output of this phase is a timestamped list of active cards that are ready for the next stage.
3. Discovering the PIN once a card is active
When a specific card flips to active, the operator pivots to PIN discovery by issuing rapid, automated submissions to the redemption endpoint and observing which response indicates a correct value, a process that becomes practical if the server does not enforce CAPTCHA, rate limits, or temporary lockouts after failed attempts.
Because the space of four digit combinations is small and easily enumerated, the time to success depends less on sophistication and more on whether the backend applies friction that slows iteration or blocks it outright.
In environments where no friction exists, the average time to a correct PIN is short enough to allow action before the purchaser reaches the website.
4. Converting stored value into liquid value
After a valid PIN is identified, the operator completes the online conversion by selecting brands that issue digital codes immediately, since instant issuance reduces the risk window in which a provider might intervene or reverse a transaction.
If partial redemptions are permitted, the operator may split balances across multiple brands to avoid concentration and to make downstream tracing harder, recording each issued code with the corresponding card number, PIN, and timestamp to maintain inventory discipline.
This conversion step is attractive because it occurs entirely within official workflows and leaves few artefacts beyond standard transaction logs.
5. Monetising the result at scale
Issued codes can move quickly through private chat groups and small marketplaces where buyers accept a discount in exchange for speed, which allows an operator to convert inventory to cash without interacting with the originating retailer again.
Some operators prefer to launder value indirectly by purchasing digital goods that hold resale value, reducing reliance on a single resale channel and smoothing price variability across markets.
At this point the original cardholder experiences the failure as a zero balance at redemption, and customer service teams inherit the problem without obvious indicators that point to a specific actor.
Evidence of prior automation
I next wanted to establish whether anyone had already scripted against the public TCN endpoints that expose card status or accept redemptions.
That would show how long the weakness might have been visible and whether tooling existed outside research circles.
I searched GitHub for basic terms such as: TCN, gift card, balance, pin, telegram, bot and pretty quickly I came across exactly that.
What it appeared to be was a Telegram bot for checking TCN balances hosted externally on Heroku.
A user sends a card number and a PIN to this custom API, the bot replies with status and remaining value. The code used a small HTTP client to build one unauthenticated request to a public URL and then parsed the JSON reply.
There were no API keys, no session cookies, and no token exchange. There was no handling for CAPTCHA challenges because the endpoint did not present any.
The repository history showed the first commit long before July 2025, that timeline indicating the permissive behaviour on TCN’s public endpoints likely had been discoverable for an extended period.
It also raises the question as to whether routine monitoring for third party automation was either missing or ineffective.
Contacting the bot’s author
After reaching out to the dev who wrote the bot, he replied that that he’d written the bot almost two years earlier, soon after moving to Australia and how he’d discovered that a balance endpoint returned structured data with no authentication, wrapped it in a Telegram interface for convenience, confirmed it worked, and left it online.
Taking the information so far into account suggest the following:
- The open behaviour was present well before July 2025.
- It was discoverable by a developer using public information.
- There may likely be others that had discovered the same issue (but we don’t know if they exploited maliciously or not)
Signs this may be much bigger than one report
After reviewing Simon’s case, I began looking at whether other customers had unknowingly experienced the same failure – without ever realising it might have been the result of a security issue being exploited by fraudsters.
During my search I looked at ProductReview.com.au, a consumer complaint platform widely used by Australian buyers to report poor service.
What I found, in my view, suggests the problem may be far more widespread than anyone previously acknowledged.
Real customers. Real money. Same story.
One reviewer from QLD reported that their gift card had been emptied using “this method” back in March 2025, and after over five months of battling support and submitting documentation – including a signed Statutory Declaration – they still had not received a refund.
Another review from just a month ago described being gifted a card that “stopped working for no reason,” and that when they contacted support, they were told to produce the original physical receipt or they would not be assisted despite the card having been a gift.
In my opinion, the symptoms described in multiple user reviews – even months before the issue was publicly acknowledged – appear consistent with the same issue that was described by Simon.
The fact that there are similarities in the sequence of events suggests the vulnerability may have been exploited earlier than anyone realised, and dismissed for months if not years as user error or unknown fraud.
What this means for fintech and stored value platforms
In short – build systems that expect to be attacked
If your product moves money.. and make no mistake, gift cards are money – then your platform must enforce parity between the friction applied at onboarding and the friction applied at redemption.
That means CAPTCHA must exist not just where accounts are created, but where balances are spent.
It also means threat detection can’t just be a SOC team reviewing device logs – it has to be wired into all areas of the business, payment processes included.
These are not abstract security principles, they are practices that determine whether your customers’ funds can be drained in the wild – and whether they find out from you, or from a YouTube video published by someone else.
Closing Remarks
You cannot rely on user honesty
- Failed attempt thresholds must be enforced server-side.
- After a set number of incorrect inputs (e.g. 5 or 10), the card should be locked.
- Escalation should route the user to manual verification or support intervention.
- All anomalies velocity, geo mismatch, IP fingerprinting should be logged and correlated.
Allowing unbounded input attempts on a live money system in 2025 is a failure of design, it is not a sophisticated vulnerability.
