PHP2Shell in Asia: How Korea, Japan, Singapore and India Responded

South Korea raised its private-sector cyber crisis alert from Interest to Caution at noon on 22 October over PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Japan's prime minister asked site owners on X to patch that night. Singapore and India issued critical advisories. If you run PHP in Asia, install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart workers, then check logs.

Europe's response, covered in our post on governments taking websites offline over PHP2Shell, was mostly about public bodies pulling their own sites. Asia's response looked different. South Korea used a formal national alert system and pushed instructions to tens of thousands of registered security officers. Japan's head of government spoke directly to site operators at 21:55 local time, an hour before the fix, and banks, airlines and telecoms paused web services the next morning. Singapore and India stayed with advisories.

This post sets out what each agency actually published, in its own words where it matters, with our translations. For the flaws themselves, read our PHP2Shell explainer. We do not repeat the bug mechanics here and we give no exploit details.

Why the timing hit Asia differently

PHP's advance notice on php.net scheduled the security release for 21 October at 14:00 UTC. In Seoul and Tokyo, both on UTC+9, that is 23:00 on a Wednesday night. Japan's IPA said exactly that in its pre-alert: the release was planned for 23:00 Japan time. CERT-EU's advisory records the fixes as released at 13:30 UTC, which is 22:30 in Seoul and Tokyo.

So European teams got the patch mid-afternoon with staff at their desks. Korean and Japanese teams got it near midnight, after a day of leaked details and public proof of concept claims. That explains much of what followed: Japan's evening messages telling people to prepare for a night patch, the wave of precautionary maintenance windows that started around 20:00 JST, and Korea's formal alert the following noon once the first night was over.

What changed since the first reports

The picture on 22 October was not the picture on 20 October. Four things moved.

• Exploitation claims grew, but agencies still disagree. Amazon Threat Intelligence wrote on 21 October that PHP2Shell is "now being broadly exploited in the wild" and that its honeypots saw a first attempt on 17 October, four days before disclosure. Singapore's CSA reports "widespread exploitation attempts". India's CERT-In says multiple reports confirm large-scale exploitation. KISA says attack attempts are being reported, mainly by overseas security firms. JPCERT/CC lists indicators to check but does not confirm attacks in Japan. CISA said it had not observed exploitation when it published on 21 October.
• Attacks were reported against Japanese servers. The Yomiuri Shimbun reported that Trend Micro had detected attacks exploiting the flaw against multiple servers in Japan by the morning of 22 October, and that it was unknown whether any caused damage. Chief Cabinet Secretary Kihara told the morning press conference that the government had received no damage reports so far.
• Korea moved from advisory to alert. KISA posted a standard update notice on 21 October. On 22 October it added eight response rules for companies, and the Ministry of Science and ICT (MSIT) raised the private-sector alert level.
• The US position is firmer than first reported. NBC News had reported that CISA recommended patching but not going offline. CISA's own alert page now says organisations that cannot update immediately, or that still run PHP 8.1 or earlier, should take PHP-based systems offline until patched. We cannot tell from the page whether that line was there at first publication.

South Korea: from KISA notice to national alert

The alert level and what it means

South Korea runs a four-step private-sector cyber crisis alert: 관심 (Interest), 주의 (Caution), 경계 (Alert) and 심각 (Severe). Hankyung and Aju Business Daily both report that MSIT raised the level from Interest to Caution effective 12:00 noon KST on 22 October, after a crisis assessment meeting with KISA. ZDNet Korea's report says "오전 12시", which can read as midnight, but the other outlets say noon and MSIT's press release was published the same day, so we treat noon as correct.

MSIT's press release on the government briefing portal korea.kr is titled, in our translation, "MSIT urges urgent security updates and technical measures for the web development language PHP security vulnerability." Its body is in an attached file we could not read, so the details below come from Korean press coverage of that release.

Caution is the second of four steps. It is not a shutdown order. According to Hankyung and Aju, it triggered:

• more incident response staff and emergency dispatch teams on permanent standby,
• urgent distribution of security measures to registered organisations,
• ongoing monitoring of attack trends with domestic and foreign security firms.

