On 6 November, NHK published replies from Qilin, a Russia-linked ransomware group that has been attacking companies in Japan and abroad. Asked why it targets Japanese firms, the group pointed to vulnerabilities in their systems that are left unfixed. It answered NHK's questions in English.
It's an uncomfortable answer, not least because the numbers support it. Trend Micro counted 600 publicly disclosed cases of unauthorised access at Japanese companies and local governments between January and September 2026, which is already more than the 593 recorded across the whole of 2025. Most explanations for the rise come back to AI, and to two quite different things it has changed.
Two things AI has changed
The first is the one most people would expect. AI can now do much of the work that used to take a skilled attacker's time: scanning for vulnerable services, testing them, and repeating the same attempt across thousands of targets at once. In October it was also AI that uncovered two critical flaws in PHP, the programming language behind a large share of the world's websites, which had sat unnoticed in the software for years. Defenders can use the same tools, of course, but an attacker only needs to find one site that hasn't been updated.
The second is less obvious, and it matters more for Japan than almost anywhere else. Until recently, the Japanese language did a surprising amount of defensive work. A phishing email from someone who couldn't write Japanese was easy to spot, a ransom negotiation conducted in broken Japanese was hard to carry off, and an admin panel in Japanese was slow going for anyone who couldn't read it. AI has removed most of that friction, so an attacker can now write convincing business Japanese, translate replies as they arrive and work through Japanese-language systems without knowing a word of the language.
What the language barrier used to do
For years Japanese companies were attacked less than their counterparts in English-speaking markets, and the language was a large part of the reason. Nobody designed that protection, so nobody had to maintain it, and it hid a problem. Because attacks were rarer, many companies have little practical experience of responding to one, and plenty of websites were built, launched and then left alone on the reasonable assumption that nobody was looking very hard.
The protection was only ever partial, which is why "somewhat" belongs in the title. Japan has dealt with serious attacks before, including state-backed espionage campaigns and waves of DDoS attacks from pro-Russian groups. But for the opportunistic attacker scanning the internet for easy targets, Japan used to be more trouble than it was worth, and that is the part that has changed.
Where your website fits
Most of the attacks in the news reach companies through their internal networks, by way of a phishing email, a stolen password or an exposed remote-access tool. A website is a different kind of risk, but it is the most public part of a company's systems and the easiest to scan, which makes it one of the first things an automated tool will try.
October's PHP alert showed how exposed many sites are. Once the vulnerabilities were disclosed, Japanese government agencies and companies including Nomura, MUFG and East Japan Railway temporarily suspended some online services while they patched. Those are organisations with their own security teams. A smaller company running an older WordPress site, with a theme and a dozen plugins that nobody has updated since launch, is in a harder position, because older sites often put off upgrading PHP in case the update breaks something that currently works.
Most of the sites we look after are built with Next.js rather than PHP, but the same thing happens there. Last December a critical flaw known as React2Shell, in the React Server Components that Next.js relies on, allowed attackers to run code on affected sites without logging in, and it was being exploited within days of disclosure. We updated our clients' sites as soon as the patches were released. Vercel, which hosts them, went a step further and began refusing any new deployment that still contained a vulnerable version of Next.js, so a site simply couldn't be redeployed until it had been patched. That kind of safeguard is only useful if someone is there to act on it, which is most of the argument for maintenance in a sentence.
What a migration changes
A migration is a chance to remove most of those moving parts at once. When we rebuild a site, the content lives in Sanity, which is hosted and maintained by Sanity, and the website itself is built with Next.js and hosted on Vercel. That leaves far fewer things for an automated scanner to find: no plugin directory to probe, no forgotten theme files, and no server of ours running an old version of PHP.
It also changes who notices when something goes wrong. A vulnerability like October's PHP flaw becomes something we check against your site and fix, instead of something you hear about on the news and then try to work out whether it affects you.
For your technical lead: sites run on Next.js with content in Sanity, deployed to Vercel, which adds platform-level protections such as firewall rules for known exploits and the deployment block described above. Dependencies are updated monthly, and immediately when a critical advisory lands. If you're curious how we structure the content side, our series on multilingual websites with Sanity covers it in more detail.
What ongoing maintenance covers
A migration only helps if someone keeps looking after the site afterwards, because new vulnerabilities will keep turning up, and AI is making sure they turn up faster.
Our maintenance is a monthly service that covers your hosting and applies security updates every month, and we keep watch on current threats and advisories that affect the tools your site is built with. When something critical does come up, we respond and patch it the same day. Uptime is checked around the clock, and detailed logging means that if anything unusual happens we can see exactly what it was and when, instead of piecing it together afterwards.
What a website can't fix
The limits matter too. A well-maintained website closes one door, but most of the ransomware behind this year's headlines came in through others: phishing, stolen passwords and exposed remote-access tools. Those need phishing-resistant multi-factor authentication, staff who know that fluent Japanese no longer means an email is genuine, and for many companies a security specialist as well. For smaller companies, IPA's guide to handling website vulnerabilities (in Japanese) is a sensible place to start.
If your site hasn't been touched since it launched, the website is still the easiest of those doors to close, so get in touch and we can talk through what a migration and ongoing maintenence would look like for you.
