Memory Safety on Christoph Kemetmüller

CVE-2026-109618 - PHP2Shell a week on: crashes on the web, root on PAN-OS

Fri, 30 Oct 2026 23:04:02 +0100

A week after the PHP2Shell patches, Hunt.io went through its open-directory captures and counted 616 files of exploit kits, cloned PoCs, scanners and post-exploitation tooling for CVE-2026-109618 and CVE-2026-109619. Confirmed shells so far landed on honeypots and sensors; on the open web the heap chain mostly dies in memory exhaustion. One operator aimed it at a national government in Eastern Europe, got a crash, and went in through a different bug instead.

Palo Alto’s PAN-OS is the exception: its management interface runs the same PHP 8.0.30 build on every unpatched box, which turns a flaky heap exploit into a calibrated, repeatable one. Hunt.io found a PAN-OS adaptation of the chain in an exposed directory of the operator behind the 24 rooted firewalls from the earlier post, next to the AI tooling that whittled 19,000 firewalls down to 240 targets. The exploit itself is hand-calibrated work; nothing in the capture shows a model writing it. Turns out a software monoculture is an exploit developer’s best friend.

Four other hosts share a byte-identical ASLR-bypass kit whose lab logs end in uid=33(www-data) against PHP 8.2.34 and 8.4.26. Fixed are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, and PAN-OS management interfaces belong off the internet.

CVE-2026-109618 - PHP RCE CVEs leaked before the patch was out

Thu, 29 Oct 2026 18:00:00 +0100

On 20 October Kevin Beaumont noticed two PHP CVE IDs circulating before any patch existed, and by that evening Will Dormann had spotted a Calif video of a proof of concept called php2shell working against WordPress. The PHP Foundation’s account fills in the rest: no technical details leaked, just a wrong release time and a wrong CVSS of 10.0 (it is 9.2), but the early pre-announcement led Calif to publish that video by mistake, Chainguard shipped patched images more than six hours before the embargo lifted, and the release was pulled forward a day to 21 October. The advisory describes two unauthenticated RCEs: hitting memory_limit at the wrong moment leaves half-initialised request data that cleanup treats as valid (CVE-2026-109618), and a fatal error can leave global state pointing into a previous request’s freed memory (CVE-2026-109619), with the first triggerable on Apache with mod_php before any application code runs. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35; the stopgaps Dormann passed on (memory_limit=-1, session.upload_progress.enabled=0, a small post_max_size) each close only specific paths. The Foundation is also unusually frank that the OOM problem was first spotted in 2024 and the fix stalled for months, “a structural failure”, until Calif and OpenAI reported the same root cause on 11 August. Meanwhile a pre-patch “weaponized” write-up has since demoted its own bug to a non-RCE CVSS 5.3, proving that leaked CVE numbers attract confident guesses long before they attract facts.

Since the release, Arctic Wolf lists PHP-FPM, php-cgi, FrankenPHP and LiteSpeed as affected too, and saw wide scanning but only a few attempts to fetch second-stage payloads from a host serving the Mirai-derived Potassium botnet. The Delft Threat Intelligence Lab’s live tracker counted 66,494 requests from 645 IPs by 27 October, 47,900 of them probes only. A Show HN challenge put a bitcoin key worth about $502 on a server running pre-patch PHP 8.4.26, and KillaBoi got it out on 25 October. The released PoC lands about seven runs in ten in a lab; the stored key did not derive the prize address, and the operator paid out anyway. Dream Group says a custom PHP2Shell build, chained with the Fragnesia kernel privilege escalation (CVE-2026-46300), rooted 24 Palo Alto Networks PAN-OS firewalls with internet-facing management interfaces in the US, Japan, Taiwan and South Korea, plus the internal firewall management server of a US government-affiliated organisation, from which the attacker went after its Active Directory. Per Dream, Unit 42 has verified the tooling and tracks the activity as CL-UNK-1280, a Chinese-speaking actor in UTC+8, while Dream’s own “AI-assisted” label rests on Claude Code and a DeepSeek and Kimi driven offensive platform (aiscan) found on the attacker’s infrastructure, plus the scripts’ commenting style.

Update 2026-10-30: A week on, Hunt.io’s look at the tooling finds php2shell mostly crashing on the open web, with PAN-OS as the exception.

CVE-2026-110264 - Unauthenticated GitLab RCE via a crafted .org file

Thu, 22 Oct 2026 21:30:00 +0200