Who was told

The counts differ between outlets, and we report both.

The C-TAS figure is the clear conflict. One of the two numbers may refer to a different subset, but we could not confirm which from MSIT's own text.

What the minister said

Deputy Prime Minister and Science and ICT Minister Bae Kyung-hoon said, per Hankyung, that the flaw could affect many Korean websites and that, with attack code already public, the response was "매우 시급한" (very urgent). ZDNet Korea adds that he said the usual patch cycle of several days is not enough, and that automated blocking and WAF rule deployment are essential.

The National Security Office meeting

Aju Business Daily reports that the National Security Office held an emergency civil, government and military cyber security meeting on 22 October, chaired by Song Ki-ho, the office's third deputy director. Director-level officials from MSIT, the Ministry of National Defense and the National Intelligence Service attended and reviewed PHP use and patch status. Song asked everyone to finish the work "원팀으로" (as one team). Per Aju, he also said attack attempts had already been reported overseas.

MSIT's alert covers the private sector. We could not find a separate public-sector notice from the National Intelligence Service's National Cyber Security Center, so do not assume a public-sector level changed too.

KISA's two notices

KISA, which also operates KrCERT/CC, published two notices on its 보호나라 (Boho) portal.

21 October, notice 72227, "PHP 제품 보안 업데이트 권고" (PHP product security update recommendation). A standard update notice from KISA's Vulnerability Management Center. It classifies CVE-2026-109618 as Improper Handling of Exceptional Conditions and CVE-2026-109619 as Use After Free, lists versions below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as affected, and says PHP 8.1 and earlier have lost official security support and should be upgraded. Contact is the KISA cyber complaints centre on 118.

22 October, notice 72230, "PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙" (Enterprise security response rules for the PHP2Shell vulnerability). This one is pinned at the top of KISA's notice board and is the most detailed government guidance we found anywhere in Asia. It says the details leaked before the update, that attack attempts are being reported mainly by overseas security firms, and that a successful attack can lead to webshells, customer data theft, defacement and movement into internal networks. It also warns that patches can break compatibility, so test before applying.

Its eight rules, in summary and our translation:

1. Find every PHP you run. Check every internet-facing site and system, including outsourced builds, abandoned sites, event and test servers and admin pages. Base the check on servers actually running, not the asset list. Check network device management screens, Windows installers that bundle PHP, and Docker images separately.
2. Update and restart. Install 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or the distro or vendor equivalent, internet-facing servers first. Restart every PHP runtime: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. KISA's line is blunt: "재시작하지 않으면 메모리에 남은 이전 버전이 계속 동작해 여전히 취약" (without a restart, the old version keeps running in memory and stays vulnerable). Redeploy containers from new images. Note that php -v can differ from what the web service uses, and distro packages may keep the old version number after patching, so check the changelog for the CVE.
3. Move off 8.1 and older. No official update exists. KISA also notes that 8.2 loses security support on 31 December 2026 and recommends 8.3 or later. As a stopgap, use distro or LTS vendor patches, or the source patches PHP published for 7.4, 8.0 and 8.1. If none apply, use rule 4, and if that fails, consider blocking external access or suspending the service.
4. Temporary measures if you cannot update today. Limit request size in front of PHP at the WAF, web server or proxy, including requests with no declared size. Block multipart uploads where the service does not need them. Make sure WAF rules are current. Apply PHP's temporary settings and restart every PHP process (the exact values are in the Technical details section below). These do not fully block attacks.
5. Check logs after updating. Review everything from 20 October, the leak date, and earlier if possible. Look for unusually large requests to PHP pages followed by HTTP 500 errors, unexplained PHP restarts, segfaults or out-of-memory errors, web server processes running sh, bash or download tools, new or changed PHP files in web, upload and temp directories, scripts injected into home or payment pages, and new outbound connections to unknown addresses.
6. Rotate important credentials. Passwords, tokens and API keys in server memory may have leaked. For servers exposed before patching, change database passwords, API keys and admin passwords. For servers with signs of compromise, this is mandatory.
7. If you are breached: isolate by cutting external network access without powering off or restarting; report through Boho's incident report page; preserve logs, process lists and network connections before any update or restart, because a restart erases attack traces in memory; then update, remove webshells and rotate credentials.
8. Do not run PoCs of unknown origin. Many circulating PoCs are fakes that hide malware. Judge exposure by version checks and log review. If analysis is essential, do it in an environment separate from the business network.

