PHP to Motoko: move your backend to ICP

Fatal error: Allowed memory size of 134217728 bytes exhausted

Most PHP developers have seen this error. Forcing it while PHP is still setting up a request is how the first PHP2Shell bug starts. From there, an attacker can run code on the server without logging in.

Two bugs inside PHP itself. Every PHP site was exposed.

9.2severity out of 10, for both bugs

0logins needed to run code on the server

5.4+every PHP version from 5.4 on was affected

The bugs are in PHP’s engine, not your code, so WordPress, Drupal, Joomla and Magento sites were exposed too. Details leaked before the fix, an exploit tool is public, attacks started before the patch was out, and researchers now report exploitation in the wild.

Still running PHP? Find your fix.

Update to

8.5.12

Patching closes these two bugs. Moving your backend ends the dependency, so the next PHP advisory isn’t your emergency.

Read PHP’s advisory

Taken offline as a precaution on 21 October

As reported by Reuters, NOS and others. Each name links to its report.

Also offline: several Dutch judiciary websites, Dutch hospital websites, the sites of the five largest Dutch political parties, 13 of the 25 Dutch safety regions, and universities across Europe.

The advisories, straight from the source.

37 publications from PHP’s maintainers, government security agencies, Linux distributions, hosting companies and security researchers. We opened every link, and each entry shows the page’s own title.

Published on 20 and 21 October 2026. Some were written before the patches shipped, so check each one for updates.

Stop owning the layers that break.

On ICP your backend is Motoko running in a sandboxed canister. The network runs and upgrades everything beneath it.

No PHP engine to attack

Both bugs live inside PHP. Motoko compiles to WebAssembly, so there’s nothing for them to exploit. A call that runs out of memory just stops, and its changes are rolled back.

Nothing for you to patch

No PHP runtime, web server or operating system of yours. The network upgrades its own node software through its governance system, the NNS.

Contained by design

Each canister runs in its own WebAssembly sandbox with its own memory. There’s no shell to open and no server filesystem underneath.

What it won’t do: fix logic bugs or a missing permission check on its own. The skill makes your agent check the caller on every method that changes data.

Six steps. You approve the two that matter.

Your agent does the work. Your frontend can stay where it is today, or move to ICP too.

01
Inventory
Every page, form, table, upload folder, scheduled job and integration goes into a checklist.
02
Approve the plan
What moves where, and what can’t move as-is. Nothing changes until you sign off.
You approve
03
Build the backend
Your PHP logic becomes Motoko on ICP. Old links keep working, the .php ones included.
04
Move the data
Exported, imported in batches and checked against the old database, table by table.
05
Move the users
Sign-in moves to Internet Identity. Accounts are linked only with verified proof.
06
Switch over
Both run side by side, then a final sync, your domain points to ICP and every journey is checked live.
You approve

One skill. Your whole backend.

migrating-php-apps works with Claude, Codex, Cursor or any coding agent. It moves a WordPress, Drupal, Joomla, Magento, Laravel, Symfony or plain PHP app to Motoko on ICP, with its data, users and links, and stops for your approval before anything irreversible.

Tested end to end on a real PHP site: database export and import, safe re-runs, access control, accented text and emoji, old links, and upgrades with the data in place.

An inventory script that maps the whole app in one run
Export and import tools, tested on real data
A tested Motoko backend to start from
Old-link handling, .php URLs included
Platform notes for WordPress, Drupal, Joomla, Magento, Laravel and Symfony
The workflow and the pitfalls that break migrations

Download the skill Read the skill

your coding agentmigrating-php-apps

1. Add the official ICP skills alongside it

npx skills add dfinity/icskills

2. Where should your frontend live?

On ICP tooBackend and frontend move Keep our current hostOnly the backend moves

3. Give your agent this prompt

Load the migrating-php-apps skill from https://kwnju-pyaaa-aaaao-qqkta-cai.icp.net/skills/migrating-php-apps/SKILL.md and the ICP skills listed at https://skills.internetcomputer.org/llms.txt. Then move this PHP app to the Internet Computer: the backend in Motoko and the frontend on ICP, with its data, users and links. Inventory everything first, propose the plan, and wait for my approval before changing anything.

Your agent stops after the inventory and waits for you.

Same feature. No PHP underneath.

One PHP file and its Motoko version. The skill applies the same move to every route, table and job in your app.

save.phpBefore: PHP

<?php
session_start();

if (!isset($_SESSION['user_id'])) {
    http_response_code(401);
    exit;
}

$pdo = new PDO($dsn, $dbUser, $dbPass);
$stmt = $pdo->prepare(
    'REPLACE INTO notes (user_id, body) VALUES (?, ?)'
);
$stmt->execute([$_SESSION['user_id'], $_POST['body']]);

Needs a session store and a database server, plus a web server, PHP-FPM and an operating system to keep patched.

main.moAfter: Motoko

import Map "mo:core/Map";
import Principal "mo:core/Principal";

actor Notes {
  type Saved = { #saved; #signInFirst };

  let notes = Map.empty<Principal, Text>();

  public shared ({ caller }) func save(body : Text) : async Saved {
    if (caller.isAnonymous()) return #signInFirst;
    notes.add(caller, body);
    #saved
  };
};

caller comes from the request’s signature, not a session cookie, and notes persists without a database. Compiles with Motoko 2.0.0.

Before you move.

Do we have to move the frontend too?

No. Your rebuilt frontend can stay on its current host and call the backend on ICP, or move to ICP as well. The skill covers both. If it stays where it is, that host remains part of what you have to secure.

What happens to our users and their logins?

Sign-in moves to Internet Identity: passkeys, Google, Apple or Microsoft accounts, or your organization’s own sign-in. Old password hashes are not copied over. Existing accounts are linked only with verified proof, such as a verified email address.

Can we keep our domain and our links?

Yes. Your domain points to ICP at switch-over, and old links keep working: pages are rebuilt at their old addresses, renamed pages redirect, and old .php links are forwarded.

Where does our data live?

In your backend canister on the Internet Computer. For data-residency rules you can place it on a subnet whose nodes are in the region you need, or on your organization’s own cloud engine. The network protects data against tampering but does not encrypt it by default, so the skill keeps secrets out of the backend and flags personal data for a decision.

What does it cost to run?

Canisters pay for computation and storage in cycles, which you can buy with ICP or by card. The cost depends on your data and traffic; current prices are in the cycle costs reference. This site runs on ICP and its first cycles cost five dollars.

What if something goes wrong during the move?

Your PHP site keeps running until the switch-over, the new backend is snapshotted before risky steps so it can be restored, and nothing irreversible happens without your approval.

Patch today. Move your backend next.

Give your coding agent the skill and the prompt, and start with the inventory.

Get the migration skill How it works

Two bugs inside PHP itself. Every PHP site was exposed.

Taken offline as a precaution on 21 October

The advisories, straight from the source.

Stop owning the layers that break.

No PHP engine to attack

Nothing for you to patch

Contained by design

Six steps. You approve the two that matter.

Inventory

Approve the plan

Build the backend

Move the data

Move the users

Switch over

One skill. Your whole backend.

Same feature. No PHP underneath.

Before you move.

Patch today. Move your backend next.