DEV Community: Can Türk

Reverse Development in the Age of AI

Can Türk — Thu, 22 Oct 2026 13:00:00 +0000

After a long time, I sat down to write again, and within the first few minutes I noticed something strange: I can't think as well as I used to. Or rather, the thoughts are still there. There are dozens of them in my head, constantly fighting with each other, but I struggle to pull them together the way I once did and turn them into a few pages of writing. I got my coffee, sat down at the desk, and thought for a long while about what to write. I used to be able to rattle off pages about any topic that came to mind; these days, just gathering what comes to mind has become an effort in itself. Thoughts used to turn into sentences on their own. Now, before I can build a sentence, I first have to catch the thought.

Then I started thinking about why. As someone who used to read books regularly, I tried to pin down what it was that had both derailed my reading habit and slowed down my writing. As I kept thinking, a few items actually surfaced in my mind. Here they are as an unordered, incomplete list: attention spans shrinking under fast social media; forgetfulness, lack of discipline, or the absence of reward; and finally, the reverse development that has come with the rise of AI.

Maybe the problem is me. Or maybe we're all a little like this now.

Attention spans shrinking under fast social media

First, let me explain what I mean by "fast social media." This trend first entered our lives in 2013 with the Vine app. Back then, with this approach of watching video after video in a fast, endless loop, we didn't realize that short, vertical video creation would come to shape how media is perceived in the future. In 2014, an app called Musical.ly carried it forward. Then came TikTok, which would become the Hiroshima of social media, spreading in China in 2016 and around the world in 2017. TikTok became the single biggest force in carrying this trend to the whole world and to every age group.

Of course, when Instagram and YouTube then copied this format for themselves, the direction of content creation and consumption changed irreversibly. Naturally, the users are happy: they have something to keep their minds busy, something that releases fake dopamine and lets them masturbate on happiness. The platforms are happy: they're increasing how long users stay in the app. The advertisers are happy: they've found a new, effective way to advertise. Even adult content companies, wanting their share of all this happiness, started making 7-second porn clips. Everyone is happy. Except us, losing hours of our lives without fully understanding what's going on.

This new kind of media has done irreversible damage to the human mind. People who at first assumed that, since this was about watching short videos, it would eat up less of their time, started finding themselves caught in a spiral that lasted for hours. Humanity was now making time for short-form content on the bus, in traffic, in the elevator, even in the bathroom. Videos that are short on their own, once linked together in an endless chain, began taking up hours, and came to occupy more of people's lives than even sleep, one of our most basic needs.

This consumption of short content back to back, and even exposure to several pieces of content at once, has seriously lowered people's threshold for attention and focus. As a result, people who created text-based content either moved to producing both text and video, or abandoned text-based content altogether. Because nobody reads a long piece of text anymore, and worse, nobody can find the energy to write one either. And this is where the transition to the second stage happens.

Forgetfulness, lack of discipline, or the absence of reward

As I said, the human brain now moves very fast. And related to that, forgetfulness has reached its peak. We forget almost everything. The work we've done, the work we're going to do, and the promises we've made to ourselves. We're surrounded by millions of people who tell themselves every New Year, "This year I'm going to do this regularly," only to forget that promise a few weeks later. Along with this forgetfulness comes a lack of discipline. Or maybe what I think of as forgetfulness is just a lack of discipline itself. But one thing is certain: the two feed each other.

Then there's the reward mechanism, which kicks in even for people who aren't forgetful and are disciplined. The new system no longer rewards you. Blogs don't make money the way they used to, and readership for written content has hit rock bottom. In a world where books are listened to rather than read, nobody reads text to learn something or to hear about a memory; they choose video instead, which appeals to the eye. I won't lie, that's mostly what I do too. And when I try not to, I can't find anyone who still keeps a blog regularly these days. Maybe that's my fault. When was the last time you read a blog? When did you last email a blog's author? When did you last leave a comment under a post and argue with the person who wrote it? It's rare.

On the internet of the 2000s, you'd visit a blog. You'd step into someone's world. You'd read what they wrote, maybe leave a comment, maybe come back the next day. Maybe you'd add it to your RSS. Maybe you'd become friends with that person over the internet without ever meeting them. Now the algorithm decides who you get to see. And because algorithms favor visual content over written content, you can't even get in front of the people who would read you. Since the system doesn't reward you, no matter how disciplined you are, you start writing less and less often, and eventually you stop writing altogether.

And even if you manage to keep going, the final blow is dealt by LLMs, the most powerful weapons of the AI age. Who's going to read a technical blog post when they could just learn the thing from an LLM?

The rise of AI and reverse development

We've come to the last item, and in my view, the biggest danger. People have started using AI even for blog posts, which I believe should be completely personal and belong to humans alone. They give it a topic, say "Write it like this," and share content that is entirely AI-generated as if it were their own. It's like this everywhere: on video platforms, in text-based media, in social media content. At this point, where the dead internet theory is starting to come true, a blog post full of typos and clumsy, inverted sentences is a pearl in my eyes. In this boundless pollution of artificial data, I believe the natural, neuron-based mistakes made with emotion are what's valuable.

