Value Card and MOS CARD Breach: 1.4 Million Prepaid IDs and PINs

A third party exploited a web server vulnerability at Value Design, which runs the white label prepaid service Value Card, and took 1,424,748 card IDs with PINs and balances. Mos Food Services says 1,133,070 of its MOS CARD records were among them. No names were taken. Mos has force changed affected PINs; cardholders should check their usage history.

This post sets out what the three companies said in their notices of 23 October 2026, what the numbers do and do not mean, and what any team running or buying a stored value platform can take from it. Public technical detail is thin. Neither company has named the vulnerable product, a CVE, an attacker or indicators of compromise for this incident, and we do not guess at them.

One point up front: Value Design paused two other services on 22 October as a precaution against PHP2Shell, but the breach notices do not connect the breach to PHP2Shell, and the suspicious activity began on 14 October, a week before PHP2Shell was public. The link is timing only.

What happened

Value Design Inc. (株式会社バリューデザイン) is a consolidated subsidiary of Paycloud Holdings, which is listed on the Tokyo Stock Exchange Growth market under code 4015. Value Design sells cashless payment and marketing services to retailers and restaurants. Its main product, Value Card, lets a business issue its own house electronic money (ハウス電子マネー), often marketed in Japan as a store's own "Pay": a branded prepaid card or app balance that customers top up and spend only at that business. Value Design's service page says the platform is used at about 130,000 stores, and a partner announcement from 31 August 2026 gives the same figure.

Mos Food Services (株式会社モスフードサービス), which runs the Mos Burger chain and is listed on the TSE Prime market under code 8153, issues a prepaid card called MOS CARD (モスカード). Mos outsources the server operation and maintenance of MOS CARD to Value Design.

On 23 October 2026 three notices appeared. Paycloud's timely disclosure gave the confirmation date (19 October), the platform total (1,424,748 ID records) and the cause (a web server vulnerability in part of the subsidiary's system environment). Value Design's notice repeated the core facts and said it was reporting progress to the client companies where unauthorised access had been confirmed. Mos's timely disclosure, with a customer notice attached and a matching page on the Mos Burger site, gave the MOS CARD count of 1,133,070 and the customer actions. Nikkei reported the Mos figures the same day.

Timeline

All times are Japan Standard Time. Where a source gives only a date, the table gives only a date.

The 14 to 18 October window is when suspicious activity was detected, not necessarily the whole period of attacker activity; no source says when access began.

What was taken

Both companies describe the same three fields. Neither says any personal information was involved.

Paycloud defines an unissued ID as one that an end user has not yet bought. Mos uses the term "not yet distributed" for cards that have not reached customers. Those are close but not identical definitions.

Why you should not add the two numbers

Mos issues its cards on Value Card, so its 1,133,070 records are, on any reasonable reading, part of Paycloud's 1,424,748. Reporting "2.5 million" would be wrong. The splits line up: about 570,000 leaked MOS CARDs were in circulation, against 569,224 issued IDs across the whole service. By inference, not by either company's statement, almost all leaked issued IDs appear to be MOS CARD, and the remaining 291,678 or so records (1,424,748 minus 1,133,070) appear to be mostly unissued IDs outside the Mos count. Value Design's mention of "some client companies" implies Mos may not be the only affected issuer; none other has been named.

Each record is a card, not a person. One customer may hold several cards, and more than half of the Paycloud total is cards nobody has bought yet.

Card number plus PIN: why "no personal data" still means money

Weighed by personal data, this incident looks mild. It is not, and the companies' own response shows why.

In a closed loop prepaid scheme, the card number identifies a balance and the PIN proves the right to use it. For web balance checks, app registration and guest checkout in online ordering, those two values are what the system asks for. Together they work like a bearer credential. That is why Mos force changed every PIN tied to a leaked card number, and why those three online functions are exactly the ones Mos says may now fail until a customer contacts support. Paycloud's wording fits: issued IDs were at risk of fraudulent use, the risk has been dealt with, and there has been no actual damage from misuse.

Unissued cards matter too. They hold no balance today, but become valuable the day a customer buys and loads one, if the number and PIN still match what the attacker holds. Mos says it changed the PINs linked to leaked card numbers without separating sold from unsold.

