futureshop Breach: 3,147,469 Lindt Japan Records and a PHP Shutdown

On 17 October 2026 an attacker exploited a software vulnerability on servers run by futureshop, a Japanese SaaS e-commerce platform, and took 3,147,469 member records belonging to one merchant, Lindt & Sprüngli Japan. Card data was not included. Lindt members should watch for phishing and reset reused passwords. Merchants on any SaaS platform should check their vendor's breach notice terms.

Four days later the same platform found a second, separate intrusion on four servers, and that evening it stopped every futureshop and futureshop omni-channel shop for about 26 hours while it dealt with the critical PHP flaws disclosed that week, known as PHP2Shell. futureshop has not named the vulnerability used in either intrusion. The overlap with PHP2Shell is a matter of timing only, and this post treats it that way.

This post sets out what futureshop and Lindt have said in their own notices, in order and to the minute where they give times. It then covers what one multi-tenant platform incident means for the many shops that share it, the PHP2Shell facts any PHP platform operator needs this week, and concrete checks for platform teams and for merchants who rent their storefront from someone else.

What happened

futureshop is run by Future Shop Co., Ltd. of Kita-ku, Osaka. The company says in its own press materials that it was split off from Future Spirits Co., Ltd. in March 2010. Its platform hosts storefronts, admin screens, FTP, an API and email for many independent shops, and an omni-channel product that joins store and online customer data.

The incident unfolded as two separate events that came to light in reverse order. The second intrusion was announced first, on 21 October. The first, larger one was announced on 23 October.

Timeline

All times are Japan Standard Time (UTC+9) unless marked.

Two intrusions, not one

It is easy to read the notices as one story. They describe two.

futureshop has not said whether the two intrusions used the same vulnerability, the same entry route or the same actor. A security news summary of the Lindt case makes the same point: there is no official statement linking them and no official statement that either involved PHP2Shell.

Why the 22 October notice and the 23 October notice read differently

The 22 October 07:00 report says futureshop had found no trace of personal data being viewed or taken. On 23 October futureshop announced that 3.1 million member records had been taken. Read quickly, those look contradictory. They are not, because they describe different events. The 22 October statement was about the four servers named on 21 October. The member data theft happened on 17 to 18 October, and futureshop says it had already reported that to the affected shop on 19 October.

futureshop's 23 October notice acknowledges that publication took time. It says that in the gap it was confirming facts with the shop and preparing customer notices and a contact desk. Lindt says the online shop was stopped from 16:00 on 21 October, which was before either public notice about the theft.

Who is affected

One point on the count. A security news summary notes that 3,147,469 is the number of records, not a confirmed number of distinct people, and that Lindt's online shop and app share one account system, so it is not two databases added together.

Technical details

Neither company has published indicators of compromise, the vulnerability name, the attack technique or the hashing algorithm. Lindt says details of the method are being withheld to prevent repeat attacks and secondary harm. What follows is everything concrete that the primary sources do publish, plus the PHP2Shell specifics that matter to anyone running PHP this week.

Data fields taken, as published

Lindt's notice is the more complete list. futureshop's list matches it but folds the last three items into "other member information".

On cards, futureshop says card details typed by a shopper are processed directly by the payment agency and never pass through or rest on futureshop's servers. Lindt says its online shop does not store card information.

On passwords, futureshop says the hashed form cannot be used to log in as is. That is true of the hash itself. Whether hashes can be cracked offline depends on the algorithm, salt and cost settings, none of which have been published. Treat any short or reused password as exposed.

Server and service identifiers

The FormMailer shutdown is worth a note. futureshop says it ended the two products because their developer, Future Spirits, decided to end them urgently. Future Spirits says the reason was age and the difficulty of keeping a legacy service at the security level now required, and that it had found no unauthorized access in that service. No source connects the FormMailer decision to either intrusion. It is, though, a clear example of a vendor retiring old code under pressure rather than patching it, and shops that depended on it had about six hours' notice.

Durations

futureshop's restart notice apologises for repeatedly moving the expected restart time, which made it hard for shops to plan. That is a useful, honest admission, and a reminder that the estimated time in an outage notice is a planning input that can slip.

