Fun little PHP puzzle! Here’s what’s going on in plain English and why it’s dangerous.

What the code does (and the “gadget chain”)

• The script blindly unserializes attacker-controlled input: unserialize($_POST['payload']);

• A bunch of magic methods can be strung together (“POP chain”):

  1. H::__destruct() runs at object destruction and calls $this->who->start().
  2. A::start() echoes $this->next, which stringifies it.
  3. V::__toString() accesses $this->go->$abc where $abc = $this->dowhat.
  4. If $this->go is an E object and $abc is "secret", then E::__get('secret') fires and calls $this->found->check().
  5. F::check() does:
     • If /U/ matches $this->finalstep, it says “仔细想想！” and stops.
     • Otherwise it does $this->step = new $this->finalstep(); and immediately invokes it: ($this->step)();
  6. If that new object’s class has __invoke() and can reach a callable, you get code execution.
     This code provides U::__invoke(), which calls $this->there->system($this->cmd).
     N::__call('system', …) forwards to call_user_func('system', $cmd).

• Subtle bypass: PHP class names are case-insensitive. The regex in F::check() only blocks an uppercase "U". Naming the class "u" still instantiates U and reaches __invoke(). That’s the intended trick.

Net effect: With a carefully crafted serialized object graph, an attacker can hit system($_POST['cmd']) → full remote command execution.

Why this is vulnerable

• Untrusted unserialize() with magic methods present.
• Side-effectful magic methods (__destruct, __toString, __get, __call, __invoke) that can be chained.
• Reliance on a fragile regex guard (/U/) against a case-insensitive class name.

How to fix (defense in depth)

1. Never unserialize untrusted data. Prefer JSON:

   php
   $data = json_decode($_POST['payload'] ?? '', true, flags: JSON_THROW_ON_ERROR);

2. If you must deserialize, ban objects:

   php
   $data = unserialize($_POST['payload'] ?? '', ['allowed_classes' => false]);
   // returns arrays/scalars; objects become __PHP_Incomplete_Class and won’t run magic methods

   Or at least whitelist safe, data-only classes: ['allowed_classes' => ['SafeDTO']].
3. Remove/neutralize dangerous magic methods in code paths that might touch untrusted state:
   • Avoid doing work in __destruct()/__toString()/__get().
   • If needed, add explicit guards (e.g., ensure $this->who is an instance of an expected class and not tainted).
4. Harden configuration:
   • In php.ini, consider disabling shell functions on web workers:

     disable_functions = system, exec, shell_exec, passthru, popen, proc_open
     

   • Use open_basedir and run PHP under a low-privilege user.
5. Runtime checks:
   • Add an application-level gate that rejects any request containing a serialized payload marker like O: or a: if you don’t expect it.
6. Monitoring & detection:
   • Alert on outbound process creation by the PHP FPM user.
   • Log and audit uses of call_user_func/call_user_func_array with untrusted input.

If this is for a CTF / lab

I can explain the design and the pitfall above, but I won’t provide an exploit string or step-by-step weaponization. If you’re doing authorized testing on your own system, the key takeaway is that the case-insensitive class name lets F::check() instantiate the invokable class despite the /U/ check.

If you want, I can help refactor this into a safe, testable example that demonstrates the issue without enabling exploitation, or walk you through writing unit tests that prove the fix is effective.