The cause, as stated

The three notices say three slightly different things about the cause, and they are worth reading side by side.

• Paycloud: a web server vulnerability was exploited by a third party in part of the subsidiary's system environment.
• Mos: Value Design detected suspicious access and unauthorised login attempts against the MOS CARD management system, and the investigation found that unauthorised access "using an external program" led to the leak.
• Value Design: no cause beyond what the parent disclosed.

No source names the web server, the product, a version, a CVE, or how the attacker reached the stored data. "External program" usually means automated tooling, but Mos says no more than that.

Mos's recurrence prevention list adds some shape: stronger controls against unauthorised access through APIs, limits on simple or high risk password settings, source IP restrictions for administrative accounts, and better early warning monitoring including in contractor environments. A remediation list is not a root cause statement, but it points at three areas to check on any platform: API access control, weak credentials, and where admins can log in from.

What this is not

Not, on current evidence, PHP2Shell. Value Design suspended Arara Cashless and Online Charge on 22 October over CVE-2026-109618 and CVE-2026-109619 as a precaution, while Value Card ASP kept running. The 23 October breach notices do not mention PHP or any CVE, and detection began before the PHP advisory of 21 October.

Not, on current evidence, part of a named campaign. JPCERT/CC's running alert on a wave of unauthorised access at Japanese organisations, updated 23 October, does not name Value Design, Value Card or Mos. We cite its controls and indicators below as useful context, not as an explanation.

Technical details

This section collects every concrete value the primary sources publish, then the related technical facts that a defender running a stored value platform will want in one place. Where a value is not about this incident, the heading says so.

Values published by the companies

No CVE, product name, version, IP address, domain, file hash, user agent or other indicator of compromise has been published for this incident.

What a 6 digit PIN means in practice

A 6 digit numeric PIN has 1,000,000 possible values: many for a person at a till, very few for a computer. Two general consequences follow; neither is a claim about how Value Card was built.

Online guessing must be throttled per card, not only per IP address. An attacker who spreads guesses across many addresses can work through the space for chosen cards unless the system counts failures per card. Mos reports "unauthorised login attempts" in the detection window; we do not know whether they succeeded or how the data was taken.

Hashing a 6 digit PIN on its own does not protect it. A plain or salted hash of a value with a million possibilities falls to trying all of them. Protection has to come from a secret the attacker does not get with the database: a keyed hash such as HMAC, or encryption, with the key in a hardware security module or key management service. OWASP's password storage guidance calls such a separately stored secret a pepper.

The companies do not say whether PINs were stored in a directly readable form, whether a key was also taken, or whether PINs were collected some other way. We do not assume an answer. A design where a database read alone yields usable PINs is the one to check for on your own platform.

Context only: indicators from JPCERT/CC's general alert

JPCERT/CC's alert JPCERT-AT-2026-0030, first published 8 October and updated 23 October, covers a run of unauthorised access cases at Japanese organisations since around September 2026. It does not name this incident, and JPCERT says not every case used the same method. We list its published indicators because they are the most current official set for Japanese web and API intrusions this month and a platform operator can sweep logs for them in minutes. JPCERT notes that some of these addresses may be in legitimate use at the time you investigate. Indicators are defanged as JPCERT published them.

For Case B, JPCERT also lists user agents curl/7.88.1, python-requests/2.34.2, a desktop Chrome 126 string and, added 23 October, a user agent identical to the target's own app, plus JA4 t13d181100_85036bcba153_d41ae481755e and JA3 93c7d42c0df602fb91589311534831f5. It warns that this JA4 matches a common Python HTTP client and should not be used alone, and reports traffic through Tor exit nodes and residential proxies.

Case B abuse includes changing user privileges, creating rogue accounts, probing responses with missing headers or malformed tokens, and blind NoSQL injection to identify accounts. JPCERT's recommended controls include request limits on every API, separate limits on login, password reset, SMS and search, access control on every endpoint including non public ones, least privilege tokens with expiry and fast revocation, and taking unneeded admin functions off the internet.

Context only: the PHP flaws behind the 22 October suspension