PHP2Shell: the facts a PHP platform operator needs

futureshop's 21 and 22 October notices describe the platform stop as a response to "a serious vulnerability in PHP" that was "being covered in the news". The PHP security release that week fixed two flaws. Again, futureshop has not said either intrusion used them. These details are here because anyone running a PHP platform faced the same decision futureshop did on 21 October.

Fixed versions, from both GitHub advisories and php.net:

PHP's advisory lists partial mitigations for teams that cannot update at once. It is explicit that only the update is a complete fix.

• For CVE-2026-109618: memory_limit=-1 set administratively (for example php_admin_value in the FPM pool) so applications cannot restore a finite limit; a low post_max_size (8M if no uploads, 32M if uploads are needed) with upload_max_filesize below it; request size and count limits at the proxy, including for requests without a usable Content-Length; a container or cgroup memory limit as an availability boundary. Do not use RLIMIT_AS or RLIMIT_DATA, which the advisory says can cause the vulnerable allocation failure.
• For CVE-2026-109619: session.upload_progress.enabled=0 in php.ini, the FPM pool or server config (not ini_set() or .user.ini), then restart every worker; on 8.5, fatal_error_backtraces=0; pm.max_requests=1 in the FPM pool if performance allows; remove per request settings that emit diagnostics before initialisation; fix attacker reachable fatal errors and timeouts. Hiding errors with error_reporting, display_errors or @ does not help.

There is one newer item. On 23 October php.net posted an informational advisory recommending session.upload_progress.enabled=0 until the next regular release, to close an "unlikely RCE vector" tracked as CVE-2026-115560. It only applies when an application sets session.serialize_handler to php_binary or php_serialize in configuration and then switches it to php with ini_set() before session_start(), with upload progress still on. If you set the upload progress mitigation on 21 October, PHP says to keep it in place. A full advisory comes with the next release.

The timing overlap, stated carefully

BleepingComputer reported on 22 October that a large cloud provider's threat intelligence team saw PHP2Shell exploitation attempts begin on Saturday 17 October, four days before the fixes, against a honeypot, from addresses on a commercial anonymisation network. The same report says other observers had seen only scanning, fingerprinting and non-working exploits, with no known compromises. It does not mention Japan or e-commerce.

futureshop's first intrusion began at 23:02 JST that same Saturday. That is the whole of the connection. Two facts cut the other way, or at least do not help: futureshop says it applied a countermeasure for the exploited vulnerability on all admin servers on 19 October, two days before PHP published fixed releases; and a countermeasure can be a configuration change, a block at the edge or a patch to some other software. The public record does not tell us which software was exploited. Anyone who says this breach was PHP2Shell is ahead of the evidence.

How one platform bug becomes every shop's outage

Multi-tenant SaaS is how most small and mid-sized online shops run. One vendor runs the servers, the runtime, the database and the mail, and each shop gets its own storefront and admin screen on top. That model is efficient and usually safer than each shop running its own stack. This incident shows its two sharp edges.

One tenant's whole customer base in one read. The theft took 74 minutes from entry to data, by futureshop's own times: in at 23:02, member data taken at 00:16. The attacker took one shop's member records as a single set. That suggests, without proving, that whatever access was gained could read a tenant's whole member table. No source says how. In general, a platform where application servers hold one database credential that can read every tenant's data turns any server compromise into a potential all-tenants read, and tenant scoping rests only on the application's own query filters.

Every tenant shares the runtime. When the risk sits in the runtime itself, as it did with PHP2Shell, there is no per-tenant fix. The platform has to patch or stop the runtime for everyone. futureshop chose to stop. Its notice frames it as a precaution "until safety can be confirmed". For a platform that had just found a second intrusion that morning, with the 20:00 JST stop coming three hours before PHP's scheduled 23:00 JST (14:00 UTC) release time, that was a defensible call. It cost every shop roughly a day of trading.

Shared mail and shared forms. The four-server intrusion also took down each affected shop's own-domain email, and the form services ended on 23 October. A shop that thinks of its platform as "the store" may not have mapped that its customer mail and inquiry forms ran on the same vendor.