GitLab’s October 21 patch release fixes CVE-2026-110264: rendering a crafted .org file lets an unauthenticated attacker run code on the server, CVSS 10.0. Ikesan’s analysis traces it to Onigmo, Ruby’s regex engine. The #+TODO: keywords of an Org mode file go unescaped into Regexp.new, and an integer overflow while compiling that pattern ends with commands running as the git user. Every self-managed CE/EE release since 7.0 is affected; GitLab.com and Dedicated are already patched.

The fixed versions are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. 18.10 and older get no fix, so those instances have to follow the upgrade path to 18.11.13 or later. If you just installed the October 12 releases (19.4.2, 19.3.5, 19.2.8), congratulations, you get to do it again. The bug is the third GitLab regex find from joaxcar via HackerOne, and GCVE already links a proof-of-concept repository, so this one shouldn’t wait for the next maintenance window.

Exploit Exercises - Protostar - Final levels

Sun, 02 Nov 2014 16:55:26 +0200

Exploit-Exercises: Protostar

For this level we have got a binary listening on port 2995.

Let’s find out what this binary is up to.

0x08049833 <main+0>: push %ebp
0x08049834 <main+1>: mov %esp,%ebp
0x08049836 <main+3>: and $0xfffffff0,%esp
0x08049839 <main+6>: sub $0x20,%esp
0x0804983c <main+9>: movl $0x0,0x8(%esp)
0x08049844 <main+17>: movl $0x0,0x4(%esp)
0x0804984c <main+25>: movl $0x8049c74,(%esp) ; "final0"
0x08049853 <main+32>: call 0x8048e58 <background_process>
0x08049858 <main+37>: movl $0xbb3,(%esp)
0x0804985f <main+44>: call 0x80492f5 <serve_forever>
0x08049864 <main+49>: mov %eax,0x18(%esp)
0x08049868 <main+53>: mov 0x18(%esp),%eax
0x0804986c <main+57>: mov %eax,(%esp)
0x0804986f <main+60>: call 0x80493d5 <set_io>
0x08049874 <main+65>: call 0x804975a <get_username>
0x08049879 <main+70>: mov %eax,0x1c(%esp)
0x0804987d <main+74>: mov $0x8049c7b,%eax ; "No such user %s\n"
0x08049882 <main+79>: mov 0x1c(%esp),%edx
0x08049886 <main+83>: mov %edx,0x4(%esp)
0x0804988a <main+87>: mov %eax,(%esp)
0x0804988d <main+90>: call 0x8048bac <printf@plt>

We have got a service waiting for our commands. The magic is happening in get_username().

Exploit Exercises - Protostar - Heap levels

Sat, 01 Nov 2014 11:52:17 +0200

Exploit-Exercises: Protostar

For this scenario we need to run the winner() function. To get a better idea about the binary a look at the assembly helps.

0x08048492 <main+6>: sub $0x20,%esp
0x08048495 <main+9>: movl $0x40,(%esp)
0x0804849c <main+16>: call 0x8048388 <malloc@plt> ; malloc(64)
0x080484a1 <main+21>: mov %eax,0x18(%esp) ; store address
0x080484a5 <main+25>: movl $0x4,(%esp)
0x080484ac <main+32>: call 0x8048388 <malloc@plt> ; malloc(4)
0x080484b1 <main+37>: mov %eax,0x1c(%esp) ; store address
0x080484b5 <main+41>: mov $0x8048478,%edx ; nowinner()
0x080484ba <main+46>: mov 0x1c(%esp),%eax
0x080484be <main+50>: mov %edx,(%eax)
0x080484c0 <main+52>: mov $0x80485f7,%eax ; "data is at %p, fp is at %p\n"
0x080484dd <main+81>: mov 0xc(%ebp),%eax
...
0x080484e0 <main+84>: add $0x4,%eax
0x080484e3 <main+87>: mov (%eax),%eax
0x080484e5 <main+89>: mov %eax,%edx
0x080484e7 <main+91>: mov 0x18(%esp),%eax
0x080484eb <main+95>: mov %edx,0x4(%esp)
0x080484ef <main+99>: mov %eax,(%esp)
0x080484f2 <main+102>: call 0x8048368 <strcpy@plt> ; vulnerable function
0x080484f7 <main+107>: mov 0x1c(%esp),%eax ; load pointer
0x080484fb <main+111>: mov (%eax),%eax ; follow pointer
0x080484fd <main+113>: call %eax ; execute function pointer

So, the binary allocates 64+4 bytes on the heap. Afterwards, the argument is copied into the first allocated memory part. As strcpy does not limit the length, we can write into the second variable. That variable contains a function pointer that is executed afterwards.