AI has been a very important breakthrough. If you ask me, it's the biggest leap since the Industrial Revolution. But every revolution carries its own evil within it. People are drifting toward an era in which they won't be able to tell whether a piece of information is true or not. Let's keep up with the times, let's use AI, let's burn through millions of tokens, but let's not surrender our souls and our reality to it. For reading a summary of something, for writing programs, for generating images, AI is a huge blessing. But at that point, I think it should remain an assistant. We shouldn't put it in the place of a human.

For example, there's this developer, someone I'd never heard of before, who declared himself a master once AI came along. The software he writes and the X posts he puts out (formerly known as tweets) are entirely AI-generated. He has surrendered himself completely; he's gone blind. I'm sure he even asks AI whether people's criticisms are valid, and what insults to throw back at them. I don't want to name him and embarrass him, but I hope he reads this post and starts remembering that he's human before he loses the last neuron he has left to think and question with.

Because the issue isn't AI taking us over. The issue is us handing ourselves over to it of our own free will.

If this post has somehow landed in front of you and you've read it all the way to the last sentence, please know that this content is entirely the product of a human brain. I'm deliberately not fixing my typos. Things that belong to humans are beautiful even with their mistakes.

Maybe some of the sentences in this post are longer than they need to be. Maybe some of my thoughts are wrong. Maybe I'm being unfair on some points. Maybe a few years from now I'll believe the exact opposite of what I'm arguing today. But all of it is mine. And I think that's one of the most valuable things on the internet today. Let's use AI to generate images, but let our ideas remain our own.

Hoping to keep writing, even if only now and then, I'll wrap up this post that carries the spirit of 2000s blogging. If you want these posts and thoughts to continue, remember that the system has to reward them. So whichever platform you're reading this on, please don't hesitate to follow me there, visit my personal site, and say hello.

Because maybe the best part of blogging again is that you're not writing for an algorithm, but directly for another human being.

Take care of yourselves.

Originally published at iamcanturk.dev.

October 21 Security Roundup: PHP2Shell's Backstory, Java, HTTP/3, Node, Railway and OVH

Can Türk — Thu, 22 Oct 2026 11:04:32 +0000

21 October 2026 was a long day for security teams. PHP patched two critical vulnerabilities, Oracle issued an out-of-band alert for Java, Node.js closed ten vulnerabilities and Railway disclosed access to customer secrets. The day before, OVHcloud's command-line tool had been shipped with malware.

This post is a roundup of that day. Each section says what happened and what you should do. The technical deep dive on the PHP bugs is in a separate post: Two Critical RCEs in PHP: CVE-2026-109618 and CVE-2026-109619. Video: Pixel Shorts ¬∑ Yesterday, in short.

At a glance

Topic	Identifier	What to do
PHP2Shell	CVE-2026-109618, CVE-2026-109619 ¬∑ CVSS v4.0 9.2	Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart PHP-FPM and Apache
Java (JSSE)	CVE-2026-91403 ¬∑ CVSS 9.1	Update the JDK or replace `blocked.certs`
HTTP/3 QPACK	CVE-2025-64702 (quic-go), CVE-2026-12523 (quiche)	quic-go 0.57.0, quiche 0.29.3, lsquic 4.9.0; disable HTTP/3 on Bun
Node.js	10 CVEs, worst is CVE-2026-111497 (Brotli, RCE)	22.23.4, 24.22.1 or 26.12.1
Railway	Incident QH8L8B3E	Rotate every environment variable and API token stored on Railway
OVHcloud CLI	0.11.0 ‚Äì 0.15.0 (19 October)	If you installed it that day, rotate every secret on disk and use 0.16.0

PHP2Shell: from 2024 to today

2024: the first sign

According to the PHP Foundation, the first signs appeared in 2024. A PHP core developer contracted by the Foundation noticed the out-of-memory (OOM) problem while fixing another issue from Quarkslab's 2024 audit. No concrete attack vector was found at the time, and issues with clear impact took priority.

In the following months the security team drafted several fixes. As The Next Web reports, one broke backward compatibility, one introduced a new DoS risk and one required changes across thousands of extensions. The small, consensus-driven team could not pick one. The Foundation called this a "structural failure" and says decisions will now be made by majority.

August 2026: rediscovered with AI

This summer two teams independently found a working attack path:

Calif: According to the Wall Street Journal, a Calif researcher found the flaw with GPT-5.6 Sol as part of OpenAI's "Patch the Planet" program.
Wiz Research: According to Wiz, the first finding came on 19 August, unauthenticated RCE was confirmed against Drupal and WordPress on 20‚Äì21 August, and the reports went to PHP on 24 August. Wiz says it used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol.

PHP acknowledged the reports on 21 September and started a coordinated fix.

17‚Äì21 October: the leak and the patch