What to do now

If you are a Lindt Japan member

1. Expect an email from Lindt from 26 October. Lindt says it will never ask for your password or card details by email or phone, and that its official domain is www.lindt.jp. Type it into the browser rather than following links.
2. If your Lindt password is used anywhere else, change it there now. You cannot change the Lindt one until the shop reopens; Lindt will explain how then.
3. Be ready for mail, SMS, calls or letters that use your name, address and birth date. Fake order confirmations, point expiry notices and "re-register" or "compensation" pages are the obvious lures.
4. Lindt's dedicated line is 0120-713-065, 9:00 to 21:00 including weekends and holidays, per its notice.

If you run a multi-tenant PHP platform

These steps are for operators, the role futureshop was in. Run them on every host and image, not just the ones you remember.

1. Inventory every PHP runtime and its SAPI. The CLI and the web runtime are often separate packages.

php -v
php -i | grep -E '^(PHP Version|Server API|Loaded Configuration File)'
# Debian and Ubuntu: list every PHP package and version
dpkg -l | awk '/^ii/ && $2 ~ /^(php|libapache2-mod-php)/ {print $2, $3}'
# RHEL family
rpm -qa | grep -E '^php' | sort
# What a running FPM pool reports
curl -s http://127.0.0.1/fpm-status?full | head

2. Confirm the fixed version or a distro package that names the CVEs. A distro build can carry the fix under an older looking version string.

# Debian and Ubuntu
apt changelog php8.4-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]' | head
# RHEL family
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]' | head
# Container images
docker run --rm your-php-image:tag php -v

3. Restart every worker. A package upgrade does not replace code already in memory.

sudo systemctl restart php8.4-fpm
sudo systemctl restart apache2   # for mod_php
# Prove no worker predates the upgrade
ps -o pid,lstart,cmd -C php-fpm8.4

4. Apply the upload progress setting and check it took effect where it matters, in the FPM pool or php.ini, not per request.

php -r 'var_dump(ini_get("session.upload_progress.enabled"));'
grep -R "session.upload_progress.enabled" /etc/php/ 2>/dev/null
# In an FPM pool file, set it administratively:
#   php_admin_value[session.upload_progress.enabled] = 0

5. Look for bulk reads of one tenant's member table. The theft here was one shop's full member set taken in one go. Whatever your database, find statements that returned a very large number of rows.

-- MySQL 8 with performance_schema enabled
SELECT DIGEST_TEXT, COUNT_STAR, SUM_ROWS_SENT, LAST_SEEN
FROM performance_schema.events_statements_summary_by_digest
WHERE SUM_ROWS_SENT / NULLIF(COUNT_STAR,0) > 100000
ORDER BY LAST_SEEN DESC
LIMIT 20;

-- PostgreSQL with pg_stat_statements
SELECT query, calls, rows, rows / NULLIF(calls,0) AS rows_per_call
FROM pg_stat_statements
WHERE rows / NULLIF(calls,0) > 100000
ORDER BY rows_per_call DESC
LIMIT 20;

6. Check web and egress logs for unusually large responses or uploads. A full member export is tens to hundreds of megabytes.

# Combined log format: field 10 is response bytes. Show the largest responses.
awk '{print $10, $1, $4, $7}' /var/log/nginx/access.log | sort -nr | head -20
# Outbound volume per destination from a host, if you keep flow logs
# (adapt to your flow log schema)

7. Rotate what an attacker on a PHP host could read. Database credentials in config files, API keys, mail relay credentials and session secrets. If you rebuilt servers, as futureshop did for four of them, do not restore old secrets onto the new hosts.

8. Decide in advance when you stop the platform. Write down the trigger (for example, a critical unauthenticated RCE in your runtime with no fixed release, plus any sign of intrusion), who decides, what the shop notice says and how often you update it.

If you are a merchant on a SaaS platform