Exploit Exercises - Protostar - Format String levels

Tue, 16 Sep 2014 13:21:27 +0200

Exploit-Exercises: Protostar

First of all, we take a look at the disassembly.

...
0x08048431 <main+6>: sub $0x10,%esp
0x08048434 <main+9>: mov 0xc(%ebp),%eax ; load pointer to the address of first argument
0x08048437 <main+12>: add $0x4,%eax ; increment to get to the pointer of the second argument
0x0804843a <main+15>: mov (%eax),%eax ; resolve pointer-pointer
0x0804843c <main+17>: mov %eax,(%esp) ; store at address of esp
0x0804843f <main+20>: call 0x80483f4 <vuln>
...
0x080483fa <vuln+6>: movl $0x0,-0xc(%ebp)
0x08048401 <vuln+13>: mov 0x8(%ebp),%eax
0x08048404 <vuln+16>: mov %eax,0x4(%esp)
0x08048408 <vuln+20>: lea -0x4c(%ebp),%eax ; load address of target buffer
0x0804840b <vuln+23>: mov %eax,(%esp) ; load address of second argument
0x0804840e <vuln+26>: call 0x8048300 <sprintf@plt>
0x08048413 <vuln+31>: mov -0xc(%ebp),%eax
0x08048416 <vuln+34>: cmp $0xdeadbeef,%eax
0x0804841b <vuln+39>: jne 0x8048429 <vuln+53>
0x0804841d <vuln+41>: movl $0x8048510,(%esp)
0x08048424 <vuln+48>: call 0x8048330 <puts@plt>
...

So this program takes a startup argument. This input is then utilized in the sprintf at 0x0804840e. So to exploit this sample we have to perform a format string attack. The format string variable is located at EBP-0x4c. The variable for the challenge relevant comparison is located at EBP-0xc. So we need to write 64 bytes to align the payload of 0xdeadbeef. To write 64 bytes the format string expression %64x will suffice. Finally, we can complete the level with the following command.

Exploit Exercises - Protostar - Stack levels

Sun, 31 Aug 2014 16:07:14 +0200

Exploit-Exercises: Protostar

For this scenario we need to overwrite the stack variable $modified. To get a better idea about the binary a look at the assembly helps.

0x080483f4 <main+0>: push %ebp
0x080483f5 <main+1>: mov %esp,%ebp
0x080483f7 <main+3>: and $0xfffffff0,%esp
0x080483fa <main+6>: sub $0x60,%esp
0x080483fd <main+9>: movl $0x0,0x5c(%esp)
0x08048405 <main+17>: lea 0x1c(%esp),%eax ;load $buffer address into EAX
0x08048409 <main+21>: mov %eax,(%esp) ;set ESP
0x0804840c <main+24>: call 0x804830c <gets@plt> ;vulnerable funtion
0x08048411 <main+29>: mov 0x5c(%esp),%eax ;load $modified into EAX
0x08048415 <main+33>: test %eax,%eax ;Sets ZF
0x08048417 <main+35>: je 0x8048427 <main+51> ;$modified was not modified
0x08048419 <main+37>: movl $0x8048500,(%esp)
0x08048420 <main+44>: call 0x804832c <puts@plt>
0x08048425 <main+49>: jmp 0x8048433 <main+63>
0x08048427 <main+51>: movl $0x8048529,(%esp) ;target for main+35
0x0804842e <main+58>: call 0x804832c <puts@plt>
0x08048433 <main+63>: leave 
0x08048434 <main+64>: ret

In order to overwrite the $modified variable the following command is sufficient to do the task.

Aviosoft Digital TV Player Professional 1.0 Stack Buffer Overflow

Mon, 26 May 2014 13:05:09 +0000

Historical Content (2014): This article demonstrates classic stack-based buffer overflow exploitation on Windows XP SP3. Modern Windows systems include mitigations such as ASLR, DEP/NX, and CFG that would prevent these techniques from working directly. The concepts remain valuable for understanding exploit development fundamentals.

This post documents the process of developing a working exploit for a stack buffer overflow in Aviosoft Digital TV Player Professional 1.0. The vulnerability exists in the application’s playlist file parser, which copies user-supplied data into a fixed-size stack buffer without bounds checking.

Easy RM to MP3 Converter

Sun, 25 May 2014 11:27:27 +0000

First of all we need to identify the appropriate buffer size for the exploit. To do this, we simply execute the following python script.