Revolut Handed Over Passports and Selfies Because an Email Came From a Real Government Domain, and JFrog Artifactory Attackers Are Stealing the Keys That Let Servers Trust Each Other

Revolut Wasn't Hacked. It Was Asked, and It Answered.

Start with the sentence that should unsettle anyone working in a compliance or fraud team: nobody breached Revolut's systems. Somebody asked, using a real government agency's own email domain, and Revolut answered with passports, verification selfies, home addresses, and complete transaction histories. The fintech giant — more than 80 million customers, operating in over 160 countries — confirmed on September 12 what it calls "a sophisticated external impersonation scam," in which an unauthorized third party used a legitimate government agency's domain email to submit fraudulent requests for customer information, requests Revolut's own staff fulfilled under the reasonable belief they were handling authentic law enforcement business.

The mechanism here is worth understanding precisely, because it's a genuinely different category of attack than the credential theft or system intrusion most breach coverage assumes by default. The fraudulent emails carried valid domain authentication — meaning the technical signals that normally confirm a message is genuinely from where it claims to be all checked out correctly, because the sender genuinely was operating from inside that government agency's own email infrastructure, not spoofing it. Revolut told affected customers plainly: "As the communication carried valid domain authentication credentials, it was fulfilled under the reasonable belief that it was an authentic government agency request." Multifactor authentication, password strength, and endpoint security are all irrelevant to an attack like this one — no credential was stolen, no session was hijacked, because the entire attack targeted the human process of a compliance team fulfilling what looked like a routine, legally-obligated law enforcement data request.

What actually left Revolut's systems, according to the company's own notification to affected customers, is genuinely extensive: full names, dates of birth, occupations, postal and email addresses, phone numbers, copies of passports and driver's licenses, verification selfies taken during account signup, and in some cases account statements and transaction histories. Revolut has disclosed almost nothing about scope — no victim count beyond "a very limited group of customers," no named agency, no confirmed date range for when the fraudulent requests were submitted or fulfilled. That silence has a real, practical cost: without knowing which government agency's domain was compromised or spoofed from within, every other company that routinely honors requests from that same domain remains exposed to the identical attack right now, with no way to know it. Adding real urgency to an already-serious incident, a threat actor has since surfaced on Telegram claiming to possess the stolen customer data and threatening to release more of it unless Revolut pays — though Revolut has not confirmed the extortion attempt is genuine or that the actor's claims about the data's scope are accurate.

The practical lesson for any organization that routinely responds to law enforcement or regulatory information requests deserves to be specific, not just "be careful": valid domain authentication confirms where an email genuinely came from, not that the person sending it is actually authorized to request what they're asking for. If your organization has a defined process for law enforcement data requests, the question worth asking today is whether that process includes an independent verification step — a callback to a publicly listed number, a check against a known point of contact — that doesn't rely solely on the email itself looking legitimate, since this incident is proof that "the email checks out technically" and "the request is genuine" are not the same thing.

Artifactory's Attackers Are Stealing the Keys That Let Servers Trust Each Other

The second story of the day returns to more conventional technical territory, but with a genuinely serious twist for anyone running software supply-chain infrastructure. Cloud security firm Wiz confirmed active, in-the-wild exploitation of three JFrog Artifactory vulnerabilities — the repository software a huge number of organizations use to store and distribute software artifacts, containers, AI models, and packages across their build pipelines. Between August 15 and September 8, Wiz observed multiple distinct threat actors chaining two of the three flaws — CVE-2026-42018, an improper-authentication bug that returns an internal anonymous-user access token even when anonymous access has been explicitly disabled, and CVE-2026-42016, an insufficient token-validation flaw that lets that same token be escalated to full administrator privileges. In some observed cases, attackers went from anonymous access to a working administrator account in under five minutes.

A third flaw, CVE-2026-82329, is considerably more dangerous on its own: a maximum-severity, unauthenticated authentication bypass affecting Artifactory's default configuration directly, requiring no chained vulnerability at all to reach administrator privileges. A public exploit for this specific flaw appeared on September 1, and content delivery network Fastly recorded roughly 406,000 exploitation attempts across its own platform on September 2 alone — attempts observed in traffic, not confirmed compromises, but a genuinely enormous scanning wave regardless. CISA added all three CVEs to its Known Exploited Vulnerabilities catalog, with federal agencies given a two-week remediation window under Binding Operational Directive 26-04.

The detail that turns this from a routine "patch your software" story into something with real, lasting supply-chain consequences is what attackers did once inside. Wiz documented attackers installing malicious Groovy plugins to achieve arbitrary code execution, then deploying a custom Rust-based backdoor with its own command-and-control capabilities — engineered specifically for persistence, meaning it's designed to survive routine cleanup or even a subsequent patch of the original vulnerability. In several observed cases, attackers went further and stole the cluster join key — the shared secret credential Artifactory nodes use to authenticate and register with each other inside a clustered deployment. Watchtowr's Yordan Ganchev put the implication plainly to reporters: an attacker with administrator access to a central software supply-chain system can build, sign, and distribute software using the exact same trusted infrastructure your own engineering team relies on — meaning the actual blast radius of a compromised Artifactory instance extends to everything that instance was ever trusted to build or ship, not just the server itself.

The patching numbers as of Wiz's own September 10 disclosure are genuinely concerning on their own: when CVE-2026-42016 was first published on July 27, 67% of organizations running Artifactory had at least one vulnerable instance, and patching velocity stayed slow throughout the entire campaign window that followed. CVE-2026-82329 has seen meaningfully faster remediation — dropping from 67% to 49% vulnerable within two weeks of publication, likely because its maximum severity rating drew faster attention — but that still leaves roughly half of all deployments exposed weeks after a fix was available and after active, wide-scale exploitation was already confirmed. If Artifactory runs anywhere in your environment, JFrog's guidance is specific: upgrade to the fixed build for your exact release branch, then separately rotate the cluster join key and revoke any access tokens issued since mid-August — patching the vulnerability alone doesn't undo whatever an attacker who already got in did with the credentials they stole before you closed the door.

The Common Thread

Two stories, entirely different mechanisms, converging on the same uncomfortable point: both attacks succeeded by exploiting something each organization had built specifically to be trusted, rather than defeating a technical defense head-on. Revolut's compliance process trusted valid domain authentication as a proxy for legitimate authority, because that's exactly what domain authentication is designed to signal — and an attacker who could legitimately operate from inside that trusted domain didn't need to break anything technical at all. Artifactory's cluster join key exists specifically so servers can trust each other automatically inside a deployment, and once an attacker holds that same key, every one of those servers extends it the identical trust it would give a legitimate node. Neither incident needed a sophisticated technical exploit chain to matter — Revolut's attacker needed one email address, and Artifactory's attackers needed roughly five minutes once inside. Both needed the same thing: a mechanism built to signal trust, used by someone the system had no way to know didn't deserve it.