Rule 7 is worth pausing on. Most Western guidance says patch and restart immediately. KISA says that if you already suspect compromise, capture memory evidence first, then restart. Both are right for their case: restart fast if you are clean, preserve first if you are not.

The privacy regulator's angle

The Personal Information Protection Commission (PIPC) issued its own press release on 22 October urging operators of personal data systems to take preventive steps. Per Aju Business Daily's summary, PIPC asked them to:

• restrict direct internet access to database admin tools,
• give web service accounts the least database privilege they need,
• check for abnormal access such as bulk lookups or exports of personal data,
• confirm whether outsourced and contracted vendors' systems use PHP, and what they have done.

That last point is the one Western advisories mostly skipped. Many Korean public and commercial sites are built and run by outside agencies. PIPC put the duty to check on the organisation that holds the data.

Why Korea took it personally

ZDNet Korea and other outlets note that WordPress and Gnuboard (그누보드), a PHP board and site builder widely used in Korea, both run on PHP. Small businesses and schools often run these on shared hosting where the customer never touches the PHP version. That is why KISA's guidance and MSIT's coverage both tell hosting customers to ask their provider directly whether the patch is applied.

The Yonsei University breach: confirmed, but not linked

Yonsei University confirmed on 22 October that personal data of about 10,000 people leaked from its portal service, according to Hankyung and the Seoul Shinmun. Per the Seoul Shinmun, the university said unauthorised external access occurred in two windows, 20 October from 19:41 to 19:43 and 21 October from 10:04 to 10:11 KST. Exposed data included student and staff ID numbers, names, mobile numbers, email addresses, identity codes, last login IP addresses and some system administration information. The university said resident registration numbers, foreign resident numbers and passport numbers were not included.

The university said it blocked the access path and the attacker's IP, reviewed its systems, notified the PIPC, KISA and the Ministry of Education, and, per Hankyung, referred the case to investigators.

None of the reports we read names PHP, PHP2Shell or any vulnerability as the cause. The first access window also predates the PHP release. Do not treat this breach as a PHP2Shell case unless the university or investigators say so. We include it only because it was widely reported in Korea on the same day as the alert, and readers will see the two stories side by side.

Japan: a prime minister's post at 21:55

Government messages

IPA pre-alert, 21 October. Japan's Information-technology Promotion Agency asked organisations to watch PHP and vendor announcements, inventory PHP in the programs and sites they build and run, check products for embedded PHP, and be ready to patch fast. It said it had seen websites still running end-of-support PHP and that attackers may move quickly. At that point IPA said it had not confirmed attacks.

Prime Minister Sanae Takaichi, 21 October, 21:55 JST. Impress Watch dates the post to 21:55; ITmedia says just before 22:00. Takaichi opened with "今夜に対応して頂きたい大至急のお願い" (an urgent request we ask you to handle tonight). She asked operators to check whether their public sites use PHP and to prepare to apply the patch due at 23:00 JST as fast as possible. If patching quickly is hard, she said, temporarily stopping a website is one effective way to reduce risk. ITmedia called it unusual for a prime minister to address a specific software flaw directly, and reported that engineers welcomed it because it reaches executives.

National Cybersecurity Office (NCO), 21 October, late evening. The NCO, Japan's cabinet-level cyber office, posted similar guidance on X, per Impress Watch and the Yomiuri Shimbun. The Yomiuri adds that the NCO plans to inspect government websites and that the Tokyo Metropolitan Police Department also urged action on X on 21 October. We could not load a dated NCO notice on its own website.