Because Value Design paused two services over PHP2Shell, here are the official version facts. They concern the precautionary suspension, not the breach.

Value Design's notice gives a CVSS 4.0 base score of 9.2 (Critical). PHP 8.1 and older get no official release, only minimal source backports. JPCERT/CC's alert lists compromise checks: malformed PHPSESSID cookies, suspicious multipart/form-data requests near memory limit errors or HTTP 500s, and unexpected worker crashes. Our PHP2Shell explainer covers the flaws, and finding and patching every PHP runtime covers the inventory work.

Who is affected

Holders of other retailers' prepaid cards should check that retailer's own notices.

The processor is the breach surface

The structural point of this incident is easy to state. Hundreds of brands can run their prepaid cards on one white label platform, and customers usually see only the brand. When the platform is breached, every brand's card data is in the same blast radius, and each brand learns of it from its contractor.

Mos's disclosure is candid about this. It says it takes the matter seriously "including management of the contractor", and the first item on its recurrence list is stricter oversight of contractors and external partners: re-verifying the security level of contractor servers and systems, and stronger supervision and security audits.

Several other incidents disclosed in Japan this month also reached many brands through one shared platform. Nothing links Value Card to them; what they share is the shape of the risk. For prepaid, the inheritance is financial: a leak of working card number and PIN pairs is closer to a leak of cash, and the brand carries the customer relationship and the cost of re-PINning even though it never ran the server.

What to do now

If you hold a MOS CARD

1. Keep using the card in store, in online ordering and in table ordering; Mos says these are unaffected.
2. If web balance checks, new registration in the official app, or guest purchases in online ordering with MOS CARD fail, call the MOS CARD hotline: 03-3496-8322 until 26 October, then 0120-395-126 from 27 October, 09:00 to 22:00. Mos says it may ask simple identity questions such as the store you use or your balance.
3. Check your usage history for top up deductions or purchases you do not recognise, and report them to the hotline.
4. Ignore messages that ask for your card number or PIN by email, SMS or phone. Mos's notice does not say it will contact customers that way, and a well known breach is a common hook for phishing.

If your business issues cards on a white label prepaid platform

Ask your provider these questions in writing, and keep the answers.

1. Were any of our card records in the leaked set, and how many in each state (sold, unsold, cancelled)?
2. Which fields: card number, PIN, balance, transaction history, any linked app account or email?
3. Has every PIN for those records been rotated, including unsold stock, and how will customers be told?
4. What rate and lockout controls apply per card on balance check, registration and guest checkout endpoints?
5. How are PINs stored at rest, and where is the key?
6. Which admin interfaces are reachable from the internet, and from which source addresses?
7. What log retention do you hold, and can you give us per card access logs for the incident window?
8. When will we receive a written incident report, and does it name the vulnerable component?

If you run a stored value or prepaid platform

The steps below are general. They do not assume anything about how Value Card was built.

1. Sweep logs for the JPCERT indicators. Even though they are not tied to this incident, they are current and cheap to check.

# Nginx or Apache combined logs; adjust paths for your hosts
cat > /tmp/jpcert-at-2026-0030-ips.txt <<'EOF'
20.210.128.125
69.10.51.162
207.241.172.54
210.149.87.120
210.149.87.33
3.112.252.14
31.76.91.2
54.95.112.6
136.85.58.5
136.117.40.140
141.11.187.186
172.86.91.7
31.59.92.155
31.56.206.187
38.244.50.120
46.8.227.73
64.44.24.195
94.183.184.98
94.183.184.254
95.182.99.112
176.65.144.71
EOF
zgrep -hFf /tmp/jpcert-at-2026-0030-ips.txt /var/log/nginx/access.log* | awk '{print $1, $4, $7, $9}' | sort | uniq -c | sort -rn | head -50

If you log JA3 or JA4 at a load balancer or CDN, search for the two fingerprints above too, and treat a match only as a lead.

2. Look for PIN and login guessing patterns. Count failed attempts per card identifier, not just per address. The exact field depends on your app; this example assumes a JSON application log with card_id and result fields.

jq -r 'select(.event=="pin_verify" and .result=="fail") | .card_id' app-*.log \
  | sort | uniq -c | awk '$1 >= 5' | sort -rn | head -50

