- JPCERT/CC says attackers analyzed Android apps to find APIs, then attacked them, and used AI to look for known vulnerabilities.
- A compiled app can reveal how it talks to your servers, so a server that trusts the app to prove identity is exposed.
- Ask your teams whether apps hold embedded keys, whether servers check users themselves, and whether URL-fetching APIs restrict destinations.
The app is a map, not a wall
A mobile app feels like a private door into a company's systems. New findings from Japan's computer emergency response team, JPCERT/CC, show it can work as a public map of those systems instead.
The background is an alert JPCERT/CC put out on October 8, 2026. It concerned a series of break-ins in which several organizations in Japan reported leaked personal and other data. In a follow-up on October 21, the team's infrastructure investigators described what they found on servers the attackers used.
JPCERT/CC says it confirmed that AI helped the attackers hunt for weaknesses that were already publicly known. The break-ins themselves ran through APIs. An API is the interface an app uses to talk to a company's servers. The team also says the attackers went after web services meant for users outside Japan.
JPCERT/CC does not say how much of the work the AI did. It does not name the affected organizations. It does not say where the attackers are based.
How the attackers worked
JPCERT/CC singles out one habit as notable. The attackers took apart Android application packages, known as APK files, to learn which APIs the apps call. They then went after those APIs.
One attack server held evidence of this. It contained analyzed APK files and signs that the matching APIs had been probed for weaknesses, including server-side request forgery (SSRF). Apps aimed at users outside Japan were on that server too.
SSRF works like this. Some APIs fetch content from a web address a user supplies. If the API places no limit on where it will fetch from, an attacker can make the company's own server send requests for them.
JPCERT/CC also found a Python script that looks like an SSRF test. It runs as an HTTPS server and answers certain requests with an HTTP 302 redirect, a reply that sends the caller to another address. A script like this can show whether a target follows redirects wherever they lead.
A second server held several APK files and traces of two tools. One was jadx, which analyzes Android apps. The other was Blutter, an open-source tool for examining Flutter apps. Flutter lets developers build for several platforms from one codebase.
The same server had a folder named apk_extract/. JPCERT/CC says it may have been associated with APK extraction. A filename such as strings_libapp.txt suggests that files may have stored strings taken from native libraries. JPCERT/CC states both as possibilities, not confirmed uses.
Compiled code still gives up its design
Many teams assume a compiled app keeps its inner workings private. JPCERT/CC's appendix points to two public technical write-ups that challenge this. They are examples from other researchers, not findings from the Japanese incidents.
IQCrafter described analyzing a real-world Flutter app in June 2026. The work exposed an embedded RSA private key, the API's authentication mechanism and the logic that signs requests. IQCrafter reports that it reproduced the signing. A standalone Python client then reached the production API without the legitimate app. NerdzLab describes similar techniques for examining API keys, secrets and class structures.
The lesson here is plain. Shipping an app means distributing a copy of your client to everyone, including people with bad intent. Anything inside it can be studied, including how it talks to your servers. If the server relies on the app to prove who is calling, it is trusting code that the caller controls.
A wider toolkit on a separate server
JPCERT/CC also examined a third server, which it says is not directly related to these attacks. It held files for targeting web applications, MySQL databases, Jenkins servers and email gateways. The team saw signs of attempts to get past EDR, the security software that monitors laptops and servers. It also saw web shells, which are hidden remote-control pages, believed to be running inside a targeted network. JPCERT/CC says this suggests the attackers wanted to reach internal networks.
Treat that as context, not a proven chain of events. The report does not say the app-based attacks led to these internal intrusions.
What to ask your team
JPCERT/CC lists four measures. Each becomes a question for your next leadership meeting.
First: do any of our apps contain private keys or long-lived credentials used for API authentication? JPCERT/CC says they should not. Second: does the server check who the user is and what they may access? Or does it lean on request signing and code obfuscation inside the app? JPCERT/CC says those two are not enough alone.
Third: do we apply rate limits and watch for unusual requests, assuming something other than our app may call the API? Fourth: for any API that fetches outside URLs, do we restrict the destinations and check redirect targets too?
One more question follows from the report. Do we know every app we have published, including those aimed at customers in other countries? One attack server held apps for users outside Japan, and JPCERT/CC says the attackers also targeted web services abroad.
Assume the app will be opened and read. Build the server so that reading it gives the reader nothing to use.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: JPCERT/CC.
