AI-Discovered Vulnerabilities: PHP, ARTEX and October's Cyberattacks
Multiple security breaches were reported in South Korea and Japan in October 2026. Most breaches involved systems outside organizations' core services, including internet-facing web services, backend APIs for mobile apps, and third-party SaaS platforms. During the same period, vulnerabilities that could allow unauthenticated remote code execution were disclosed in widely used software, including PHP, Node.js, and GitLab. Reports also continued to emerge that AI agents, including ARTEX, had been used in actual breaches.
In South Korea, breaches were first reported at commercial banks in late September, followed by incidents affecting savings banks, capital companies, mutual financial institutions, virtual asset service providers, and insurers. Data leaks were also confirmed outside the financial sector, affecting an enterprise accounting software provider, a large church, universities, and a franchise company. Japan also saw similar large-scale disclosures, some involving millions of personal data records. A Japanese government agency identified attacks on backend servers using information obtained from analyzing publicly available apps as one of the main causes of the breaches.
This trend was not limited to South Korea and Japan. During the same period, breaches involving third-party services and internet-facing websites were also reported in the United States, Europe, and South America, along with large-scale automated attacks using AI agents.
The AhnLab SEcurity intelligence Center (ASEC), examined the reported points of compromise including its analysis reports, public reporting, announcements by relevant organizations, and reports from other security companies and identified recurring attack patterns, and compiled prevention and response measures.
This article is a summary of the report published by ASEC. The full report is available on the ASEC Blog.
Note: The causes of most individual incidents remain under investigation. Based on public reporting, affected organizations are identified only by industry.
Financial-sector breaches reported in South Korea
Reports of breaches in South Korea's financial sector began with a commercial bank in late September, followed by disclosures involving other financial institutions in subsequent weeks. As of October 14, financial authorities had identified security incidents at 16 financial companies, including banks, savings banks, capital companies, mutual financial institutions, electronic financial service providers, online investment-linked financial service providers, and virtual asset service providers. Approximately 100,000 personal data records were confirmed to have been leaked. However, the volume of leaked data is considered relatively small given the number of financial companies affected.
The attacks did not target the banks' core systems for processing deposits and transfers. According to publicly available information, the points of compromise were ancillary systems connected to the main services, such as a lookup service for loan brokers, an internal sales support system for employees, and an external mutual aid webpage.
| Category | Point of compromise | Publicly disclosed information |
|---|---|---|
| Financial firm A | Lookup service for loan brokers | Attackers bypassed standard authentication and repeatedly entered lookup values, exposing loan-related information belonging to approximately 25,000 people |
| Financial firm B | Employee sales support system, or ODS | Abnormal access occurred on a system separated from internet and mobile banking, exposing information belonging to 89 people |
| Financial firm C | External mutual aid webpage | The organization did not discover the breach until two days after the attack |
Table 1. Major breaches and points of compromise in South Korea's financial sector
Evidence of ARTEX, an autonomous AI penetration testing tool, was found in the attacks on the financial sector. South Korean security companies first identified ARTEX-related strings on a web server used in the attacks. CrowdStrike later obtained ARTEX configuration files and work logs from an AI coding tool in an exposed folder on the attacker's server. Analysis indicated that the attacker had connected ARTEX to several large language models (LLMs), including DeepSeek, GLM, and Grok. The attacker's identity and nationality have not been confirmed.
Security Breaches in Other Sectors
Organizations outside the financial sector were also affected during the same period. The victims included an enterprise accounting software provider, a large church, a coffee franchise, universities, and education offices. Despite the differences among these organizations, the points of compromise were all outside their core business systems. The reported points of compromise included an employee VPN account, an external backup solution, a temporary file left in the cloud, a portal, and cloud accounts used for education.
| Category | Point of compromise | Publicly disclosed information |
|---|---|---|
| Enterprise accounting and ERP software provider | Employee VPN account and external backup solution | Attackers used a VPN account to gain unauthorized access to a development server. There were also indications that some encrypted data had been exfiltrated by exploiting a vulnerability in the backup solution. The government classified the incident as serious and formed a joint public-private investigation team |
| Church | Church information system | Data containing names, dates of birth, and other information belonging to approximately 850,000 church members was leaked |
| Coffee franchise | Temporary data file left in the cloud | Approximately 2.76 million records were exposed during unauthorized access intended for cryptocurrency mining. The exposed data was stored in a temporary file created during an earlier service redesign |
| University | Portal service | Student numbers, contact information, and email addresses belonging to approximately 10,000 current students, graduates, and others were exposed |
| Education offices | Cloud accounts used for education | More than 110,000 accounts across six education offices were compromised |
Table 2. Major breaches and points of compromise outside South Korea's financial sector
Data breaches involving web systems and third-party services in Japan
Japan also saw numerous large-scale data breach disclosures. According to figures compiled by Japanese security company Macnica, Japanese organizations had disclosed 119 personal data leaks through web systems as of October 6, 2026. This had already exceeded the 84 cases reported throughout 2025 and the 62 reported in 2024. Of the 119 cases, 81 occurred after July.
Japanese authorities also reported attacks targeting backend systems through publicly available apps. On October 13, Japan's National Institute of Information and Communications Technology (NICT) described this technique as an App-to-Backend (A2B) attack. In these attacks, threat actors analyze a publicly available Android app to identify the servers it connects to and understand its API structure. They then exploit server-side vulnerabilities. The main vulnerabilities targeted include server-side request forgery, remote code execution, SQL injection, and IDOR or BOLA.
Even when an app has no vulnerabilities, weaknesses in its server-side APIs can lead to a data leak. On October 8, JPCERT/CC also identified scanning for known vulnerabilities, abuse of administrative APIs through app analysis, exploitation of the SQL injection vulnerability CVE-2026-72898 in the Metabase business intelligence tool, and web shell installation as major attack types. However, neither organization named the affected companies, so no specific incident can be definitively classified as an A2B attack.
| Category | Point of compromise | Publicly disclosed information |
|---|---|---|
| Software sales company | Member information lookup API | The API was used for four days, potentially exposing up to approximately 22.52 million member records, including passwords |
| Major discount retailer | App and online store servers | Attackers gained access by abusing functionality in software used to provide the services, potentially exposing information belonging to up to approximately 1.73 million people |
| SaaS company | API servers for an email delivery SaaS platform | Commands were executed on two API servers, resulting in the exfiltration of information on all subscribers and recipient lists belonging to some customers |
| Japanese subsidiary of a food brand | Third-party e-commerce platform | Attackers exploited a software vulnerability on a service provider's server, exposing approximately 3.14 million records |
| Department store group | Reservation site leading to the customer management system | Attackers accessed the customer management system through the reservation site, exposing approximately 1.26 million records belonging to nearly all members using the group's shared ID |
| News platform | Administrative tool used for business operations | A vulnerability in the tool may have exposed email addresses and other data from up to 323,000 records |
| E-book service | System log files | In addition to 319 records from the member database, information retained in log files may have exposed up to approximately 4.2 million records |
| Securities company | Third-party FAQ system | A breach of an external inquiry management service may have exposed information belonging to approximately 110,000 people |
| Cloud provider | Cloud infrastructure | A ransomware attack disrupted services for 495 customers, including local governments and companies |
Table 3. Major security incidents and points of compromise in Japan
Several of the reported incidents involved external services or supporting systems. In the department store group incident, attackers accessed the customer management system through a reservation site. In the e-book service incident, information retained in log files accounted for a much larger potential exposure than the records reported from the member database.
ARTEX was also identified in Japan. On October 19, Japanese security company GMO Cybersecurity by Ierae announced that it had found evidence of ARTEX in infrastructure used to attack organizations in Japan. Eight of the companies it identified as targets disclosed data leaks in September and October. The company names were not released, and there is no evidence that the attacks were conducted by the same actor responsible for the South Korean incidents. The available evidence links ARTEX to attack activity in both countries but does not establish a common attacker.
Evidence of ARTEX use and autonomous attack capabilities
Attacks in which AI agents independently conduct reconnaissance, search for vulnerabilities, gain access, and install web shells are now being confirmed in actual breaches.
ASEC recently reproduced ARTEX in a separate test environment to determine how far it could proceed with an autonomous intrusion. Given a short instruction such as "Break into the target," ARTEX found a web server's file upload function and used a web shell to execute a program without human intervention. In an environment where Apache ActiveMQ was exposed, it exploited the known vulnerability CVE-2023-46604 for initial access and proceeded to execute remote commands on four internal hosts.
These cases reveal a significant shift in the economics of cyberattacks. Repetitive work that previously required skilled personnel, including vulnerability discovery, testing attack paths, modifying payloads, and retrying after failures, can now be assigned to agents that operate continuously for hours. Open-weight AI models can be easily combined with freely available agent frameworks, making cyberattacks that once required advanced technical expertise accessible to virtually anyone. The cost of carrying out such attacks is also falling rapidly.
Reviewing external attack surfaces to defend against AI-assisted attacks
Preventing AI-assisted attacks starts with knowing exactly what an organization exposes to the internet. Attackers are using AI agents to scan external attack surfaces and identify potential entry points. Defenders must therefore reassess their assets from the same perspective. Security teams should review less frequently monitored assets, particularly ancillary services connected to primary services, event pages, administrative tools, and APIs called by apps.
| Area | Review items |
|---|---|
| Internet-facing asset management | Create a complete inventory of internet-facing websites, APIs, administrative pages, and remote access points, and assign an owner to each one. Block external access to unused services and test servers |
| App backend APIs | Assume that any app can be analyzed. Verify server-side authentication and object-level authorization for every API request, and do not embed API keys or credentials in apps. Limit the number of queries per user and detect abnormal repeated queries |
| Administrative and business tools | Prevent direct external access to administrative pages, business intelligence tools, and sales support systems. Where external access is unavoidable, restrict access by IP address and require multifactor authentication. Minimize the permissions these tools have to read business databases |
| Third-party SaaS and supply chain | Inventory the data held by service providers and the access permissions connected to them. Regularly review cloud permissions granted to third-party apps, including OAuth consent. Include breach notification procedures in contracts with service providers |
| Accounts and authentication | Apply phishing-resistant multifactor authentication to VPN, remote access, and business cloud accounts. Detect sudden increases in failed logins and access from unusual locations to defend against attacks using account information obtained elsewhere |
| Patching and end of support | Establish a separate process for internet-facing components such as PHP, GitLab, Node.js, and DNS servers, with the goal of responding on the day a vulnerability is disclosed. Develop replacement plans for systems that are no longer supported and reduce their external exposure until they are replaced |
| Data minimization | Delete member data that has exceeded its retention period, information on former employees, temporary development files, and logs containing personal data. Removing unnecessary stored data reduces the amount of information that could be exposed in a breach |
| Detection and monitoring | Collect logs from peripheral access points at the same level as logs from core systems and include them in around-the-clock monitoring. Maintain detection rules for post-compromise activity, such as a web server executing a shell or download tool |
Table 4. Preventive review items focused on peripheral access points
Organizations also need to account for the speed of AI-assisted attacks. In one case, less than three hours elapsed between initial targeting and privileged access. Manual reviews and patching processes that take several days may not be fast enough to respond to attacks that progress within hours. Organizations should prepare automated response measures in advance, including the proactive deployment of web application firewall rules and the immediate blocking of exposed assets. AI-assisted vulnerability assessments can also help security teams identify weaknesses in internet-facing systems.
More detailed analysis of these attacks and additional prevention and response measures are available in the full report published on the ASEC Blog.
Read the ASEC BlogReference: AhnLab threat analysis
PHP vulnerabilities
- Part 1.Two Critical PHP Vulnerabilities Prompt Urgent Security Updates
- Part 2. AhnLab Analyzes 100 GitHub Repositories Following PHP Vulnerability Disclosure
- Part 3. PHP2Shell Attacks: Reproducing the Exploit and Detecting Threats with AhnLab EDR/XDR
ARTEX
- AI Lowers the Barrier to Cyberattacks: Our Tracking of ARTEX Infrastructure
- ARTEX v2: AI Penetration Testing and Infrastructure Analysis
- Tracking ARTEX Infrastructure: Signs of Real-World Cyberattacks
- AhnLab