Date	What happened
17 October	Amazon Threat Intelligence saw a PHP2Shell attempt in its MadPot honeypots, four days before disclosure. How the actor got the details is unknown.
20 October	The CVE IDs circulated on forums and social media with a wrong release time and a wrong score (10.0). PHP moved its pre-announcement to 19:30 UTC.
20 October	Calif mistakenly published a video of its working PoC. The Foundation says it revealed "limited additional details".
21 October 07:41 UTC	Chainguard published patched images more than six hours early. The Foundation said this disregarded coordinated disclosure.
21 October 14:00 UTC	8.5.12, 8.4.27, 8.3.36 and 8.2.35 released.
21 October	watchTowr saw exploitation attempts in its honeypots; Cloudflare saw attack traffic against customers and shipped WAF rules. No confirmed successful compromise has been reported.

Names of alleged leakers are circulating on social media. I could not find them in any primary source, so they are not here.

How to apply the PHP fix correctly

1. Check the PHP your site actually runs

If a server has several PHP versions, php -v in the terminal shows only the default CLI. The PHP-FPM pool or Apache module serving your site can be a different version.

php -v                 # CLI PHP
php-fpm8.4 -v          # the FPM your site uses (adjust the version)
ls /etc/php/           # all installed versions (Debian/Ubuntu)

If unsure, put a temporary phpinfo() page on the site, check "Server API" and the version line, then delete it.

2. Update the package

Debian and Ubuntu (distribution packages): Distributions usually backport security fixes into the old version number. If the number did not change, look for the CVE in the changelog.

sudo apt update
sudo apt install --only-upgrade 'php8.4*'
apt changelog php8.4-fpm | grep -E '109618|109619'

Ond≈ôej Sur√Ω's repository (deb.sury.org): This repository follows PHP's upstream version numbers. It also has new packages for 7.4, 8.0 and 8.1 dated 21 October. I checked their changelogs myself: the patch was written by PHP developers and carries the note "Minimal mitigation for EOL version". It buys time for 8.1 and older; the real fix is moving to 8.2 or later.

AlmaLinux: Patched packages are in the AlmaLinux 8, 9 and 10 repositories.

sudo dnf update 'php*'

Docker: Rebuild your image on the new version tag (e.g. FROM php:8.4.27-fpm) and restart the containers. A docker pull alone is not enough; containers started from the old image keep running old code.

Shared hosting and control panels: Your provider applies the update. Ask in writing which version you are on.

3. Restart

PHP-FPM workers and Apache processes run the code they loaded into memory. The fix is not live until they restart.

sudo systemctl restart php8.4-fpm
sudo systemctl restart apache2      # if you use mod_php

4. Interim settings

The interim settings php.net lists (session.upload_progress.enabled = 0, memory_limit = -1, a low post_max_size, and fatal_error_backtraces = 0 on PHP 8.5) do not make a server safe; they close some paths. Details are in the earlier post. If you don't use upload progress, keeping it off after patching does no harm; I left it off on my server.

On my own server

I installed the builds that landed in the CloudPanel repository on the evening of 21 October: 8.5.12 (17:29) and 8.4.27 (18:56). The check on 22 October:

$ php-fpm8.5 -v
PHP 8.5.12 (fpm-fcgi) (built: Oct 21 2026 07:08:08) (NTS)
$ php-fpm8.4 -v
PHP 8.4.27 (fpm-fcgi) (built: Oct 21 2026 07:08:08) (NTS)

Java: CVE-2026-91403

According to OpenJDK's 21 October advisory, eight intermediate CA certificates were compromised. The component is security-libs/javax.net.ssl (JSSE), scored 9.1 under CVSS 3.1. JDK 8, 11, 17, 21, 25 and 27 are affected; OpenJFX is not. Oracle issued it as a separate Security Alert, outside the regular October CPU.

Standalone JDK/JRE: Update to the latest release.
If you can't update: Drop in the new $JDK_HOME/lib/security/blocked.certs (blacklisted.certs on JDK 8; back up any entries you added), or enable revocation checking:

-Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true

OS-provided OpenJDK: On Debian, Ubuntu, Fedora, Red Hat and Arch, updating the system certificates is usually enough. Update FreeBSD and Homebrew packages directly.

If you don't know how many JDKs you have, count them first: CI agents, IDEs and runtimes bundled inside applications each need their own update.

HTTP/3: QPACK memory amplification

FoxIO published a class of memory amplification flaws in QPACK, HTTP/3's header compression (summary by The Hacker News). Affected stacks cap the compressed input but not the decoded header list, or apply the cap too late. Seven of the ten HTTP/3 stacks tested were affected. No authentication is needed; a small request can make the server allocate far more memory.

Stack	Status
quic-go (Caddy, Traefik, cloudflared)	Fixed in 0.57.0 ¬∑ CVE-2025-64702
Cloudflare quiche	Fixed in 0.29.3 ¬∑ CVE-2026-12523
lsquic (LiteSpeed, OpenLiteSpeed)	Fixed in 4.9.0
Wireshark (dissector)	4.6.2 / 4.4.12 ¬∑ CVE-2025-13945
Bun, h3 (hyperium), aioquic/mitmproxy	Unpatched at disclosure
IIS, Envoy, ngtcp2/nghttp3, Google quiche	Not affected per FoxIO

Interim mitigations for unpatched stacks: don't expose Bun's HTTP/3 server, run mitmproxy with --set http3=false, and set a limit with max_field_section_size in h3. No in-the-wild exploitation was reported at disclosure.

