A Cracker Barrel vulnerability
Cracker Barrel catapulted themselves into the news earlier this year with their big logo change controversy. After seeing them in the news so much, a thought came to mind: are they secure? I set out to find out! After poking around, I found a way to get into their rewards admin panel. Here is how I did it.
Cracker Barrel Rewards
The Cracker Barrel rewards currency is “pegs”. It’s named after the famous peg game. Essentially, pegs are rewards points. $1 spent = 1 peg. You can redeem your pegs online or in-store for food, drinks, etc.
That’s really all there is to it. You can click the header link to learn more if you’d like.
The Admin Panel
I came across a website called the Rewards Portal/Engine: https://rewardengine.crackerbarrel.com/. It is a corporate site and not a consumer site, so only Cracker Barrel employees are supposed to be able to get into it.
It was a simple React JS app and you could see how the login worked by looking at auth-context.js:
Looking closely, I saw an easy potential bypass method: setting the initial “isAuthenticated” value to true. One change in the compiled JS…
…and that was enough to get into the site! Sometimes it really is that simple.
From here, you could manage the rewards and the associated peg values:
That is pretty much it for the good stuff. Nothing sensitive was exposed and no customer data was at risk. The worst thing that could have happened would have been potential business disruption to the rewards system, or inflating your own rewards by modifying items you would then buy.
Important: No write actions were performed. While it looked possible to adjust production rewards, I opted to not test it since there’s probably a lot of rewards activity every second, so any brief change could have led to problems.
What went wrong? It looks like they had the right idea for the auth – the code below sends an authorization token. Since I did not have one, I left it blank, so no token was sent. The API server would accept requests without a token, and that is where the vulnerability was.
Timeline
This time, I decided to give a third-party VDP a try that came recommended. I submitted it October 25, 2025. By the time I heard back on November 17, 2025, Cracker Barrel appeared to have noticed the vulnerability and fixed it themselves. As a result, no further action was required. It was cool to see a company proactively notice and fix a vulnerability so quickly!