1. Find out which platform holds your customer master data, and every vendor that touches it. Storefront, app, CRM, email and forms may all be different, or all the same vendor.
2. Ask your platform three questions this week: which PHP (or other runtime) versions it runs, when it moved to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a patched distro package, and whether session.upload_progress.enabled is off.
3. Check your contract for a breach notice time. Under Japan's personal information rules, the business that holds the data owes the PPC a preliminary report within about 3 to 5 days of discovery, and a final report within 30 days, or 60 days where improper intent such as unauthorized access is suspected. Your contract should make the vendor tell you fast enough for you to meet that.
4. Plan for a vendor wide outage. A static maintenance page you control, an alternative contact route that does not run on the platform, and a list of what breaks (app login, point balance, forms, own-domain mail) when the platform stops.
5. Prepare your customer notice before you need it. Lindt's notice is a fair model: what was taken, what was not, what the customer should do, and a phone line with hours.

What changed since the first reports

• 21 Oct: The story started as an intrusion on four named servers and then a precautionary platform stop for PHP. Neither notice mentioned stolen data.
• 22 Oct, 07:00: No trace of personal data viewed or taken on the four servers. Mail on affected shops' domains suspended.
• 22 Oct, 23:35: Platform back; four servers rebuilt.
• 23 Oct: A separate, earlier theft of 3,147,469 member records from one shop disclosed, with the shop named by its own notice as Lindt Japan. The cause is described only as a vulnerability in software used on futureshop's servers. Two legacy form products ended the same day.
• 23 Oct: PHP posts the CVE-2026-115560 informational advisory, which strengthens the case for keeping session.upload_progress.enabled=0.

Open questions

• Which software and which vulnerability were exploited on 17 October? futureshop has not said.
• Were the 17 October and 21 October intrusions related in method, route or actor?
• Why was one shop's data taken and not others? futureshop says it found no trace of the same method against other shops' data, and that this is still under investigation.
• Which password hashing algorithm and settings protect the leaked hashes?
• What did the outside specialists find? futureshop says it will publish preventive measures after the investigation.
• When will the Lindt online shop reopen, and how will password resets work?

What would have helped

None of this is a judgment of futureshop's or Lindt's decisions. Their notices are clear about what is known and what is not, and futureshop's decision to stop the whole platform rather than run on an unpatched runtime is the kind of call many teams find hard to make. The points below are what any team running or renting a multi-tenant platform can take from it.

Practices any team can use

Per tenant database credentials. If each tenant's data lives in its own schema or database, give the application a credential per tenant, or use row level security keyed to a tenant setting that the application cannot change mid request. A compromise of one request path then reads one tenant at most, not all of them. In PostgreSQL:

ALTER TABLE members ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON members
  USING (tenant_id = current_setting('app.tenant_id')::bigint);

In MySQL, the equivalent is a user per tenant schema with grants only on that schema:

CREATE USER 'shop_1234'@'10.0.%' IDENTIFIED BY '...';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop_1234.* TO 'shop_1234'@'10.0.%';

Alerts on bulk reads, not just on logins. futureshop's monitoring found the theft about 39 hours after it happened. An alert that fires when a single session, query digest or credential returns more than a set number of member rows in an hour cuts that window. The thresholds are easy to set once you know normal batch jobs.

Egress control on application servers. A storefront server rarely needs to send hundreds of megabytes to an arbitrary address. Restrict outbound traffic to known destinations, and alert on volume.

A runtime inventory you can query in minutes. On 21 October every PHP operator needed to know which hosts and images ran which PHP branch and SAPI. A table of host or image, PHP version, SAPI and owner turns that into a checklist. Our PHP runtime playbook walks through building it.

Rebuild, do not clean. futureshop rebuilt the four servers before returning them. That is the right default for a host where an attacker had code execution, combined with new secrets.

A written stop rule and honest restart estimates. Shops lost the most when restart times kept moving. Publish an update time, not just a restart time, and keep to it.

Retire legacy services on a schedule, not in a crisis. The FormMailer products were ended with about six hours' notice. An annual review of old services, with a published end of life date, gives customers months instead of hours.