Then look the other way: many different card IDs failing from one address, user agent or token in a short window.

jq -r 'select(.event=="pin_verify" and .result=="fail") | [.src_ip, .user_agent] | @tsv' app-*.log \
  | sort | uniq -c | sort -rn | head -50

3. Check how PINs are stored. Find every column and field that holds a PIN or a PIN derived value and confirm what it contains.

-- PostgreSQL: list columns whose name suggests PIN storage
SELECT table_schema, table_name, column_name, data_type, character_maximum_length
FROM information_schema.columns
WHERE column_name ILIKE '%pin%' OR column_name ILIKE '%passcode%'
ORDER BY 1, 2, 3;

A char(6) or short varchar column is a red flag. A 64 character hex column may be an unkeyed SHA-256, which is just as recoverable for a 6 digit value. The safer pattern computes a keyed hash with a key the database never sees. A minimal Python sketch, with the key fetched from a key management service at start up rather than stored in config:

import hmac, hashlib

def pin_tag(pin: str, card_id: str, key: bytes) -> str:
    # key comes from an HSM or KMS, never from the database or app config
    msg = f"{card_id}:{pin}".encode()
    return hmac.new(key, msg, hashlib.sha256).hexdigest()

def pin_ok(pin: str, card_id: str, stored: str, key: bytes) -> bool:
    return hmac.compare_digest(pin_tag(pin, card_id, key), stored)

Binding the card ID into the message means the same PIN on two cards produces different tags. Better still is to have the HSM perform the comparison so the key never leaves it.

4. Add per card throttling and lockout. A simple per address limit at the edge is a start; the important control is per card in the application. An Nginx example for the edge layer:

limit_req_zone $binary_remote_addr zone=pinverify:10m rate=5r/m;

location /api/card/verify {
    limit_req zone=pinverify burst=5 nodelay;
    proxy_pass http://card_backend;
}

In the application, lock a card after a small number of failures and require a support or in store step to unlock. Return the same response time and body for "unknown card" and "wrong PIN" so the endpoint does not confirm which card numbers exist.

5. Restrict admin interfaces. Mos's own list includes source IP restrictions for admin accounts. Keep management consoles behind an allowlist or off the public internet, with phishing resistant two factor authentication.

6. Know every web server and runtime version you expose. Paycloud names a web server vulnerability. Whatever product that turns out to be, the question for your estate is the same: which web server, application server, language runtime and framework version sits behind each public hostname?

# On each host
nginx -v 2>&1; apachectl -v 2>/dev/null; httpd -v 2>/dev/null
php -v 2>/dev/null | head -1
# Debian or Ubuntu packages
dpkg -l | grep -E 'nginx|apache2|php[0-9.]*-(fpm|cli)|libapache2-mod-php' | awk '{print $2, $3}'
# RHEL family
rpm -qa | grep -E '^(nginx|httpd|php)' | sort
# Containers
docker ps --format '{{.Image}}' | sort -u

7. Prepare a mass re-PIN and reissue path before you need it. Mos could force change PINs quickly. Test, in a staging copy, how long it takes to rotate PINs for a million cards, how customers learn the new PIN or reset it, and which channels break while that happens.

If you are in Japan: the reporting picture

Prepaid instruments in Japan fall under the Payment Services Act (資金決済法), which the Financial Services Agency says covers magnetic, IC and server based prepaid instruments. Paycloud says it has reported to the relevant authorities. This is not legal advice; check your own scheme's obligations with counsel.

What changed since first reports

• On 22 October the only Value Design notice was the PHP2Shell precaution. The 23 October notices describe a breach and do not mention PHP.
• Mos's notice adds the detection window, card and PIN lengths, circulation split and customer actions; the parent adds the platform total and cause.
• No issuer other than Mos has spoken publicly as of 24 October.
• JPCERT/CC's 23 October update added indicators and a case on AI driven testing frameworks. That is context, not attribution.

Open questions

