# They named PHP and then took it back

2026-10-23

Bartec confirmed a fact it treats as a customer-data leak and stopped a long list of MOT and POS services. The first notice blamed a PHP attack. The correction says that was the wrong sentence: their own product was the flaw. No count yet. Earliest restore is 26 October.

Canonical: https://www.fabiocti.com/notes/they-named-php-and-then-took-it-back/
Author: Fabio Correia

The POS is down. The CVE they named is not why.

Bartec said a third party reached it and that it has a fact it treats as customer information leaving. It stopped MOT Cloud, reservations, attendance, expenses, hotel, a stack of POS and ticket-machine functions, and said the earliest restore is 26 October. It has not published a field list, a count, or a date the access started.

The first notice blamed a PHP vulnerability. The correction, now at the top of the same page, says that sentence was a misbrief. They had a separate PHP-hardening job running and mixed it up with this intrusion. This one, they now say, is a flaw in their own service. The PHP2Shell rows from 21 October are not this door. Do not add Bartec to a php2shell victim list.

## What a blank count will be asked to cover

It will be briefed as every MOT customer in Japan. They have not numbered a file. It will be briefed as php2shell. They took that sentence back. A long outage list is not a finding that every stopped product sat in the same export. Attendance being down is an outage. “A fact we treat as a leak” is the incident, still without fields.

If you run MOT or their POS, treat the services as off until the 26th, and treat customer data as unresolved until they list it. Do not brief a PHP patch as the close. A mail that already knows a timesheet and asks for a card is someone else.

They named the wrong bug in the first hour. Wait for the field list. Do not wait for the POS to come back before you ask what left.