For merchants: vendor inventory and breach notice terms. Our post on the IDCF Cloud ransomware incident and third party risk covers vendor inventory in more depth. That post lists Future Shop among the SaaS companies reported affected by the IDCF Cloud incident earlier this month. Two platform events in one month is a reason to ask the questions above, not a reason to assume either was preventable from the merchant side.

Zero-Day Discovery and Gold

Safeguard's 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 language runtime, not a package in those ecosystems, and nothing here suggests Zero-Day Discovery found the vulnerability used against futureshop or PHP2Shell, or that an SGZ advisory existed for either.

Gold Open Source at gold.safeguard.sh is free and needs no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is the paid catalogue of hardened, drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages. We are not claiming Gold had a patched build for this incident. The habit these tools support is the one that matters on a day like 21 October: know the safe version, pull patched and signed components from a curated source, and rebuild fast.

Where Safeguard fits

Safeguard is useful for the parts of this story that sit in code and images a team builds itself:

• Find every PHP image and dependency. safeguard scan --dir . scans a repository, safeguard scan --image <name> a container image and safeguard scan --sbom <file> an SBOM, writing JSON under ./output. The platform then shows which projects contain a given component and version, so "which of our images still carry PHP 8.4.26" is a query, not a hunt. Our post on using SBOMs to find affected products fast shows the pattern.
• Match against vulnerability data and rank by reachability. Findings are matched against vulnerability databases, and reachability analysis puts the code paths your application actually calls first.
• Stop regressions with policies and gates. A gate evaluated in the platform can block a build that pins a PHP base image below the fixed version.
• Open the fix. Autonomous remediation can open fix pull requests (it is off by default). The Safeguard CLI's assistant can edit a Dockerfile or composer file and run your tests, asking before each command unless you choose another /permissions mode (Ask, Accept edits, Plan, Auto, the default, or Strict). safeguard exec runs the same in CI.

Where Safeguard does not help: it does not run a SaaS vendor's servers, so a merchant cannot use it to patch a platform it rents. It does not detect intrusions, watch database queries or monitor egress. It would not have stopped the 17 October theft, and nothing in this post claims it would. For a merchant, its value is indirect: knowing your own estate well enough to ask vendors sharp questions, and to fix your own side quickly.

Common mistakes and troubleshooting

• Treating the 22 October "no personal data" line as the final word. It covered the four servers. The member theft was a different, earlier event.
• Assuming PHP2Shell was the cause. No source says so. Write your incident notes on the facts you have.
• Trusting php -v alone. The CLI and FPM or Apache module are separate packages. Check every SAPI and restart every worker.
• Setting session.upload_progress.enabled=0 with ini_set() or .user.ini. PHP says those apply too late. Use php.ini, the FPM pool or server config.
• Using RLIMIT_AS as a memory guard. PHP's advisory says this can trigger the vulnerable path. Use a cgroup limit instead.
• Restoring old secrets onto rebuilt hosts. A clean server with the old database password is not clean.
• Assuming hashed means safe. Weak or reused passwords can still be recovered from many hash formats. Reset and warn.
• Forgetting what else runs on the platform. App logins, loyalty points, forms and own-domain mail all stopped here. List them before the next outage.
• Clicking the breach email link. Go to the official site directly, as Lindt asks.

FAQ

What happened at futureshop?

An attacker exploited a vulnerability in software on futureshop's servers at 23:02 JST on 17 October 2026 and took one merchant's member records at 00:16 on 18 October. A separate intrusion on four servers was found on 21 October, and the whole platform was stopped that evening for the PHP vulnerability before returning at 23:35 on 22 October.

Which company's customers were affected?

Lindt & Sprüngli Japan says in its own 23 October notice that 3,147,469 member records from its online shop and official app were taken. futureshop says only one shop's data was taken, and that it has found no trace of the same method against other shops so far.

Was credit card data stolen?

No, according to both companies. Card details are processed directly by the payment agency and are not stored on futureshop's servers.

Was this the PHP2Shell vulnerability?

futureshop has not named the vulnerability. A cloud provider's threat team, as reported by BleepingComputer, saw PHP2Shell exploitation attempts begin on 17 October, the same day as the intrusion. That is timing only. futureshop also says it applied a countermeasure on 19 October, before fixed PHP releases existed.