• Which web server or product was vulnerable, which version, and was a fix available at the time?
• Did the attacker read stored data directly, collect it through an application interface, or both?
• Were the PINs stored in a form that could be read without a separate key?
• Did the unauthorised login attempts in the 14 to 18 October window succeed, and did they play a part in the leak?
• When did attacker activity begin?
• Which other issuers' cards are in the 291,678 or so records outside the Mos count?
• Were any balances actually spent by the attacker before PINs were rotated? Both companies say no losses have been reported so far.
• Has any of the data been offered for sale? No public source says so.

What would have helped

Lessons below are for any team that runs or buys a similar platform. They are not a judgement of Value Design, Paycloud or Mos. The companies detected suspicious access, blocked it, rotated PINs and disclosed within days, and Mos was specific about what customers should do.

Practices any team can use

• Treat card number and PIN pairs as credentials. Keyed hashes or encryption with the key outside the database, and no API that returns a PIN after issue. This is the control that most changes the impact of a database level leak.
• Throttle per card, not only per address, and make error responses uniform so the endpoint does not confirm valid card numbers.
• Retire or re-PIN unsold stock after any exposure. It carries no balance today and full value tomorrow.
• Inventory every web server and runtime in front of the platform, with version and owner, and rebuild promptly when fixes land.
• Separate admin from customer traffic and restrict admin source addresses, as Mos now plans to.
• Authorise and rate limit every API, including ones the app does not show. JPCERT's Case B describes attackers reading public app code to find internal APIs.
• Write contractor clauses before the incident: notification time, per card access logs, PIN rotation responsibility, customer messaging and audit rights.
• Watch for login and lookup bursts. Value Design's detection came from suspicious access and failed logins.

Where Safeguard fits

Safeguard works on the software you build and ship: source repositories, container images and SBOM files. If a platform like this is your own code running on open source web servers, runtimes and libraries, Safeguard helps in these ways.

• Know what you run. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image, and safeguard scan --sbom <file> reads an existing SBOM. Results are written as JSON under ./output. The platform shows which projects contain a given component and version, so when an advisory lands for a web server, a language runtime in a base image or a framework, you can list every service that carries it.
• Match and rank. Safeguard matches components against vulnerability databases, and reachability analysis ranks the vulnerable code paths your application actually calls first.
• Gate releases. Policies and gates evaluated in the platform can stop a build that carries a known vulnerable component version from reaching a public endpoint.
• Fix with approval. The Safeguard CLI's assistant can read code, edit files and run commands with your approval, using /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to move PIN checks to a keyed hash, add per card lockout and a test that proves it, or bump a base image to a patched runtime, and approve each change. safeguard exec runs the same work in CI.

Where Safeguard does not help: it cannot scan a vendor's hosted platform, so a brand buying a prepaid service gets no view of the provider's servers from it. It does not read logs, act as a WAF or rate limiter, manage HSM keys, or detect an intrusion in progress. If the vulnerable web server is a vendor appliance or hosted service you do not build, the fix must come from that vendor. Safeguard would not have prevented this incident, and we do not claim it would have.

No CVE has been published for this incident, so there is nothing to look up for it in Gold Open Source (gold.safeguard.sh), which gives free CVE intelligence with affected and fixed versions.

Common mistakes and troubleshooting

• Adding the two counts, or calling it a breach of 1.4 million people. The counts overlap, and they are cards, more than half unsold.
• Calling it a PHP2Shell breach. The notices do not say that.
• Hashing PINs with plain SHA-256. A million candidates are trivial to try.
• Rate limiting by IP only. Attackers rotate addresses; count per card.
• Treating JPCERT indicators as proof. A hit is a lead; JPCERT says some addresses may be in legitimate use, and no hit does not mean no intrusion.
• Re-PINning without briefing support. Mos listed which flows might fail and staffed a hotline first.

FAQ

What did Value Design and Mos disclose?

Paycloud Holdings and its subsidiary Value Design said on 23 October 2026 that a third party exploited a web server vulnerability and took 1,424,748 Value Card ID records with PINs and balances. Mos Food Services said the same day that 1,133,070 MOS CARD records were among the data, and that it had force changed the affected PINs.

Was my personal information taken?

Both companies say no. Mos says names, addresses, phone numbers and credit card information were not part of the leak. The leaked fields are the card number, the PIN and the balance.