JPCERT/CC, 22 October, JPCERT-AT-2026-0033. JPCERT/CC's alert says PHP is widely used in Japan and asks users of affected products to "速やかに対策の適用および侵害有無の調査を実施してください" (promptly apply countermeasures and investigate for compromise). It was revised the same day to reword its compromise investigation section. Details are in the Technical details section.

JVN, 22 October, JVNVU#99905564. The vulnerability note run jointly by JPCERT/CC and IPA lists the same fixed versions. Its vendor list already shows one Japanese vendor, Soliton Systems, stating that it has affected products. Expect that list to grow as appliance makers check their embedded PHP.

IPA alert, 22 October. IPA's full alert, which names the pair "PHP2shell", adds Wiz's view that PHP 5.4 and later are affected by at least one flaw. Its most distinctive advice is aimed at owners of old sites: until you finish updating or migrating, "脆弱な状態での運用を放置せず" (do not leave the system running in a vulnerable state). IPA asks owners to judge whether the site still needs to exist, whether they have the people and budget to maintain it, and to consider migration, reduced features or retirement.

Chief Cabinet Secretary, 22 October morning. Kihara said, per the Yomiuri, "今のところ、関係する被害の報告は受けていない" (so far we have received no reports of related damage).

What Japanese organisations did

Japan's private sector went offline far more widely than Korea's. All of this is from news reporting; we did not verify each company's notice.

The Japanese Bankers Association said on 22 October that it had confirmed "現時点で影響がない" (no impact at present) on the online system linking nearly all domestic financial institutions, per Jiji Press. Jiji also reported no confirmed unauthorised access at the regional banks so far. As in Europe, every report we read describes these pauses as precautionary.

Singapore: CSA alert AL-2026-151

The Cyber Security Agency of Singapore published "Critical Vulnerabilities in PHP (PHP2Shell)" on 21 October and updated it on 22 October. The alert number AL-2026-151 comes from the page address; the page itself does not print it.

CSA's alert is short and firm:

• It says the flaws affect all versions of PHP, broader than the vendor's list of supported branches.
• Both CVEs carry CVSS v4.0 9.2, and both allow unauthenticated remote code execution.
• It reports "widespread exploitation attempts" and multiple PoC exploits.
• It asks administrators to update immediately, follow PHP's temporary measures if they cannot, find every system running any PHP version with internet-facing systems first, and check web servers for PHP used by third-party applications even where the main site is not PHP.

CSA does not recommend taking sites offline. We found no reporting of mass precautionary shutdowns in Singapore.

India: CERT-In CIVN-2026-0510

CERT-In, India's national CERT under MeitY, issued vulnerability note CIVN-2026-0510, "Critical remote code execution vulnerabilities in PHP", originally on 21 October and updated on 22 October. It rates the issue CRITICAL, lists the same four version lines as affected, and targets all organisations and individuals using PHP.

CERT-In describes the flaws as memory corruption and improper resource control, triggered by a specially crafted request. Its strongest statement is about exploitation: it says multiple reports confirm large-scale exploitation in the wild, and it tells users to "patch urgently". The solution section points to the php.net advisory for updates and mitigations.

Two context points for Indian organisations. If you find a compromise, CERT-In's incident reporting directions apply. And this landed in the same week as CERT-In's advisory on AI agents, which we cover in AI found vulnerabilities: PHP2Shell and PwnEscape. We found no reporting of Indian government sites going offline.

Asia and Europe side by side

Three differences stand out. Korea used standing machinery: the alert level system, the CISO registry and C-TAS already existed, so one decision reached tens of thousands of organisations the same day. Japan's response was public and top-down, and the shutdowns that followed were mostly in companies rather than government. Singapore and India used stronger exploitation language than CERT-EU or JPCERT/CC, yet neither recommended going offline, and we found no reports of precautionary shutdowns there.

Technical details

All values below come from the fetched primary sources named in each row.

The vulnerabilities

JPCERT/CC and JVN do not print a CVSS score on their pages.

Affected and fixed versions

Advisory index

None of the Asian agency pages we read gives a time of day for its own publication.

Temporary settings, as KISA and PHP list them