Node.js: 21 October security releases

On 21 October Node.js fixed 10 CVEs across the 22.x, 24.x and 26.x lines: 4 high, 3 medium, 3 low. The fixed releases are 22.23.4, 24.22.1 and 26.12.1.

High severity:

CVE-2026-111497: out-of-bounds write in the Brotli decoder that allows remote code execution (RCE).
CVE-2026-105483: TLS certificate hostname check bypass when an IP address is written with fullwidth digits.
CVE-2026-106069: TLS hostname check bypass when the host loosely resolves to an IP address.
CVE-2026-105482: dns.resolve truncates names containing a NUL character.

Among the medium ones, CVE-2026-106074 stores the entropy cache of crypto.randomUUID() and randomInt() in snapshots and SEAs, so processes started from the same snapshot can repeat values. Node.js 20 and 25 are end-of-life and got no fix; apps on those lines need a major upgrade.

node -v

Railway: access to environment variables

On 21 October Railway detected anomalous activity in the systems that store customer environment variables. According to GitGuardian's summary, an unauthorized party may have accessed encrypted values and, for some, decrypted ones. Railway links it to a series of attacks on platform companies aimed at compromising AI inference providers.

Per the status page, builds were paused platform-wide, OAuth sessions were invalidated, bucket credentials were rotated and on 22 October at 04:17 UTC all Railway API tokens were revoked. On the morning of 22 October, Pro and Enterprise builds were running slowly and Hobby builds were not yet enabled.

If you use Railway:

Rotate keys in the upstream services first (AWS, GCP, GitHub, AI providers), then update the values in Railway.
Rotate sealed variables too; the disclosure doesn't say whether they were in scope.
Rotate private registry credentials.
Review the logs of services that use these credentials. Railway published guides for AWS, GCP and GitHub.
Create a new Railway API token; the old ones no longer work.

Claims that crypto assets stored on Railway were also drained are circulating on social media; I could not confirm them from a primary source.

OVHcloud CLI: a supply-chain attack

According to BleepingComputer, attackers took over a developer's GitHub account and replaced files in existing OVHcloud CLI releases. Versions 0.11.0 through 0.15.0 served malicious files on 19 October between roughly 14:47 and 16:21 (sources state the time zone differently; the window is about 94 minutes).

The malware is an infostealer that collects secrets from disk. It includes a hidden preinstall.js loader and a second stage fetched through a Solana memo dead drop. OpenSourceMalware links it to an operation called GlassWorm.
Affected platforms: macOS (Intel, ARM), Linux (x86_64, ARM64) and Windows x86-64. Builds from source and Docker images were not affected.
The releases could be changed without passing CI/CD because GitHub's release immutability setting was off. OVHcloud has turned it on.
0.10.0 and 0.16.0 are clean.

This is not a customer data breach; there are no reports of access to OVHcloud infrastructure or customer databases. But if you installed or updated the CLI in that window on 19 October, the advice from OVHcloud CEO Octave Klaba is clear: change every secret on that machine.

Today's checklist

[ ] PHP: is your site's PHP-FPM on 8.5.12, 8.4.27, 8.3.36 or 8.2.35? If not, update, then restart PHP-FPM and Apache.
[ ] PHP 8.1 and older: install the minimal patch and plan the move to 8.2 or later.
[ ] Java: update every JDK/JRE or replace blocked.certs.
[ ] HTTP/3: check your quic-go, quiche and lsquic versions; disable HTTP/3 on Bun.
[ ] Node.js: 22.23.4, 24.22.1 or 26.12.1.
[ ] Railway: rotate every environment variable, registry credential and API token.
[ ] OVHcloud CLI: if you installed 0.11‚Äì0.15 on 19 October, rotate your secrets and move to 0.16.0.

Sources

php.net ¬∑ 21 October security releases
PHP Foundation ¬∑ Today's PHP Security Release, and How We're Strengthening PHP Security
The Next Web ¬∑ PHP knew about one of the flaws in 2024 but could not agree a fix
Wiz Research ¬∑ PHP2Shell
AWS Security Blog ¬∑ PHP2Shell exploitation prior to public disclosure in MadPot
watchTowr ¬∑ PHP2Shell FAQ
The Hacker News ¬∑ PHP Issues Emergency Patches
AlmaLinux ¬∑ Patched PHP packages
packages.sury.org ¬∑ php7.4 7.4.33-31, php8.0 8.0.30-25, php8.1 8.1.34-9 (21 October builds, debian/changelog)
OpenJDK Vulnerability Advisory 2026/10/21
The Hacker News ¬∑ New QPACK Flaws Can Crash HTTP/3 Servers
Node.js ¬∑ October 2026 Security Releases
Railway status ¬∑ QH8L8B3E
GitGuardian ¬∑ New Railway Incident
BleepingComputer ¬∑ OVHcloud CLI releases backdoored on GitHub
TechCrunch ¬∑ The internet is having a very bad cybersecurity day

Originally published at iamcanturk.dev.

Two Critical RCEs in PHP: CVE-2026-109618 and CVE-2026-109619