Can someone spend my MOS CARD balance?

The card number and PIN together can authorise some online uses, which is why Mos changed the PINs for all leaked card numbers. After that change, the leaked PIN should no longer work. Check your usage history and call the hotline if you see anything you do not recognise.

My MOS CARD stopped working online. Why?

Because its PIN was changed. Mos says in store use, online ordering and table ordering continue, but web balance checks, new app registration and guest purchases in online ordering may fail. Call 03-3496-8322 until 26 October or 0120-395-126 from 27 October, 09:00 to 22:00.

Was this caused by PHP2Shell?

The companies have not said so. Value Design paused two other services on 22 October as a PHP2Shell precaution, but the breach notices on 23 October name only a web server vulnerability, and the suspicious activity began on 14 October, before PHP2Shell was public. The connection is timing only.

Are other brands affected?

Probably, but none has been named. The platform total exceeds the Mos count by about 291,678 records, and Value Design says it is reporting to affected client companies. If you hold another store's prepaid card, check that store's notices.

Has any money been stolen?

Paycloud says there has been no actual damage from misuse. Mos says it had received no customer reports of losses as of 23 October. Those statements may change as the investigation continues.

Why did unsold cards leak?

Platforms generate card numbers and PINs before cards are sold, and those records sit in the same system as active cards. They have no value until a card is sold and loaded, which is why rotating their PINs matters.

The vulnerable component in this incident has not been named, and it may be a web server or hosted service that only its operator can fix. For the open source web servers, runtimes and libraries you build into your own platforms, though, the gaps below are the ones to close.

Fix it without waiting for upstream

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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 Value Design, Mos or their systems. Each is a real Safeguard session, and each intro says how the same flow would apply to a team that runs its own prepaid or stored value platform.

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. On a card service you would run /scan . in the repository that verifies PINs, then ask the assistant to replace a plain PIN comparison with a keyed hash check and add a test that a card locks after five failed attempts, approving each edit and command as it runs.

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 payments team could run it on a build host inside its network and scan the images behind its balance and top up endpoints, keeping web server and runtime versions current without moving code out.

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

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A platform engineer could pick the folder holding the card API, ask for every endpoint that takes a card number to be checked for per card rate limits and uniform error responses, and approve or deny each proposed change.

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 wider month, see October 2026 security incidents and what would have helped.

Quick check

Sources

• Paycloud Holdings: Notice of unauthorised access to a system provided by a consolidated subsidiary (TDnet timely disclosure, 23 Oct 2026, Japanese PDF)
• Paycloud Holdings: Same disclosure, IR mirror (Japanese PDF)
• Value Design: Notice of unauthorised access to a system we provide (23 Oct 2026, Japanese)
• Value Design: Temporary suspension of some services in response to critical PHP vulnerabilities (22 Oct 2026, Japanese)
• Value Design: Service overview (Japanese)
• Mos Food Services: Notice of prepaid card information leak due to unauthorised access, with customer notice (TDnet, 23 Oct 2026, Japanese PDF)
• Mos Burger: Notice on MOS CARD information leak due to third party unauthorised access (23 Oct 2026, Japanese)
• Nikkei: Mos prepaid card information, 1.13 million records leaked through contractor (23 Oct 2026, Japanese)
• Security news report: MOS CARD 1,133,070 records leaked, timeline and summary (23 Oct 2026, Japanese)
• Partner press release on Value Card credit top up fraud controls (31 Aug 2026, Japanese)
• JPCERT/CC: JPCERT-AT-2026-0030, alert on recent unauthorised access at Japanese organisations (updated 23 Oct 2026, Japanese)
• JPCERT/CC: JPCERT-AT-2026-0033, alert on PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 (22 Oct 2026, Japanese)
• PHP: News archive 2026, security advisory of 21 Oct 2026
• PHP: GHSA-w8hw-w9fx-j79w, RCE via OOM corruption
• PHP: GHSA-6wmf-4rv5-p3rp, RCE via stale global state
• Financial Services Agency: Refunds of prepaid instruments under the Payment Services Act (Japanese)
• OWASP Password Storage Cheat Sheet
• OWASP Credential Stuffing Prevention Cheat Sheet

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