These close specific paths only. PHP, KISA, JPCERT/CC and IPA all say updating is the only real fix.

; Set in php.ini, the FPM pool or server config, then restart every PHP process.
; Do not rely on ini_set() or .user.ini.
session.upload_progress.enabled = 0
memory_limit = -1            ; as an admin value, e.g. php_admin_value in the FPM pool
post_max_size = 8M           ; 32M if uploads are needed
upload_max_filesize = 4M     ; keep below post_max_size (example value)
fatal_error_backtraces = 0   ; PHP 8.5 only

PHP and CERT-EU add: do not use RLIMIT_AS or RLIMIT_DATA; use a container or cgroup memory limit instead.

Indicators to check

JPCERT/CC (JPCERT-AT-2026-0033). It warns that finding none of these does not prove no attack happened.

• PHPSESSID cookies with unusually long or malformed values in past HTTP responses.
• Suspicious multipart/form-data requests, especially near PHP memory limit errors or HTTP 500 errors.
• Unexpected or frequent PHP worker restarts or crashes.

KISA (notice 72230). Large requests to PHP pages followed by HTTP 500, unexplained restarts, segfaults or out-of-memory errors, web server processes spawning sh, bash or download tools, new or modified PHP files in web, upload or temp directories, injected scripts on home or payment pages, new outbound connections. Review from 20 October onward.

Amazon Threat Intelligence. POST requests whose form uploads contain the string PHP_SESSION_UPLOAD_PROGRESS. Amazon listed these addresses, all on shared anonymisation infrastructure, and recommends investigating activity from them rather than blocking them outright:

Amazon also says to start investigations from 17 October, not the disclosure date. That is three days earlier than KISA's 20 October starting point. Use the earlier date.

Trend Micro (KA-0024789), useful if you run its products: IPS rule 1012749, TippingPoint filter 48514, network detection rule 6021.

Reporting channels

Timeline

Times are local where the source gives them, with UTC in brackets. KST and JST are both UTC+9.

What to do now: a checklist for teams in Korea and Japan

This merges KISA's eight rules, JPCERT/CC's and IPA's guidance and PHP's advisory into one order of work. The commands are for checking, not attacking.

1. List every PHP that answers web traffic. KISA's rule 1 is the right scope: live servers, not the asset register. Include outsourced builds, campaign and test sites, admin pages, appliances and Windows software that ships PHP.

# Linux: which PHP runtimes are running?
ps -eo pid,user,comm,args | grep -E 'php-fpm|php-cgi|lsphp|frankenphp|httpd|apache2' | grep -v grep
# Is Apache loading mod_php?
apachectl -M 2>/dev/null | grep -i php
# Every php binary on disk, including bundled ones
sudo find / -xdev -type f -name 'php*' -perm -u+x 2>/dev/null | grep -E '/php[0-9.]*$|php-fpm|php-cgi'

# Windows: find bundled PHP and print each version
Get-ChildItem -Path C:\ -Filter php.exe -Recurse -ErrorAction SilentlyContinue |
  ForEach-Object { & $_.FullName -v | Select-Object -First 1; $_.FullName }

2. Check the version the web server actually uses. KISA and the PHP explainer both warn that php -v can lie.

php -v
php-fpm8.3 -v        # adjust to your FPM binary
# Debian and Ubuntu: look for the CVE in the changelog
apt changelog php8.3-fpm 2>/dev/null | grep -m1 -E 'CVE-2026-10961[89]'
# RHEL, Rocky, Alma
rpm -q --changelog php-fpm | grep -m1 -E 'CVE-2026-10961[89]'

3. Containers: rebuild, do not just restart.

docker run --rm --entrypoint php your-registry/app:prod -v
docker build --pull -t your-registry/app:prod .
kubectl rollout restart deployment/your-app   # after pushing the new image

4. Shared hosting. You probably cannot run any of the above. Ask your hosting company in writing whether PHP on your plan is at a fixed version or a backported package, and when workers were restarted. KISA explicitly tells hosting and solution providers to confirm and request updates for their customers. If your control panel lets you choose the PHP version, move off 8.1 and older now.

