Threat intel
Revolve breach: saved card numbers taken by automation
Revolve says an attacker used automated means to take names, card numbers and expiry dates from saved-card accounts. What is known and what to change.
Online fashion retailer Revolve Group told the SEC in a Form 8-K dated October 29, 2026 that an unauthorized actor "may have obtained, through automated means" the name, contact information, payment card number and card expiration date of customers who had saved a payment card to their online shopping account. Customers who never saved a card are not in the affected group. Revolve says the activity has been remediated, that it notified federal law enforcement and brought in outside incident responders, and that it does not expect a material impact on its business.
State breach notices put the access on September 11 and discovery on September 29, and letters to customers started going out on October 29. Filings in four states add up to at least 179,259 people. Revolve has not said how the attacker got in. If you run an online store that keeps cards on file, the useful question is whether a script holding valid logins, or a bug in an account API, could read your saved-card data at scale.
What Revolve has confirmed
The 8-K, filed under Item 8.01 (Other Events) rather than the Item 1.05 used for material cyber incidents, gives no count and no dates. The numbers come from state attorney general filings:
- Texas: 127,200 people, in a filing made public on October 30
- Massachusetts: 46,813
- Iowa: 3,918
- Vermont: 1,328
That totals 179,259, the basis for the "at least 180,000" figure in SecurityWeek's report. Revolve also notified the California attorney general, which does not publish a count. Malwarebytes found a figure of 1,515,073 in the data behind the Texas attorney general's breach portal, but that number is not shown on the public listing and Revolve has not confirmed it, so treat it as unverified.
The notice letters cover names, addresses and other contact details, card numbers and expiration dates. None of the filings or reports mention the card verification code (CVV). The letters tell recipients to review statements, report unauthorized charges to their card issuer and consider fraud alerts or credit freezes.
What "automated means" can and cannot tell you
Revolve has published nothing about the entry point, the tooling or the attacker, and no group has claimed the theft. Everything below is about the class of attack the phrase describes. It is not a finding about Revolve's systems.
"Automated means" usually points to a script working through a normal customer-facing interface at volume, rather than an intruder dumping a database. Two patterns from the OWASP Automated Threats list fit saved-card theft:
- Credential stuffing (OAT-008). The attacker replays username and password pairs leaked from other sites against the store's login. Most fail. The ones that work belong to customers who reused a password, and each successful login opens an account that may hold a saved card, address and phone number.
- Scraping (OAT-011) of account or payment endpoints. The attacker calls the API behind the "payment methods" or "checkout" page directly. If that endpoint returns more of the card than the page shows, or if it accepts an account or wallet ID without checking it belongs to the logged-in user, a script can walk through thousands of records with one session.
Either way, the attacker only gets the full card number and expiry if some page or API sends them to the client. A well-built store keeps the full primary account number (PAN) with its payment processor and returns a token, plus the brand and last four digits for display. PCI DSS requirement 3.4.1 caps what any screen may show at the bank identification number (BIN, the first six or eight digits) and the last four, unless a role has a documented business need. Revolve has not said whether card numbers were taken from a page, an API or somewhere else, or whether a third-party processor held them.
What to do if you are a Revolve customer, or pay for staff cards
- Ask your issuer to cancel and reissue any card saved at Revolve. Without a new number, the old one stays usable wherever a site does not ask for the CVV.
- Read statements for small charges you do not recognise. Criminals test stolen cards with small amounts before larger fraud (the OWASP pattern called carding, OAT-001).
- Expect phishing that uses your real name, address and the last digits of your card. Revolve's letters do not ask for card details. Verify any call or message about the breach by phoning the number on the back of your card.
- If your Revolve password is used anywhere else, change it there too.
Finance teams that run corporate cards should check whether any employee card was saved to a retail account, reissue those, and add a merchant-category review of small charges to this month's reconciliation.
What merchants that store cards should change
Check what the client receives. Open the saved-payment page with browser developer tools and read the JSON the API returns, not just what the page renders. Look for full PAN, expiry month and year, or the cardholder's billing address in any response. The card vault should hand back a token; the API should return brand, last four and nothing more. Do the same for the order-history, checkout and mobile app endpoints, which often reuse older serializers.
Check object ownership. Every call that takes a payment method ID, wallet ID or customer ID should confirm it belongs to the session. Test it: log in as account A, request account B's payment method ID, and expect a 403 or 404.
Rate-limit and bot-check login and account endpoints. Count failed logins per IP, per ASN (the network the traffic comes from) and per username, and add a challenge or block when the ratios jump. Put bot detection in front of the login, password reset and payment-method APIs, not only the checkout. Check new passwords against known breached-password lists.
A successful login followed straight away by a request to the payment-methods endpoint, and nothing else, is what scraping looks like in the logs. Build an alert on payment-method reads per session and per source network, and on accounts read from IPs that have never used them.
Finally, offer multi-factor authentication (MFA) to customers, and ask for it, or for the CVV, before a saved card is shown, changed or used to ship to a new address.
If an investigation finds this pattern, the fix is not finished until affected card numbers are reported to the acquirer, the sessions involved are revoked and the affected customers are forced to reset passwords.
Our web penetration testing covers account APIs, object-level access and what saved-payment endpoints return, and security operations can build the login and account-read alerts above. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Revolve Group Form 8-K, October 29, 2026, SecurityWeek, The Record, Massachusetts AG notice, Malwarebytes, teiss, PCI SSC FAQ 1492, OWASP Automated Threats to Web Applications.