The Binance hack hit USD 6.34B via a fake job interview, an abused AI tool and EIP-7702 delegation. The FBI points to North Korea.
Related Posts:
The post Binance Hack Report Details Fake Job Interview, AI Tool Abuse and EIP-7702 Wallet Drain appeared first on Daily CyberSecurity.
The Binance security incident on October 29 shows how a fake recruitment process can become the entry point to critical financial infrastructure. The attackers combined social engineering, compromised developer tools, stolen credentials and abuse of an internal AI application to reach the cryptocurrency exchange’s wallet signing systems.
“Woah – so the Binance hack was indeed via a dodgy job interview for one of its developers who was tricked into downloading malware as part of the “interview” – costing the company >$3bn…” the popular best seller author and cybercrime expert Geoff White wrote on LinkedIn. “Worth noting:
– The 2016 hack of Bangladesh Bank also attributed to North Korea’s Lazarus Group of hackers was via a job application
– The 2022 theft of $625m from video game Axie Infinity happened via offering an employee a juicy job offer
RECRUITMENT IS RISK. If you’re not educating employees on this, start now…
– The 2024 heist of $1.5b from Bybit relied on tricking an employee of its supplier into downloading a dodgy share trading app onto the work machine (so not using a recruitment lure, but still deceiving a target into downloading malware)”
In its initial findings and response update, published on November 3, Binance described the operation as a “sophisticated, multi-stage campaign.” The company estimates that approximately $6.34 billion in digital assets were affected. The FBI attributed the incident to the North Korea-linked APT “TraderTraitor,” also tracked as Lazarus Group and APT38.
“Our current investigation indicates that this was a sophisticated, multi-stage campaign. It was not a single isolated breach or a simple phishing incident.” reads the update published by the crypto firm. “The attackers combined a range of techniques, including social engineering by fake recruitment interviews, malicious software downloads, compromised internal AI tooling, endpoint compromise, and an advanced transaction-authorisation method.”
The operation began months before the theft. In June 2026, an engineer from Binance’s Wallet DevOps team downloaded a tampered Homebrew installation while searching online for a popular AI coding tool. Binance detected the suspicious activity, replaced the device and rotated the associated credentials, but information about the engineer’s role and colleagues had already been exposed.
The attackers then targeted another software engineer through a legitimate job-hunting platform. In September, someone posing as a Project Director arranged two interviews: first with an HR representative, then with someone claiming to be the CEO of a fictitious company. During the first video interview, the supposed HR representative shared a social media account containing personal photos and videos to establish credibility.
At the end of the second interview, the engineer was asked to download a technical assignment containing a malicious code repository onto his work computer. The malware executed during setup, replacing a legitimate development tool component with a malicious version. It used obfuscation to evade detection, executed commands and established communication with an attacker-controlled server. Binance said its endpoint security tools didn’t detect the malware at the time.
“The second interview was conducted in a popular social chat app, near the end of the interview, Engineer B was instructed to download an “assignment” containing a malicious code repository onto his work computer.” states the firm. “The repository contained malicious code that executed during the setup process, initiating a series of unauthorized activities.”
The compromise then moved beyond the affected workstation. On October 20, attackers used the compromised computer to abuse an internal AI tool and gain access to the systems of two other employees, including the Wallet DevOps engineer initially targeted in June. They discovered that his computer contained a token with container deployment permissions.
This is one of the more significant aspects of the incident. The report doesn’t identify a vulnerability in the AI model itself. Instead, it shows how an internal application can become an attack pivot when an adversary gains access to a compromised employee’s environment and the permissions available to that user.
“The attacker leveraged the compromised computer of engineer B and used an internal AI tool to gain control over the Wallet DevOps Engineer A and another Wallet Software Engineer C.” states the report. “The attacker soon discovered Wallet DevOps Engineer A had a container deployment permission token on his computer.”
On October 29, the attackers used stolen credentials to access another engineer’s computer, deploy a container and execute a malicious script. This gave them access to Binance’s internal wallet signing service, allowing them to initiate transactions outside the normal withdrawal process.
The transfers involved several blockchain networks. Five Binance hot wallets sent 233.46 million XRP to an attacker-controlled address, while other transfers involved approximately 970,500 SOL, 44.2 million OP and 18,270 BTC.
The attackers also exploited Ethereum’s EIP-7702 authorization mechanism to grant a malicious smart contract partial execution rights over a Binance hot wallet.
“EIP-7702 allows an account to delegate certain execution rights to a smart contract without exposing the private key. In this case, the attacker used that mechanism to give an attacker-controlled smart contract partial execution rights over a Binance hot wallet.” the company states.
Suspending withdrawals wasn’t enough to stop the transfers because the malicious authorizations already existed on-chain and operated independently of Binance’s normal withdrawal infrastructure.
Binance had to develop a specific procedure to revoke them. The use of Multi-Party Computation (MPC) meant there was no single private key that could immediately invalidate the unauthorized permissions. The final unauthorized transfer, involving 2,961.9 ETH, was finalized at 23:56 UTC. Binance cleared the malicious authorization at 00:10 UTC on October 30.
The company estimates that approximately $6.34 billion in assets were affected, of which around $2.85 billion had been frozen or intercepted as of its November 3 update. Binance says it will absorb the financial impact and has already replenished 98% of the affected token assets, based on figures reported on October 31.
The exchange has rebuilt the affected wallet infrastructure and internal AI tool, replaced compromised devices, revoked associated credentials and tokens, and strengthened endpoint monitoring and wallet-service controls. It is also engaging independent cybersecurity firms to review the incident.
The attack highlights the need to treat recruitment processes, developer workstations and internal AI applications as part of the corporate attack surface. Technical assignments should run in isolated environments, deployment credentials should be short-lived and tightly restricted, and internal AI tools should never inherit unnecessary access to sensitive systems.
Binance also said its security team had detected and prevented 57 suspected North Korea-linked cyber threat cases during 2026. These included fake job interviews, malicious developer tools, compromised software packages and browser extensions, fake video-conferencing applications and campaigns designed to steal credentials or deploy remote-access malware.
The incident is another reminder that attackers don’t always need to break directly into critical infrastructure. Sometimes, compromising the people and tools that manage it is enough.
“We are sharing this initial report because security improves when the industry learns together.” concludes the update.
In September, Japan’s National Police Agency, the FBI, the US Department of Defense’s Cyber Crime Center, and intelligence agencies from Australia and Germany published a joint advisory about a group called WaterPlum, better known as Contagious Interview. The name says it all. The job interview is the infection vector.
The numbers in the advisory are hard to shrug off. At least 30,000 devices infected across more than 100 countries, funds or credentials stolen from over 7,000 cryptocurrency wallets, and a total of 1.7 billion yen, roughly $10.71 million, funneled back to North Korea. The victims are almost always the same type: freelance developers and specialists in blockchain and Web3 work.
Japan’s NPA and the FBI assess that both WaterPlum operators and some North Korean IT workers report to the same place, the 313 General Bureau of the Munitions Industry Department, under the Workers’ Party’s Central Committee. That’s not a loose affiliation. It’s an org chart.
The trap itself is almost embarrassingly simple. WaterPlum actors pose as recruiters or hiring managers, often impersonating real AI, crypto, or NFT companies, and reach out on social media, job boards, and freelance platforms. Candidates get invited to a technical interview, then told to download a file to complete a coding test or fix a supposed bug on the video call.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Binance)
In the second round, held on a popular chat app, Engineer B was told to download an "assignment" onto his work computer. It contained malicious code that ran during setup, swapped a legitimate development tool for a malicious version, and connected to an attacker-controlled server. The zero-day malware was not detected by endpoint security tools at the time.
On October 20, the attackers used Engineer B's compromised computer and an internal AI tool to gain control over Engineer A and another wallet engineer, Engineer C. They then found that Engineer A had a container deployment permission token on his machine.
The FBI attributed the $6.3 billion Binance crypto heist to North Korean state hackers, sparking denials from Pyongyang amid ongoing asset recovery efforts.
Related Posts:
The post North Korea Binance Heist: Pyongyang Denies $6.3B Hack appeared first on Daily CyberSecurity.
The FBI has named North Korea as the party behind the theft of more than $6 billion in virtual assets from the crypto exchange Binance, on or about October 29, 2026. The bureau published its findings in a public alert. The FBI specifically blames the North Korea-linked APT “TraderTraitor,” also tracked as Lazarus Group and APT38.
Binance hasn’t named a culprit, but the blockchain analysis firm TRM has. It was the first to attribute the attack to TraderTraitor, and Chainalysis also said it’s highly confident in that finding.
“The Federal Bureau of Investigation (FBI) is releasing information advising the Democratic People’s Republic of Korea (North Korea) was responsible for the theft of more than $6 billion USD in virtual assets from cryptocurrency exchange Binance, on or about October 29, 2026. The FBI refers to this specific North Korean malicious cyber activity as “TraderTraitor.”” reads the FBI’s statement.
“The FBI, together with partners at the USSS and IRS-CI, has observed TraderTraitor actors converting stolen assets primarily into Ethereum (ETH). It is expected these assets will then be further laundered by converting them using DeFi and instant swap services as they prepare them for further laundering stages.”
Attackers used access from an engineer’s laptop to reach a service container and send unauthorized withdrawal requests. Binance says it has found no evidence that attackers stole any wallet private keys.
The FBI, along with the U.S. Secret Service (USSS) and IRS Criminal Investigation (IRS-CI), has spotted TraderTraitor actors turning the stolen assets mostly into Ethereum (ETH). The agencies expect the next step to be more laundering, by swapping the funds through DeFi and instant swap services as the actors prepare them for later stages. Instant swap services are aptly named.
The alert is aimed at private companies as well as law enforcement agencies. The FBI, USSS and IRS-CI are asking several types of businesses to help stop the money laundering. These include THORNode operators, who support the THORChain network, RPC node operators, who provide apps with access to blockchains, instant crypto exchanges, DeFi platforms, blockchain analytics companies and other crypto service providers.
The request is clear: these companies should block any transactions involving the wallet addresses used by TraderTraitor, including funds that can be traced back to them. According to the FBI, these addresses have received stolen funds and are controlled by North Korean attackers or are closely linked to them. The full list of addresses is included in the alert.
If you run any of these services, the first job is to check your blocklists against that list. The second is to look at transaction flows that touch those addresses indirectly, since the FBI says to block anything “derived from” them, not just direct transfers. Blockchain analytics firms are named for a reason, because tracing derived funds is their work.
The FBI says it’s committed to protecting the virtual asset community by identifying, mitigating and disrupting North Korea’s illicit cybercrime and virtual asset theft.
“The FBI maintains its commitment to protecting the virtual asset community by identifying, mitigating, and disrupting North Korea’s illicit cybercrime and virtual asset theft activities.” concludes the report. “If you have any information to provide, please contact your local FBI field office or FBI’s Internet Crime Complaint Center at ic3.gov.”
TRM says the attacker moved about $6.36 billion out of Binance wallets on ten blockchains on October 29, most of it in roughly 20 minutes starting at 20:05 UTC. That makes it the largest crypto theft on record, about four times the $1.5 billion Bybit hack of February 2025.
“On October 29, 2026, an attacker moved approximately USD 6.36 billion out of Binance wallets on ten blockchains, most of it in about 20 minutes starting at 20:05 UTC. That makes this the largest crypto theft on record, about four times the USD 1.5 billion Bybit hack of February 2025. Binance has confirmed a security incident and suspended withdrawals on several networks.” TRM said. “TRM attributes the attack to TraderTraitor, North Korea’s elite hacking unit, based on robust on and off-chain intelligence. We make this judgment with high confidence. TRM is tracking the funds and alerting partners through the Beacon Network.”
Freezing the money only went partway. Tether, Circle, Ripple and World Liberty Financial froze about $2.67 billion in stablecoins, and Arbitrum’s Security Council froze 8,426 ETH and 74.6 million ARB, for roughly $2.7 billion in all. But the attacker raced the freezes by selling USDT to market makers and borrowing ETH against USDT on Aave. It now holds more than 420,000 ETH and 18,270 BTC, about $2.4 billion beyond any issuer’s reach.
The early freeze numbers were messy too, Tether and Circle froze approximately $1.79 billion in stablecoins associated with the suspicious transfers in the initial reports. Those amounts describe different moments, and you shouldn’t add them without checking whether they cover distinct assets. A freeze works on tokens that have an issuer to call, and Ether and Bitcoin don’t.
Below is the link to my interview regarding the Binance case for Italian state television.
https://www.youtube.com/watch?v=DtvhBA9TdPo
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Binance)
Binance was investigating suspicious transfers that early estimates put at up to $5.8 billion. A day later, multiple media outlets reported that the largest cryptocurrency exchange had linked the theft of about $6.3 billion to a DevOps engineer’s compromised laptop. Billions had moved out of wallets linked to the exchange.
According to The Block, blockchain analyst Spreek identified approximately $3.55 billion in incoming transfers to an initially unidentified wallet.
“Onchain data flagged by analyst Spreek shows about $3.55 billion in incoming transfers to the unlabeled wallet, with nearly $900 million subsequently moved across other wallets.” The Block reports. “Conor Grogan, a senior director and product leader at Coinbase, says the amount is up to $5.8 billion.”
Coinbase executive Conor Grogan initially estimated that the total value of the movements could reach $5.8 billion.
Those figures came from blockchain tracking and differing estimates, so they didn’t necessarily show the amount stolen.
Binance pointed out that customer funds were safe, while co-founder Changpeng Zhao, widely known as CZ, said the activity appeared to be a hack. Zhao no longer manages Binance’s platform, but said he expected customers’ funds to be fully covered.
The company said its user funds were “completely safe.”
“Our teams are aware of reports of a potential security issue and are actively investigating. User funds are completely safe. Our security teams are reviewing all relevant information with urgency, and we will provide updates through official Binance channels as soon as we have verified information.” the company states. “Users should remain cautious of scams and should not trust unofficial links, messages, or requests for account information.”
That assurance is important, but it doesn’t replace a technical explanation of how the transfers occurred or independent confirmation of the final impact.
“Our initial investigation suggests this security incident may have started with a compromised DevOps engineer’s laptop. That gave an attacker access to a service container, where they submitted unauthorized withdrawal transactions.” Binance Co-CEO Richard Teng explained.
“To be clear: the attacker did not simply use one engineer’s permissions, and this was not a single “one-click” action. It involved a more complex attack process. Our investigation has not attributed responsibility to any individual.”
I want to speak to you directly about what happened.
— Richard Teng (@_RichardTeng) October 30, 2026
Bottom line – your money is safe, and we're covering every loss.
Our initial investigation suggests this security incident may have started with a compromised DevOps engineer's laptop. That gave an attacker access to a…
Attackers used access from an engineer’s laptop to reach a service container and send unauthorized withdrawal requests. Binance says it has found no evidence that attackers stole any wallet private keys.
Binance also said it had found “additional points of breach” and was still investigating. Co-CEO Richard Teng said the investigation had not identified anyone responsible. After the attack, Binance suspended deposits and withdrawals to carry out security checks, cancelled the permissions linked to the affected address, and began working with blockchain analysis firms and law enforcement to track the stolen funds.
Binance says it will cover all losses using its SAFU fund and its own money, and that customer funds are safe. The company also plans to publish an updated Proof of Reserves once it has completed the recovery work. This commitment does not replace a detailed technical explanation or independent confirmation of the full impact of the attack.
Binance hasn’t named a culprit, but the blockchain analysis firm TRM has. It attributes the attack to TraderTraitor, a North Korean state-backed unit also tracked as Lazarus Group and APT38, and Chainalysis says it’s highly confident in that finding.
Our investigators observed funds stolen by DPRK in last month's Bitget exploit commingling with funds stolen from Binance.
— Chainalysis (@chainalysis) October 30, 2026
We have a high degree of confidence that DPRK is responsible for the $6.4 billion hack of Binance. https://t.co/xj9dQYcbKr
TRM says the attacker moved about $6.36 billion out of Binance wallets on ten blockchains on October 29, most of it in roughly 20 minutes starting at 20:05 UTC. That makes it the largest crypto theft on record, about four times the $1.5 billion Bybit hack of February 2025.
“On October 29, 2026, an attacker moved approximately USD 6.36 billion out of Binance wallets on ten blockchains, most of it in about 20 minutes starting at 20:05 UTC. That makes this the largest crypto theft on record, about four times the USD 1.5 billion Bybit hack of February 2025. Binance has confirmed a security incident and suspended withdrawals on several networks.” TRM said. “TRM attributes the attack to TraderTraitor, North Korea’s elite hacking unit, based on robust on and off-chain intelligence. We make this judgment with high confidence. TRM is tracking the funds and alerting partners through the Beacon Network.”
Freezing the money only went partway. Tether, Circle, Ripple and World Liberty Financial froze about $2.67 billion in stablecoins, and Arbitrum’s Security Council froze 8,426 ETH and 74.6 million ARB, for roughly $2.7 billion in all. But the attacker raced the freezes by selling USDT to market makers and borrowing ETH against USDT on Aave. It now holds more than 420,000 ETH and 18,270 BTC, about $2.4 billion beyond any issuer’s reach.
The early freeze numbers were messy too, Tether and Circle froze approximately $1.79 billion in stablecoins associated with the suspicious transfers in the initial reports. Those amounts describe different moments, and you shouldn’t add them without checking whether they cover distinct assets. A freeze works on tokens that have an issuer to call, and Ether and Bitcoin don’t.
Hot wallets help explain how this type of theft can happen. They store cryptocurrency in systems connected to the internet, allowing exchanges to process withdrawals quickly. But this also makes strong security controls essential. Investigators still need to determine who initiated the transfers, whether they were authorized, whether attackers gained control of the wallets, and whose funds were stolen.
Binance co-founder Changpeng Zhao, who no longer runs the company, said the activity looked like a hack and expected customers to be fully compensated. Large transfers alone do not prove a cyberattack, but the findings that emerged later provided strong evidence of a breach.
Customers also need to be careful. Attackers often exploit the confusion after a major incident by spreading fake announcements, pretending to be support staff, and directing users to fraudulent websites. Use only Binance’s official channels, avoid unexpected links, and never share passwords, authentication codes, or wallet recovery phrases in response to unsolicited messages. Security teams should also watch for phishing emails that use the incident to pressure employees into verifying their accounts.
The lesson goes beyond Binance. A public blockchain records every transaction, but it cannot show who authorized it or how attackers gained access. Blockchain transparency does not guarantee operational security.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Binance)
A South Korea app store fine penalizes Apple and Google $48 million for enforcing coercive in-app payment rules and imposing excessive commission fees.
Related Posts:
The post South Korea App Store Fine Hits Apple and Google appeared first on Daily CyberSecurity.
Researchers set up a fake start-up company to study fraudulent North Korean IT workers.
On October 21, PHP released emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on the CVSS scale. The flaws affect all PHP versions that handle web requests. The vulnerable code dates back to PHP 5.4, released in 2012, and resides in the PHP engine itself rather than in individual applications. Attackers can exploit the flaws to execute code remotely by sending specially crafted HTTP requests, without authentication.
Exploitation attempts increased rapidly after the vulnerabilities became public. Cloudflare researchers reported tens of thousands of attempts within the first 45 minutes, hundreds of thousands in just two hours, and millions by October 22.
Cyfirma reported that a group of North Korea-linked group has identified 216 hosts that may still be vulnerable to PHP2Shell. The operators communicate through a private I2P channel that Cyfirma has monitored since October 22. On October 24, they reported that 216 hosts appeared to be unpatched or only partly protected, earlier than Cyfirma expected.
They are checking the systems from 21 compromised machines. At the time Cyfirma captured the conversation, the operators had already checked about one-third of the targets.
“Two handles active since March 2026, coordinating in a closed I2P channel; staging infrastructure shared in-channel.” states the cybersecurity firm. “Target set and scan nodes. “On 24 October the operators reported 216 unpatched or partially mitigated hosts and named 21 scan nodes; the same addresses were seen performing web-shell tooling and upload-progress session-poisoning attempts.”
The scanning is slow on purpose. Volume stays low, the machines rotate, and any node that shows filtering or rate limiting gets pulled and never reused. That’s why a rate-based alert will probably stay quiet.
Who’s behind it? Cyfirma assesses with moderate confidence a link to the Lazarus family of North Korean groups, based on language, operating style and old habits with PHP web shells and hijacked web servers. It has no shared malware or infrastructure to point to yet, and it admits that a Korean-speaking criminal crew without state backing would fit the same facts. Its confidence in the campaign itself is high.
Government agencies and banks come first. Next in line are logistics, ports, airports and aviation, manufacturing, and online transaction and trading platforms. The countries named are the US, Japan, South Korea, Thailand, Indonesia, Australia, Taiwan, India, Singapore, the UAE, Saudi Arabia and the EU.
Cyfirma has not named any victims or seen the full list of targeted systems. The operators have not announced when they plan to launch attacks, and the researchers have not confirmed that this group has compromised systems on a large scale. Cyfirma gives the campaign an imminence score of 78 out of 100. The operators plan to check all 216 hosts, select the most promising targets, and decide which publicly available exploits to adapt.
The group does not appear to be developing new exploits. Instead, its members use a local AI model to rank public exploit repositories, then test the results manually in a lab. Cyfirma believes this approach could help attackers turn newly disclosed vulnerabilities into working attacks more quickly. However, researchers warn that some proof-of-concept exploits shared online are fake and may contain malware, so downloading and running them can be dangerous.
Technical details leaked on October 20, ahead of coordinated disclosure, and the PHP project shipped fixes on October 21. Apache mod_php with default settings and prefork is the confirmed worst case for 109618, with full unauthenticated code execution. For 109619, PHP-FPM is validated through the upload-progress path.
One correction matters for your temporary controls. Early coverage tied the session upload-progress field to 109618, but PHP’s advisories put it under 109619 only. Disabling upload progress does nothing for 109618, so the two bugs need different stopgaps.
Triggering the bug is easy, but reliable code execution isn’t. The attacker has to land a follow-up request on the same worker and shape heap data into the freed space, otherwise the worker crashes or answers normally. VulnCheck reports working code execution on x86-64 with ASLR enabled against PHP 8.4.10 to 8.4.26, while ARM64 only leaks memory so far.
Short of code execution, attackers have already shown worker crashes, arbitrary file reads through OPcache and a leak of about 67 KB of process memory. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1, 8.0 and 7.4 get only minimal backports, and vendors such as cPanel EasyApache, CloudLinux, TuxCare and Plesk carry their own builds, so confirm coverage with yours.
Anything from PHP 5.4 to 7.3 has no fix, so migrate or isolate it. Restart every worker after patching, because a reload that keeps old workers alive leaves the stale state in place. Isolate anything internet-facing that you can’t patch within hours, starting with Apache mod_php.
If you suspect a host is compromised, capture memory and logs before you patch, since a restart destroys the CVE-2026-109619 state. Then rebuild the host from a trusted image and rotate every secret the PHP worker could reach. Hunt back to October 17, the earliest known exploitation, and use long time windows.
The strongest single signal is a PHP or web server process spawning something it never normally spawns. Application logs will usually show nothing, because the bug fires before application code runs. Look for odd multipart POSTs to endpoints that never take uploads, bursts of worker crashes and memory errors, new PHP files in web roots, and new cron jobs, local users or SSH keys.
Cyfirma includes Sigma, Splunk and YARA content, though it says the YARA set hasn’t been tested on real application code yet. It also lists 21 scan-node addresses, 17 source addresses from October 23 and 15 staging addresses, all defanged. Some scan nodes are described as compromised and may belong to victims, so hunt for prior contact before assuming who owns them.
If you can’t patch yet, the advisory suggests limits such as a low post_max_size and disabling session upload progress for 109619. Cyfirma is clear that none of it replaces patching. The operators’ own selection rule is the most useful detail in the whole advisory, because they dropped every host that showed a fixed version or sat behind heavy filtering. That makes a current version string a cheap filter against you, and for once being boring pays off.
“Hosts still bannering older PHP are the ones the operators kept.” Cyfirma states.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, PHP2Shell)
For ten days, auditors appointed by the Korea Internet & Security Agency (KISA) sat together with us and worked through 80 controls. That is what it took for a company headquartered in the United States, operating a global network serving Korean users, to be certified in South Korea. Cloudflare has now obtained South Korea's Information Security Management System (ISMS) certification under the ISMS-P framework.
For customers in Korea, this is more than a compliance checkbox. It is evidence that Cloudflare's security and privacy program has been examined not only for whether our controls exist, but for how they operate in the context of Korean law, the Korean language, and the particular expectations of Korean regulators.
The most visible result of this work is the Cloudflare account sign-up page. In most parts of the world, the line that sits above the sign-up button reads: "By continuing, I agree to Cloudflare's terms, privacy policy, and cookie policy."
A user signing up from South Korea sees something different. The Korean experience is triggered by the country selected at sign-up and by IP geolocation from within South Korea, and it breaks the same agreement into four separately labeled items, each marked required or optional, each linking to its full text, with an option to agree to all of them at once:
The three required items are hard gates. The sign-up button stays disabled until all three are checked, so there is no path through the form that creates an account without an affirmative action on each one. The optional item governs marketing permission only, and leaving it unchecked has no effect on the account creation (it merely opts the user out of receiving marketing communications).
Itemizing consent on a form we control is straightforward. The difficulty was the sign-up paths that skip that form entirely.
Globally, you can create a Cloudflare account with Google, Apple, or GitHub. Those flows hand the user to an identity provider and return with an authenticated identity, and they never render our own sign-up form, which is precisely where the four consent items live. There is no step in that handoff where we can present three required items, link each to its full Korean text, and require an affirmative action on each before the account exists. The identity provider's screen is not ours to change.
We could either build a separate post-authentication consent gate for one country, or remove the paths that bypass the gate we already had. We chose the second. Social sign-up is not offered in South Korea, so every account created there goes through Cloudflare’s sign-up form, which enforces the required consents.
The country signal is the same one available to any Cloudflare customer. Cloudflare derives a two-letter country code from the client IP address and exposes it on the request, as the CF-IPCountry header at the origin and as request.cf.country inside a Worker. Reduced to its essentials, the branch is a string comparison:
Entrar// Illustrative: the shape of the check, not Cloudflare's own dashboard code.
export default {
async fetch(request) {
// Two-letter country code derived from the client IP.
// Same value as the CF-IPCountry request header.
// Cloudflare's network populates this on the incoming request, so there is
// no geolocation database, lookup service, or extra round trip of our own.
const country = request.cf?.country;
if (country === "KR") {
return renderSignUp({
locale: "ko-KR",
consent: "itemized", // four separate items, three of them required
socialLogin: false, // no path that skips the consent form
});
}
return renderSignUp({ locale: "en-US", consent: "combined", socialLogin: true });
},
};What that does not show is why the country code is not the whole trigger. We document the limits of IP geolocation: it is an estimate rather than an exact science, addresses rotate and change ownership, and it should not be the only signal where the use case is critical to meeting the objectives of a local requirement. A Korean resident traveling abroad, or behind a VPN or a mobile carrier's NAT, may not arrive with a Korean address. So IP-based geolocation decides which form appears by default, but the country a user selects at sign-up overrides that and carries the decision from there. The IP address tells us where a request came from; only the user can tell us where they reside. Keeping those two apart is what makes the consent meaningful rather than presumed.
It is a small feature. It took a country-level product decision, and a change to the account creation path.
ISMS is a detailed, localized certification standard. It covers security policy, access control, authentication and permission management, encryption, incident response, risk management, and disaster recovery, all assessed against how personal data actually moves through an organization's systems, and against Korea's Personal Information Protection Act and its associated regulatory guidelines.
Certification requires an independent audit by an auditor appointed by KISA, a governmental institution affiliated with the Ministry of Science and ICT (MSIT), followed by review from a special committee. It is valid for three years, with an annual audit required to maintain it.
The ISMS certification is primarily established under Article 47 of Korea's Act on Promotion of Information and Communications Network Utilization and Information Protection, etc., with the certification criteria and procedure set out in its Enforcement Decree and in the public notification on ISMS certification issued by MSIT.
Cloudflare is already certified against ISO/IEC 27001, ISO/IEC 27701, ISO/IEC 27017, ISO/IEC 27018 and many other globally recognized frameworks. ISMS does not replace any of them. It is a localization of the same principles, layered with Korean regulatory requirements, and that changes what auditors look for and how they look for it.
The controls in scope started with the review of data flows. We presented detailed data flow diagrams showing every path by which employees could access personal information that Cloudflare collects, processes, and stores. The flows themselves are not Korea-specific. What was different was the form the evidence had to take: the auditors were not willing to work from a narrative description of how data moves, they wanted diagrams they could read and interrogate. For each one, they examined every access control layer and tested its effectiveness, across our internal systems, our public-facing websites, event pages, and the Cloudflare dashboard, covering the full lifecycle of a user's data from first interaction through to destruction. Those diagrams are not published here due to confidentiality.
The audit also scrutinized the language and terminology of our consent collection: the exact wording at sign-up, the structure of each notification, and whether the items were presented separately and clearly. That is the kind of detail the ISMS framework is designed to surface.
Part of the answer is how audit cycles work. An ISMS audit covers a single annual period, and all evidence, documentation, and systems must reflect that period. Our preparation ran past one audit year and into the next, which meant retranslating updated policies for the new audit year, re-collecting and reassessing evidence, republishing an updated privacy policy, and absorbing formatting and design changes our marketing and website teams had introduced in the meantime.
KISA defines the certified scope as a service boundary rather than as an enumerated list of in-scope products. The Statement of Scope submitted to KISA describes that boundary in three parts:
If a customer-consumed Cloudflare product is delivered through that certified service boundary, meaning it runs on the same certified platform, is operated by the same certified teams, and is governed by the same ISMS, it is covered by the certificate. The certificate is held by Cloudflare, Inc.
That is a different shape from the reports most procurement teams work with. A SOC 2 report or an ISO 27001 certificate describes the system it covers and names the services included, so coverage is confirmed by finding the product in that list. The ISMS certificate carries no such list. Coverage follows the delivery path instead, whether or not a product is named anywhere.
For organizations operating in Korea, this gives legal, security, and procurement teams a local assurance benchmark alongside Cloudflare's broader compliance portfolio. ISO/IEC 27001 and SOC 2 demonstrate a general security posture. ISMS reflects Korea-specific legal and regulatory expectations. That distinction matters in third-party risk reviews and in preparing for a team’s own compliance assessments.
Cloudflare’s entry can be found on KISA's public register of certified organizations, which is the independent, verifiable confirmation to cite in a risk review. Broader privacy and data protection material sits on the Cloudflare Trust Hub.
The question that usually stalls a vendor review of Cloudflare is whether a particular product in use is in scope. The certificate does not answer that by name, because it lists no products. It answers by boundary, meaning that the product is in scope if it is delivered through the certified service.
For multinational teams managing security across regions, the certification confirms that Cloudflare's program has been reviewed against local requirements in one of Asia's most important digital markets, not just designed for global scale.
ISMS is not a harder certification than the other assurance audits we go through. It is a more nuanced one. It is built around the regulatory needs of one specific region, and it asks for genuine investment in understanding and embedding those needs, rather than mapping them onto a common control framework.
Going through it made Cloudflare more global, not less. It pushed us to think carefully about what it means to serve users in a specific local context, with local language, local consent expectations, and local data protection requirements, and to put that into how the product behaves rather than only into a document.
That is consistent with what we are working toward: helping build a better Internet for everyone, not just in the regions where regulatory requirements are straightforward, but everywhere.
To learn more about Cloudflare's compliance and assurance programs, visit our Trust Hub.