5. If you suspect compromise, capture before you restart. This is KISA's rule 7. Cut external access, then save logs, process lists and network connections.

sudo ps auxwwf > /root/ir-ps-$(date +%s).txt
sudo ss -tunap > /root/ir-net-$(date +%s).txt
sudo tar czf /root/ir-logs-$(date +%s).tgz /var/log/nginx /var/log/apache2 /var/log/httpd /var/log/php* 2>/dev/null

6. Patch and restart every worker.

sudo apt update && sudo apt install --only-upgrade 'php8.3*'   # or your branch
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # or httpd, lsws
# Confirm the running workers started after the upgrade
ps -o pid,lstart,cmd -C php-fpm8.3

7. Hunt from 17 October.

# Requests mentioning upload progress (Amazon's indicator)
sudo zgrep -h 'PHP_SESSION_UPLOAD_PROGRESS' /var/log/nginx/*access* /var/log/apache2/*access* 2>/dev/null | head
# Multipart POSTs answered with 500 (adjust the field positions to your log format)
sudo zcat -f /var/log/nginx/access.log* | awk '$6 ~ /POST/ && $9 == 500' | head
# Crashes and memory errors
sudo journalctl --since '2026-10-17' | grep -Ei 'segfault|php.*(memory|SIGSEGV)' | head
# New or changed PHP files in web roots since 17 October
sudo find /var/www /srv -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | sort

8. Rotate secrets on any server that was exposed before patching. KISA calls this recommended for exposed servers and mandatory for compromised ones. Database passwords, API keys, admin passwords and session signing keys come first.

9. Check vendors and contractors. PIPC's point: if an outside agency built or runs a PHP site that holds your customers' data, ask them what they did and when. Watch JVNVU#99905564 for Japanese appliance vendors.

10. Decide what to retire. IPA's advice for sites on end-of-life PHP is to ask whether they still need to exist. If nobody can maintain it, take it down.

11. Report. Korea: Boho incident report or 118. Japan: JPCERT/CC's form. Check your personal data breach notification duties with PIPC in Korea or the Personal Information Protection Commission in Japan if data may have left.

For a fleet-wide method, see find and patch every PHP runtime after PHP2Shell.

What would have helped

Asia had less daylight to work with. The fix arrived near midnight local time, after a day of leaks. The teams that coped had the same few things ready.

Practices any team can use:

• A list of live PHP runtimes, not a list of projects. KISA's first rule tells you to work from servers that are actually running. Most asset registers miss the campaign site from 2019 and the admin panel on a forgotten subdomain.
• An after-hours patch path. If your rebuild and redeploy depends on one engineer during office hours, a 23:00 release is a problem. Practise a night patch on a quiet week, with a named approver.
• A pre-agreed offline decision. Japanese banks and Korean regulators both framed suspension as a valid control. Decide in advance which services can pause, who can say so and what users see.
• Evidence first when in doubt. KISA's capture-then-restart order is good incident practice for any runtime flaw that leaves traces in memory.
• Contractor visibility. PIPC's request to check outsourced vendors is easier if contracts already require patch timelines and version reporting.
• End of life tracking. IPA saw sites on unsupported PHP before the release. PHP 8.2 ends on 31 December 2026; plan the move to 8.3 or later now.
• Secrets that are cheap to rotate. Short-lived tokens and a rotation runbook turn "memory may have leaked" from a crisis into a chore.

Where Safeguard fits

Safeguard would not have prevented PHP2Shell and does not patch servers. It helps with finding where PHP lives in what you build, and making the change with a human approving each step.

• Finding PHP in images and SBOMs. safeguard scan --image <name> builds an SBOM of a container image and lists the PHP build inside, so you can compare it with the fixed versions above. safeguard scan --sbom <file> does the same for SBOMs from vendors and contractors, which is the PIPC question in practice, and safeguard scan --dir . covers repositories. Results land as JSON under ./output. Vulnerability matching depends on the databases carrying these new CVEs, so for a same-week flaw, check the PHP version in the SBOM directly.
• "Which projects ship this version?" The platform shows which projects contain a given component and version. Our post on SBOM incident response walks through that workflow.
• Gates. Once the CVEs are in your findings, policies and gates evaluated in the platform can stop a build that still carries an affected PHP image.
• Making the change, with approval. The Safeguard CLI's assistant can edit a Dockerfile to a patched base image and run the build and tests, asking before each command under its default permission mode. From the desktop or phone app you can send that work to a computer running the CLI and approve each command, which matters when the patch lands at 23:00. Autonomous remediation can open fix PRs for application dependencies; it is off by default.

Where it does not help: PHP installed by hand on servers you never scan, shared hosting and control panels you cannot inspect, appliances that embed PHP, restarting workers, capturing forensic evidence, blocking attack traffic or detecting a break-in. Reachability analysis does not lower the priority here, because the bug fires in the runtime before application code runs.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. PHP core is a C runtime outside those ecosystems. We make no claim that Safeguard found PHP2Shell or issued an advisory for it.

Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, with a free read API and a CI gate GitHub Action.

Gold Registry (registry.safeguard.sh, paid) offers hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore-signed, with evidence pages; an artifact loses its badge on regression. We are not claiming a patched PHP image was available there before the public fix. The habit that matters on a night like 21 October is the same either way: pull patched, signed components from a curated source and rebuild fast.

Common mistakes

• Reading the alert level as an order to shut down. Korea's Caution level raises readiness and reporting. KISA and MSIT suggest suspension only if you can neither patch nor mitigate.
• Treating the prime minister's post as the advisory. Takaichi's message was a call to act. The technical guidance is in IPA's and JPCERT/CC's pages.
• Starting the log review on 20 or 21 October. Amazon saw a first attempt on 17 October.
• Restarting a host you think is compromised before capturing evidence. KISA warns that a restart erases memory traces.
• Trusting php -v on a shared host. The CLI and the web runtime can differ; ask the provider.
• Assuming a WordPress or Gnuboard update fixes it. Those update application code, not the PHP runtime underneath.
• Linking every breach this week to PHP2Shell. The Yonsei breach has no reported link. Wait for investigators.
• Running a PoC to "test". KISA says many circulating PoCs hide malware.

Troubleshooting

• "apt says php8.3-fpm is the newest version but the number looks old." Distro backports keep old numbers. Search the changelog for the CVE IDs, as shown above.
• "I set session.upload_progress.enabled = 0 and phpinfo still shows On." You set it in the CLI ini or in .user.ini. Set it in the FPM pool or server config and restart every worker.
• "Workers restarted but one pool still shows the old start time." Some hosts run several FPM services, one per PHP version. Restart each one, and check LiteSpeed's lsphp processes separately.
• "The site broke after the patch." KISA warns patches can cause compatibility issues. Roll back to a maintenance page, not to the vulnerable version, and test on staging.

FAQ

What does South Korea's Caution alert actually require?

It is the second of four private-sector levels. It raises staffing and monitoring at MSIT and KISA and pushes guidance to registered organisations. It does not order anyone to go offline. KISA's rules suggest blocking access or suspending a service only when you cannot patch or apply temporary measures.

Did Japan order websites offline?

No. Prime Minister Takaichi and the NCO said that temporarily stopping a website is one effective way to reduce risk if patching quickly is hard. Banks, airlines, telecoms and others chose to pause services themselves, according to Jiji Press, the Yomiuri and Nikkei.

Was PHP2Shell exploited in Japan or Korea?

The Yomiuri reported that Trend Micro detected attacks against multiple servers in Japan by the morning of 22 October, with damage unknown. The Japanese government said it had no damage reports that morning. KISA said attack attempts were being reported mainly by overseas firms. We found no confirmed Korean victim.

Is the Yonsei University breach connected to PHP2Shell?

No source we read says so. The university, Hankyung and the Seoul Shinmun describe unauthorised access to its portal on 20 and 21 October without naming a vulnerability. The first access window also came before the PHP release.

Why do CSA and CERT-In sound more alarmed than JPCERT/CC?

They are citing different evidence. CSA reports widespread attempts and CERT-In cites reports of large-scale exploitation. JPCERT/CC gives indicators without confirming attacks. Amazon reports broad exploitation; CISA had not observed it at publication. Patch either way.

Which PHP versions do I need?

8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distro package whose changelog lists both CVEs. PHP 8.1 and older get no release; KISA recommends moving to 8.3 or later because 8.2 ends on 31 December 2026.

I use shared hosting in Korea or Japan. What should I do?

Ask your provider in writing whether PHP on your plan is fixed and workers restarted, and when. If you can choose the PHP version in the control panel, pick a supported branch. Then check your own site for new PHP files and unfamiliar admin users, and change your database and admin passwords.

Should I rotate credentials even if logs are clean?

KISA says yes for any server that was internet-facing before the patch, because clean logs do not prove safety and worker memory may have leaked. For servers with signs of compromise it is mandatory.

Where do I report an incident?

In Korea, through the Boho incident report page or KISA on 118. In Japan, through JPCERT/CC's incident form. In India, CERT-In. Personal data breaches may also need notifying to the privacy regulator.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json and runs install and tests with your approval, then pushes nothing. For PHP2Shell you would run the same loop against your PHP image: ask the assistant to bump the base image tag in your Dockerfile, rebuild, and run php -v inside the new container, approving each command. The demo does not show this incident.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on your computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For a Korean or Japanese team, the folder would be the repository holding your PHP Dockerfiles or Ansible roles, and each edit, the version bump and the FPM restart, would wait for your approval.

Click through it at your own pace, or open it full screen.

The mobile demo is a real Android session: work goes to a computer running the CLI and you approve each command on the phone with Allow once, Allow for turn or Deny. PHP's fix landed at about 22:30 in Seoul and Tokyo. This is how an on-call engineer could approve a rebuild and worker restart that night without going back to a desk.

Click through it at your own pace, or open it full screen.

To scan the images you build and run, download Safeguard and follow the CLI docs. For the European side of the story, see governments taking websites offline over PHP2Shell.

Quick check

Sources

• PHP news archive: advance notice, security advisory and releases (php.net)
• KISA Boho notice 72227: PHP product security update recommendation (Korean)
• KISA Boho notice 72230: Enterprise response rules for PHP2Shell (Korean)
• KISA Boho security notice list (Korean)
• MSIT press release on PHP, korea.kr (Korean)
• PIPC press release on PHP, korea.kr (Korean)
• JPCERT/CC: JPCERT-AT-2026-0033 (Japanese)
• JVN: JVNVU#99905564 (Japanese)
• IPA: PHP vulnerability countermeasures, 22 Oct (Japanese)
• IPA: pre-alert on the PHP security release, 21 Oct (Japanese)
• IPA security alert index 2026 (Japanese)
• CSA Singapore: Critical Vulnerabilities in PHP (PHP2Shell)
• CERT-In: CIVN-2026-0510
• CERT-EU Security Advisory 2026-018
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure
• Trend Micro: Security alert KA-0024789
• ZDNet Korea: MSIT issues Caution alert over PHP (Korean)
• Hankyung: Global PHP emergency, government raises alert to Caution (Korean)
• Aju Business Daily: Government raises cyber crisis alert to Caution (Korean)
• Hankyung: Yonsei portal breach (Korean)
• Seoul Shinmun: Yonsei personal data leak (Korean)
• Impress Watch: Emergency maintenance and suspensions at major Japanese services (Japanese)
• ITmedia NEWS via Yahoo Japan: PM Takaichi's request on X (Japanese)
• Nikkei: PM Takaichi says suspending websites is effective (Japanese)
• Nikkei: Suspensions spread to banks and telecoms (Japanese)
• Jiji Press via Yahoo Japan: Banks and companies take precautions (Japanese)
• Jiji Press: PM and LDP executives stop homepages (Japanese)
• Yomiuri Shimbun via Infoseek: Banks pause net services, PM's site stopped (Japanese)

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.