Can Türk — Wed, 21 Oct 2026 14:08:16 +0000

On 21 October 2026 the PHP security team released versions that fix two critical vulnerabilities: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both can allow unauthenticated remote code execution (RCE), and both are rated 9.2 under CVSS v4.0. The release had been announced a day earlier; when details leaked the same day, the fix shipped slightly ahead of the planned time.

This post explains both vulnerabilities based on the official advisories, sums up who is at risk and what helps until you can update, and ends with what I did on my own server, step by step. There are no attack instructions here; everything is written from the defender's side.

In short


Vulnerabilities	CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): RCE via OOM corruption CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): RCE via stale global state
CVSS v4.0	9.2 (both) ¬∑ `AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`
CWE	CWE-416 (use after free), CWE-755, CWE-824, CWE-1325, CWE-1419
Affected	All versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12
Fixed	8.2.35 ¬∑ 8.3.36 ¬∑ 8.4.27 ¬∑ 8.5.12
At risk	Every PHP installation serving web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed. Highest risk with mod_php.
Only complete fix	Updating. Mitigations only close specific paths.

Timeline

When	What happened
20 Oct	php.net posted "Upcoming Critical PHP Security Release": two critical vulnerabilities, CVSS v4.0 9.2, release on 21 Oct at 14:00 UTC.
20 Oct	Details leaked. Sansec and Huntress published warnings the same day; the leak circulated as "php2shell".
21 Oct 13:34 UTC	The two GitHub Security Advisories were published.
21 Oct 13:48 UTC	The PHP CNA published both CVE records.
21 Oct	8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released. Linux distributions and LTS vendors received the patches in advance.

CVE-2026-109618: request memory left half-initialized by OOM

When PHP runs out of memory (OOM), it uses longjmp() to leave the current context and abort the request. According to the advisory, in some contexts request memory becomes reachable before it is fully initialized. If any allocation fails at that moment, PHP doesn't account for the early exit and leaves the request memory in an invalid state. The failed allocation doesn't even need to be related to that memory. The request shutdown procedure may then read or branch on the invalid data.

The attacker's job is to push a request into OOM while it stays within PHP's apparent limits. The advisory lists several multipart parsing paths that make this possible:

A multipart request without a usable Content-Length can pass the initial post_max_size check and keep supplying decoded body data.
A multipart part can carry an unlimited number of headers, and their in-memory representation uses far more memory than their size on the wire.
Empty file controls don't count toward max_file_uploads but still create file metadata arrays, and nested field names multiply that work.

It depends on the SAPI

Apache mod_php: shutdown always runs, even when request startup failed. Automatic body parsing can hit the memory limit at exactly that invalid moment, and all of this happens before any application code runs. Full RCE was validated over HTTP against mod_php with default PHP input and memory limits.
PHP-FPM: when startup fails, FPM exits the child, so the invalid state is never consumed. OOM can still be reached after normal startup, though. Source analysis supports FPM as susceptible; no complete FPM exploit has been demonstrated.
FrankenPHP: like mod_php, it calls shutdown unconditionally, so it is likely open to application-independent attacks.
LSAPI: modeled on FPM; application-specific exploits are likely but unvalidated.

The patch removes the longjmp() OOM exit. It is replaced by a graceful soft OOM at the next VM safe point, plus an immediate hard OOM via _exit() if memory reaches a second, higher threshold.

CVE-2026-109619: stale state carried from one request to the next

A PHP worker handles many requests in sequence. Some global state (error, session, object and extension state) stays in the worker but points to memory owned by one request. According to the advisory, that state must be reset before the request memory is released. If it isn't, some operations that run before normal initialization of the next request touch freed memory: a classic use after free.

Exploitation needs two pieces:

A producer: an operation that stores request-owned state globally and skips its reset because of a fatal error or OOM. Parse failures, uncaught errors, a failing require and Maximum execution time exceeded are examples of such interruptions.
A consumer: an operation in a later request on the same worker that reads the stale value before normal initialization.

The advisory confirms two consumers:

INI diagnostics before request initialization. If an invalid or deprecated setting raises a warning during startup, the stale error state is used. The warning doesn't need to be displayed or logged, so error_reporting, @ and display_errors give no protection.
Session upload progress. Upload progress touches session handling before ordinary session initialization and can use session state left by an interrupted request.

Two concrete cases are confirmed:

fatal_error_backtraces on PHP 8.5: when enabled, fatal error reporting stores a request-owned backtrace that shutdown never resets. The confirmed mod_php exploit is built on this.
The session upload progress lifecycle: with mod_php, the producer and the fatal error can both happen during multipart startup. On FPM the validated path is different: state is published while the application runs, a fatal error follows, and upload progress acts as the early consumer. It works on a normal dynamic FPM pool but depends on a suitable application operation.

When is the INI path open on FPM?

According to the advisory, php.ini and FPM pool values are applied when a worker starts, and .user.ini after normal initialization, so they don't provide an early consumer. But if nginx or Apache mod_proxy_fcgi sends PHP_VALUE / PHP_ADMIN_VALUE parameters to FPM and those values raise a diagnostic before initialization, FPM is exposed through this path too.