Why did futureshop shut down every shop?

Its notice says a serious PHP vulnerability had been confirmed and the stop was a precaution until safety could be confirmed. When the risk is in the shared runtime, there is no per shop fix; the platform has to patch or stop for everyone.

Why did disclosure take four days?

futureshop says it found the theft around 15:30 on 19 October, told Lindt the same day, and used the time before the 23 October notice to confirm facts and prepare customer notices and a contact desk. It apologised for the delay.

What should Lindt members do?

Watch for phishing using your name and address, change any password you reused elsewhere, and change your Lindt password when the shop reopens. Use the official site directly and Lindt's member line if in doubt.

What should other futureshop merchants do?

Read futureshop's notices, check whether you were on c02, c05, c12 or g06, check whether you used FormMailer FreePlus or New FormMailer, and ask for the outside investigation's findings when they are published.

What should PHP platform operators do now?

Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or a distro package that lists both CVEs, restart every worker, keep session.upload_progress.enabled=0 set administratively, and review bulk read and egress alerts.

Would Safeguard have prevented this?

No. Safeguard does not run or monitor a SaaS vendor's servers and does not detect intrusions. It helps teams find which of their own images and repositories carry a vulnerable component, and open and approve the fix quickly.

Fix it without waiting for upstream

For a PHP platform, the runtime itself is a component like any other: it has a version, a fixed version and a base image you can rebuild from. The habits below are about closing the time between a fix existing and that fix running in your builds.

Whatever the vulnerability, 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

None of these demos shows futureshop, Lindt or their systems. Each is a real Safeguard session, and each intro says how the same flow would apply to a team that builds and runs its own PHP platform or storefront.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a PHP platform you would run /scan . in the repository that builds your PHP image, then ask the assistant to bump the base image to a fixed PHP tag and set session.upload_progress.enabled=0 in the pool config, approving each edit and test run.

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

This session sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. A platform team could run the same setup on a build host and scan each PHP image it ships with safeguard scan --image, so the list of images still below 8.4.27 or 8.3.36 comes from evidence, not memory.

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

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. On a night like 21 October, the on call engineer could approve the image rebuild and test run from a phone, and deny anything that restarts production until the stop or go decision has been made.

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

To try it on your own services, download Safeguard and follow the CLI docs. For the PHP flaws themselves, read PHP2Shell explained, and for the wider month, October 2026 security incidents and what would have helped.

Quick check

Sources

• futureshop: unauthorized access to our servers, first report (21 Oct 2026)
• futureshop: emergency maintenance, service stop for the PHP vulnerability (21 Oct 2026)
• futureshop: unauthorized access, second report (22 Oct 2026)
• futureshop: emergency maintenance continues for the PHP vulnerability (22 Oct 2026)
• futureshop: emergency maintenance ends, service restored (22 Oct 2026)
• futureshop: personal information leak due to unauthorized access, first report (23 Oct 2026)
• futureshop: FormMailer FreePlus and New FormMailer end of service (23 Oct 2026)
• futureshop: weekend support desk, 24 and 25 Oct (23 Oct 2026)
• futureshop: company press release with company profile (15 Oct 2026)
• Lindt & Sprüngli Japan: notice of personal information leak at a contractor (23 Oct 2026)
• Future Spirits: FormMailer FreePlus end of service (23 Oct 2026)
• PHP news archive: advance notice, 21 Oct security advisory and releases, 23 Oct informational advisory (php.net)
• GHSA-w8hw-w9fx-j79w: RCE via OOM corruption, CVE-2026-109618 (php-src on GitHub)
• GHSA-6wmf-4rv5-p3rp: RCE via stale global state, CVE-2026-109619 (php-src on GitHub)
• Personal Information Protection Commission: breach reporting obligations (ppc.go.jp)
• BleepingComputer: PHP2Shell exploitation began 4 days before patches (22 Oct 2026)
• Security news summary: Lindt Japan and futureshop, 3,147,469 member records (24 Oct 2026)

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