Overview
This Sherlock investigates the exploitation of an Apache and PHP web server. The attacker chained two PHP memory-handling vulnerabilities, using stalled multipart uploads to fill the worker pool and a leaked heap address to reach remote code execution. The evidence is the Apache logs and a packet capture, which show the whole chain from the first anomalous request to the commands the attacker ran.
Task 1: PHP version
What version of PHP was running on the server?
Upon unzipping the archive, we have 4 files:
./logs
./logs/other_vhosts_access.log
./logs/error.log
./logs/access.log
./Capture.pcapI searched the logs for the PHP/ banner that Apache writes in its version string:
logs ➜ grep -rin "php/" . | tail -n 2
Identified PHP Version
Answer: 8.4.26
Task 2: First anomalous request
At what exact date and time did the attacker send the first request of the exploitation attempt?
Looking up CVEs for this PHP version led to a Trellix write-up of two chained vulnerabilities:
Understanding Vulnerability
- CVE-2026-109618 is a flaw in how PHP handles running out of memory. The request is cut off while its internal data is only half set up, and the cleanup trusts that data.
- CVE-2026-109619 is a use-after-free. Request state survives after its memory is freed and is reused by a later request on the same worker. The usual trigger is a multipart POST that carries a
PHP_SESSION_UPLOAD_PROGRESSfield, which works against the default configuration.
That gives me three things to look for:
- Multipart POST requests with
PHP_SESSION_UPLOAD_PROGRESSand a very largePHPSESSIDcookie. - PHP error log lines with “Allowed memory size” and “exhausted” together with “Unknown on line 0”. That combination means the failure happened during request startup, not inside a script.
- Web server processes starting shells,
wgetorcurl, or new.phpfiles and ELF binaries appearing in/tmpor the web root.
Many requests in access.log fit the first pattern. These requests end with a response size of 0 and empty referrer and user-agent fields (0 "-" "-"), so I filtered on that and sorted by time:
logs ➜ grep -F '0 "-" "-"' access.log | sort | head -n 5 
First Anomalous Request Identified
Answer: 2026-10-28 08:42:52
Task 3: Stalled upload boundary
To occupy the worker pool, the exploit sent stalled multipart uploads. What is the boundary separator used in these requests?
I looked at the capture around the time of the first anomalous requests in Wireshark:
frame.time >= "2026-10-28 08:42:52" && frame.time <= "2026-10-28 08:42:53"The multipart Content-Type header shows the boundary.
Boundary Separator Identified
Answer: ZZZZZZZZZZ
Task 4: Number of occupied workers
The exploit deliberately occupied the Apache worker pool with stalled multipart uploads, forcing the exploit’s requests to land on the same single worker so that memory is leaked from the same process heap. How many workers did the exploit deliberately occupy?
The exploit stalled workers so that its later requests land on the same worker and leak memory from the same heap. Each stalled upload leaves a line with the boundary value in error.log and the process ID of its worker. Counting the unique process IDs gives the number of workers:
logs ➜ grep 'ZZZZZZZZZZ' error.log | grep -oP '\[pid \K[0-9]+' | sort -u | wc -lAnswer: 149
Task 5: CVEs chained for RCE
Which two CVEs are chained together to achieve remote code execution?
The CVE write-up from Task 2 names both:
CVE Information Page
Answer: CVE-2026-109618, CVE-2026-109619
Task 6: PHP memory limit
The exploit used the Out of Memory (OOM) primitive during exploitation. What was the PHP memory limit, in bytes, that the exploit exhausted to trigger the out-of-memory vulnerability?
The “Allowed memory size” lines in error.log state the limit:
logs ➜ grep -iE 'memory size exhausted|Allowed memory size' error.log
Memory Limit Identified
Answer: 134217728
Task 7: Cookie used to leak data
The exploit leaks heap memory from the server to retrieve a heap address value, which is then used to facilitate the remote code execution process. What is the name of the cookie through which this leaked data is delivered to the attacker?
The leak is delivered through an oversized PHPSESSID cookie.
Answer: PHPSESSID
Task 8: When the attacker gained RCE
When did the attacker achieve remote code execution capability?
Web servers usually run as www-data. Once the attacker can execute code, traffic from the shell contains that user name, so I searched the capture for it:
tcp contains "www-data"
Identified Attacker RCE Time
Answer: 2026-10-28 08:43:02
Task 9: Port of the RCE shell
What port was used for the remote code execution shell?
The same filter shows the connection that carries the shell:
Port Identified
Answer: 4444
Task 10: Second worker crash
When did the exploit cause a second crash of an Apache worker process?
When a worker crashes, Apache logs a segmentation fault. I searched for it:
dOOMs Day ➜ grep fault logs/error.log 
Identified Segmentation Fault
Answer: 2026-10-28 08:47:42
Task 11: Command that searched for databases
What is the command executed to find database files on the compromised server?
To search for files on Linux you use find, so I filtered the capture on it. One packet matched:
tcp contains "find"
Identified Command Part 1
Following the TCP stream shows the whole command:
Identified Command Part 2
Answer: find / -type f \( -name "*.sqlite" -o -name "*.sqlite3" -o -name "*.db" -o -name "*.db3" -o -name "*.s3db" -o -name "*.sl3" \) 2>/dev/null