Panels like CloudPanel send fastcgi_param PHP_VALUE to every site with values like memory_limit, post_max_size and date.timezone. Valid values raise no diagnostic. A deprecated or invalid one raises the risk.

Who is at risk?

Highest: Apache mod_php and FrankenPHP. The attack can run before application code and independently of the application.
Moderate: PHP-FPM and LSAPI. There are validated paths, but most depend on the application or configuration. That is not a reason to delay the update.
8.1 and older: the PHP project no longer ships updates for these. As an exception, minimal source backports were published for people building 7.4, 8.0 and 8.1 from source (PHP-7.4, PHP-8.0, PHP-8.1 branches). If you use distribution packages, ask your vendor or move to a supported version.
8.2: reaches end of life on 31 December 2026. Install this fix, then plan the upgrade.

The impact is code execution as the web worker account: an attacker could run commands on your server with the privileges of the user PHP runs as.

How to check your server

# Installed versions and package versions (Debian/Ubuntu)
ls /etc/php/
php -v
dpkg -l | grep -E '^ii  php[0-9.]+-(fpm|cli|common) '

# FPM services that are actually running
systemctl list-units --type=service 'php*-fpm*'

# Is Apache mod_php loaded? (highest risk)
apache2ctl -M 2>/dev/null | grep -i php

# Does the web server send PHP_VALUE to FPM?
grep -rn "PHP_VALUE\|PHP_ADMIN_VALUE" /etc/nginx/ /etc/apache2/ 2>/dev/null

# Is a fixed version in your repository yet?
apt-get update && apt-cache policy php8.4-fpm

CLI and FPM settings can differ. Use php-fpm8.4 -i to see what FPM actually uses.

Updating

Distributions and LTS vendors received the patches in advance, so distribution packages should arrive quickly. The advisory adds two notes: the volunteer-maintained rpms.remirepo.net repository will not have updates today, so switch to distribution packages or build from source if you rely on it. Windows binaries are on the php.net downloads page.

# Record your sites' status first
for d in site1.com site2.com; do echo "$d $(curl -s -o /dev/null -w '%{http_code}' https://$d/)"; done

# Upgrade only the installed PHP packages, keep config files
sudo apt-get update
sudo DEBIAN_FRONTEND=noninteractive apt-get install --only-upgrade -y \
  -o Dpkg::Options::=--force-confold $(dpkg -l | awk '/^ii  php/{print $2}')

# Verify
php8.4 -v
sudo php-fpm8.4 -t && systemctl is-active php8.4-fpm

Docker: pin the official php image to the fixed version (for example php:8.4.27-fpm) and recreate the containers. Floating tags like 8.4-fpm only update after a docker pull.

Shared hosting: if you have no server access, write to your provider today and ask which version you are on and when the fix will be installed.

If you can't update yet: the official mitigations

The php.net advisory is explicit: these only reduce exposure to specific attack paths and don't make an installation safe.

For CVE-2026-109618 (OOM):

Set memory_limit=-1 and enforce it where applications can't override it, such as php_admin_value in the FPM pool. Check that no pool, directory or application setting restores a finite limit. This removes the controllable OOM, but an underlying mmap() failure can still reach the same path. Unlimited memory is also a denial of service risk on a shared server, so do it deliberately.
Keep post_max_size low: 8M for applications that don't take uploads, 32M if they do. Keep upload_max_filesize below it.
At the web server or proxy, limit decoded request size, input field count, multipart part count, header count and nesting depth, including requests without a usable Content-Length. If your application doesn't use multipart forms, block them before they reach PHP.
A container or cgroup memory limit can act as an availability boundary. Don't use RLIMIT_AS or RLIMIT_DATA: they cause exactly the allocation failure that triggers the vulnerable path.

For CVE-2026-109619 (stale state):

Set session.upload_progress.enabled=0 and restart every worker. Put it in php.ini, an FPM pool or server configuration applied before request parsing. ini_set() and FPM .user.ini don't work. This blocks the confirmed session paths, not other variants.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks only the confirmed backtrace path.
Remove invalid or deprecated settings applied per request (.htaccess, Apache php_value, nginx PHP_VALUE).
Fix fatal errors and execution timeouts an attacker can trigger, including in callbacks, upload or import processing and cleanup.

; /etc/php/8.5/fpm/conf.d/99-mitigation.ini
session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; PHP 8.5 only

sudo php-fpm8.5 -t && sudo systemctl reload php8.5-fpm
php-fpm8.5 -i | grep -E '^(session.upload_progress.enabled|fatal_error_backtraces)'

Does a Cloudflare rule help?

A Cloudflare WAF rule shared after the leak blocks requests whose body carries a PHP_SESSION_UPLOAD_PROGRESS field:

any(http.request.body.form.names[*] == "PHP_SESSION_UPLOAD_PROGRESS")
or http.request.body.raw contains "PHP_SESSION_UPLOAD_PROGRESS"

Action: Block. But it only targets the upload progress consumer; it doesn't cover the OOM vulnerability or the INI path. It has two more limits:

Cloudflare only inspects the first part of the request body. If the field comes later, the rule misses it.
If your server can be reached directly by its IP address, the attacker never passes through Cloudflare.

I tested the second one on my own server, and every site, including my own, opened directly by IP. My main site looked closed at first because the server uses a self-signed certificate and curl refused the connection. With -k it returned 200. An attacker won't care about the certificate either:

curl -sk -o /dev/null -w "%{http_code}\n" --resolve yoursite.com:443:SERVER_IP https://yoursite.com/

If that returns 200, your origin is exposed. Accept only Cloudflare's IP ranges on the server, or use Authenticated Origin Pulls.

What I did on my own server

My server runs CloudPanel on Ubuntu 26.04. Every site runs on PHP-FPM behind nginx; there is no Apache or mod_php.

Time (UTC+3)	Step
11:26	Inventory: ten versions installed, from 7.1 to 8.5, but only the 8.4 and 8.5 FPM services running. Versions 8.4.22 and 8.5.9.
11:26	The real surprise: on 8.4 I was already three security releases behind before the emergency fix (8.4.23, 8.4.24, 8.4.26).
11:59	Recorded the HTTP status of every site, then installed the latest available releases: 8.4.26 and 8.5.11 (188 packages, over half an hour). Every site answered the same as before.
12:01	`session.upload_progress.enabled=0` on 8.4 and 8.5, FPM reloaded.
16:48	Read the advisories. nginx sends `PHP_VALUE` to every site; all values are valid and there is no `open_basedir`, so they raise no INI diagnostic.
16:48	`fatal_error_backtraces` was on in 8.5. Turned it off, reloaded FPM, checked the sites again.
pending	CloudPanel's package repository doesn't have 8.4.27 and 8.5.12 yet. I'll install them the moment they land and update this post.

I didn't apply memory_limit=-1. There are several sites on this server, and unlimited memory would let one bad request slow down all of them. No complete FPM exploit has been demonstrated and the package is close, so I decided against it. On mod_php I would have decided differently.

I also covered this in a short video (in Turkish): Pixel Shorts ¬∑ Emergency patch for PHP.

Credits

According to the advisories, the vulnerabilities were reported by lcfr-hax, sagitzadik-wiz, tomash-areion and amyb-oai. The fixes were developed by arnaud-lb, iluuu1994, bukka and ndossche.

References

Originally published at iamcanturk.dev. I wrote this post together with Claude Code.

I Turned My Personal Site Into a Building

Can Türk — Tue, 20 Oct 2026 20:17:10 +0000

My old site was a WordPress theme. It did the job, but it didn't feel like me. When I sat down to rebuild it, I asked myself one question: what should someone feel in the first three seconds?

The answer was simple: that they had walked into somewhere.

The idea: a building you can see inside

The homepage is now a menu and, below it, six rooms that fill the screen. The notebook is a library, Pixel Shorts is a studio, my projects live in a workshop, my security research sits in a SOC, the about page is my own room, and contact is a café.

Click a room and a pixel version of me walks over to it. If it's on another floor, he takes the elevator on the right. When he arrives, the screen dissolves into pixels and the page opens, with the same room as its header, so you really feel like you stepped inside.

It didn't start this way. The first version was a tall building, and the scrolling never ended. The second fit the building on one screen, but the text I put next to it made everything feel crowded. What survived is the simplest version: a menu, the rooms, a footer. Nothing else.

Small details I love

Day and night. In dark mode the rooms are dim, and on your first visit the lights switch on one by one. Flip to light mode and the whole building turns to day in place, with sunlight pouring through the windows. The mascot waits in the room I'm probably in right now, based on the time in Bursa: the SOC in the afternoon, the studio in the evening, the library late at night.
Rooms that are alive. The library lamp flickers, rain runs down the café window, the espresso machine steams, and the dots on the SOC's world map blink. Every effect is pinned to the illustration's own coordinates, so even when a room is cropped to fit your screen, the lamp glow stays on the lamp.
The studio TV. It shows the poster of the latest Pixel Shorts episode. What comes next stays a surprise until it airs.
Bugs on the SOC floor. Click them and they get squashed. A security person's site needed this.
In a hurry? Click again while the mascot is walking and you go straight there. With reduced motion turned on, there's no animation at all.

Under the hood

Astro, fully static. No database, no admin panel, no code running on the server. Posts are Markdown files.
Tiny5 for headings. In most pixel fonts I tried, the "C" read like an "O". Tiny5 didn't, so I subset it down to the characters I actually use (4.6 KB).
Two languages. Turkish at the root, English under /en/. Visitors from outside Turkey land on the English homepage; if they switch languages themselves, that choice is remembered.
Friendly to AI. Add .md to the end of any page and you get a plain-text version. There's an llms.txt summary, and AI crawlers are welcome.
Deploys. My own VPS behind Cloudflare. Every ten minutes the server checks the repo; if there's a new commit, or a Pixel Shorts episode whose time has come, it rebuilds the site and pings search engines through IndexNow.
And a trap. Bots probing addresses like /wp-admin get a fake login page instead. Nobody gets banned; they just get mocked, and I keep a log.

The illustrations and AI

The mascot, the rooms and the walk cycle were generated with AI (gpt-image), then cleaned up and cut by hand. The concept, the interactions and the code are mine; I wrote the code together with Claude Code. I don't see a reason to hide that: this site is about software, security and AI in the first place.

What's next

Pixel Shorts starts on October 20th, and after that a new episode will land on the studio TV every day. The episodes are in Turkish, but every one has an English transcript on the site. The building may get new rooms, too. If you have an idea, drop by the café.

Originally published at iamcanturk.dev.

I Wrote a Doctor for My Docker

Can Türk — Fri, 14 Aug 2026 20:20:52 +0000

Because for months I didn't really know what was running on my machine.

One evening, at the end of a long day, I typed docker ps and just stared at the output for a while. Twenty-six containers. I remembered what some of them were for; the rest were things I'd spun up months ago with a quick "let me just try this" and then forgotten. Then I typed docker images: thirteen gigabytes. Layers nobody pulls anymore, images that had long since stopped mattering.

That was the moment I admitted something uncomfortable: I used Docker every day, but I didn't actually know what was running inside it.

Docker is a strange tool that way. It makes running something extraordinarily easy, and noticing what you're running just as hard. Six months into a project, the average developer's machine has quietly accumulated the same things: a container with the Docker socket mounted into it, a couple of databases published to 0.0.0.0, a dozen services running as root, and gigabytes of images nothing references. None of it sets off an alarm — not until something breaks, or someone decides to scan you.

The existing tools don't fill this gap

Don't get me wrong, there are good tools. Trivy and Grype find CVEs in your images perfectly well. But they need a vulnerability database, and therefore a network, and what they look at is the packages inside the image. That wasn't my problem. My problem was the configuration layer: how I was running the container. docker system df tells you disk usage but has no opinion about it; it won't say "nothing touches this volume anymore."

What I wanted was a tool that answered one question: what is wrong with this Docker environment right now, and what should I do about it? I couldn't find it, so I wrote it.

DoctorDock

DoctorDock is a small command-line tool that scans your local Docker environment — with a native macOS menubar app alongside it. It finds the security problems, the misconfigurations, and the reclaimable disk, and leaves you with a health score out of 100. I wrote it in Go; single binary, no account, MIT license.

To be concrete about speed: on my machine, a full scan of roughly 26 containers, 29 images, 29 volumes, and 12 networks takes about 550 ms. That's less time than it takes to read the output of docker ps.

Three decisions I made

I decided three things up front while writing this. All three might look like missing features. I'd argue it's the opposite.

No AI

I could have made this an "AI-powered security product." I didn't. Every finding is deterministic Go you can read; the same environment always produces the same output. If you wonder why a rule flagged something, you can go read the source. I don't want a security tool telling me "this might be insecure" — either it is, or it isn't.

Fully offline

Zero network calls. No telemetry, no account, no update check. DoctorDock opens exactly one local socket — Docker's — and nothing else. It runs the same on an air-gapped machine and in a locked-down CI runner. What you scan stays with you.

Secrets stay put

I read container environment variables as key names only; their values never enter memory in a form that could reach a report. You'll see that a key called DATABASE_PASSWORD exists — never its value. That's what makes it safe to point at production, which for a security tool should be the default, not a selling point.

What it looks like

There's nothing to do but install it and scan:

brew install iamcanturk/tap/doctordock
doctordock scan

The output gives your environment a score and lists the findings worst-first:

HEALTH SCORE  37/100  poor

  1 CRITICAL · 17 HIGH · 6 MEDIUM · 22 LOW

  DD005  CRITICAL  Docker socket mounted into a container
  DD001  HIGH      Container runs as root
  DD006  MEDIUM    Database port published on 0.0.0.0

If you see 37/100, don't panic; most developer machines start somewhere around there on the first scan. What matters is that the list is finally visible. And every rule explains itself:

doctordock explain DD005

That prints what the rule looks for, why it matters, a worked attack scenario, a copy-pasteable fix, and an honest note on when it's fine to ignore. It doesn't stop at "there's a problem here" — it teaches you how to close it.

The part I worried about most: cleanup

Honestly, cleanup is the part I was most nervous about while writing this — because one wrong command can wipe out someone's month of data. So DoctorDock deletes nothing by default:

doctordock cleanup            # dry run: only shows what it would remove
doctordock cleanup --apply    # actually removes it

And no flag except --volumes can select a volume — not even --all. You can re-pull an image and re-create a network; but when the data in a volume is gone, it's gone. So volumes only ever enter the picture when you ask for them explicitly, on their own. Nothing is deleted by accident.

Closing

DoctorDock isn't a big product; it's a small, honest tool. It puts the things your Docker environment quietly accumulated over months in front of you in under a second, without leaking any of it. Like a doctor: it looks, it diagnoses, it tells you what to do — and it leaves the decision to you.

If you're curious, run a scan and see what your machine actually scores. It'll probably come out lower than you think — but for the first time, you'll know exactly what to do about it.

Code: github.com/iamcanturk/DoctorDock
Download and details: doctordock.iamcanturk.dev