DEV Community: Marius Podar

PHP RCE vulnerabilities CVE-2026-109618 and CVE-2026-109619: what to check and how to update

Marius Podar — Tue, 27 Oct 2026 07:56:02 +0000

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both can lead to unauthenticated remote code execution. They carry a CVSS v4.0 score of 9.2 (Critical) from the PHP Group, with attack complexity listed as High, and CISA added both to its Known Exploited Vulnerabilities catalog on 26 October 2026. The advisories do not state whether exploit code is publicly available.

What was found

CVE-2026-109618 (RCE via OOM corruption). PHP uses longjmp() to abort a request when it runs out of memory. If that happens while internal request data is only partly initialized, the cleanup at the end of the request can treat invalid data as valid. The advisory lists several ways to exhaust memory with a multipart request that still looks within PHP's limits.

CVE-2026-109619 (RCE via stale global state). Some internal state points to memory owned by a single request. If a fatal error, such as a timeout, interrupts the request before that state is reset, a later request handled by the same worker can read freed memory (a use-after-free). The attack needs two requests: one leaves the stale state and the next uses it.

Who is affected

Every release before 8.5.12, 8.4.27, 8.3.36 and 8.2.35 in their branches. According to the PHP announcement, any installation serving web requests is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The project considers the risk highest for mod_php, where an unauthenticated attack has been demonstrated that runs before any application code. For CVE-2026-109618 a complete FPM exploit has not been demonstrated, while for CVE-2026-109619 the advisory reports a validated attack against both mod_php and FPM.

PHP 8.1 and older no longer receive project updates. The security team prepared minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors provide their own fixes.

Check your PHP version

php -v
php-fpm -v   # the binary name varies: php-fpm8.3, php83-fpm...

The command-line binary can differ from the one serving your site. To see the web version, use a temporary page that prints it, and delete it afterwards:

<?php echo PHP_VERSION;

If PHP comes from a distribution or LTS vendor, check their advisory for the fixed package: a backported fix does not always change the version number.

How to update

Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a later release of the same branch. Source and Windows binaries are on php.net; on Linux, use your distribution's updates. Then restart every PHP worker (the FPM service, or Apache with mod_php). Both advisories say that updating is the only complete mitigation.

If you cannot update today

These measures only reduce exposure to specific attack paths; they do not make an installation safe. The same checklist is in my original article in Spanish.

For CVE-2026-109618:

Set memory_limit=-1 administratively, so the application cannot change it. It removes the controllable limit used by the confirmed attack, but it is not complete.
Set post_max_size to 8M if the application needs no uploads, or 32M if it does, and keep upload_max_filesize below it.
Enforce limits at the web server or proxy for decoded request size, fields, multipart parts, headers and nesting depth, including requests without a usable Content-Length.
Use a container or cgroup limit as an availability boundary. Do not use RLIMIT_AS or RLIMIT_DATA: they can trigger the vulnerable failure.

For CVE-2026-109619:

Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, and restart every worker. Do not rely on ini_set() or FPM's .user.ini. It does not cover other variants.
On PHP 8.5, set fatal_error_backtraces=0 and restart.
Remove invalid or deprecated settings applied per request that emit warnings before initialization. Hiding warnings with error_reporting, display_errors or @ does not help.
Fix fatal errors and timeouts that an attacker can trigger.

On 23 October the project also recommended session.upload_progress.enabled=0 until the next bugfix release, for a separate and unlikely vector (CVE-2026-115560).

Sources

PHP announcement, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, NVD CVE-2026-109618, NVD CVE-2026-109619 and the CISA KEV catalog.

I wrote a more detailed version in Spanish here: PHP: vulnerabilidades críticas RCE (CVE-2026-109618 y 109619)

CSRF en PHP: qué es y cómo prevenirlo con un token (guía rápida)

Marius Podar — Tue, 27 Oct 2026 06:34:04 +0000

El CSRF (Cross-Site Request Forgery) es una de las tres vulnerabilidades web clásicas, junto al SQL Injection y el XSS. Y tiene una particularidad: no necesita robar ninguna contraseña. Le basta con que la víctima ya tenga una sesión abierta en tu aplicación.

Cómo funciona el ataque

Cuando un usuario inicia sesión, el navegador guarda una cookie de sesión y la envía automáticamente en cada petición a ese dominio, sin importar desde qué página se origine. Un atacante puede aprovecharlo con una página (o un email, o un anuncio) que lance una petición a tu sitio. Si tu aplicación solo comprueba que hay sesión, la ejecutará como si la hubiera hecho el propio usuario.

Imagina un formulario para cambiar el email de la cuenta que solo comprueba $_SESSION['user_id']. El atacante monta una página externa con un formulario oculto que apunta a tu endpoint y se envía solo con JavaScript. Si la víctima la visita estando logueada, su email cambia sin que se entere. Desde ahí, al atacante le basta con pedir un «olvidé mi contraseña» para quedarse con la cuenta.

La defensa principal: un token CSRF

La defensa estándar, recomendada por OWASP, es un token aleatorio generado por el servidor, que viaja en cada formulario y se valida al recibir la petición. El atacante no puede conocerlo ni adivinarlo, así que no puede incluirlo en su formulario falso.

Genera el token y guárdalo en sesión:

session_start();
if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

Inclúyelo en el formulario:

<input type="hidden" name="csrf_token" value="<?= $_SESSION['csrf_token'] ?>">

Y valídalo antes de procesar nada:

if (
    empty($_POST['csrf_token']) ||
    empty($_SESSION['csrf_token']) ||
    !hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'])
) {
    http_response_code(403);
    die('Petición no válida.');
}

Dos detalles importantes: usa random_bytes() (nunca rand() ni uniqid()) y compara con hash_equals() en lugar de ==, para evitar timing attacks. En acciones muy sensibles, como cambiar la contraseña, invalida el token después de usarlo con unset($_SESSION['csrf_token']).

Capas adicionales

El token es la defensa principal, pero conviene combinarlo con:

Cookies SameSite: con SameSite=Lax o Strict, el navegador no envía la cookie de sesión en peticiones que vienen de otros dominios.
Comprobar Origin o Referer: solo como capa extra, nunca como única defensa, porque pueden faltar en casos legítimos.
Usar POST, nunca GET, para acciones que modifican datos: un enlace GET se explota con un simple <img src="...">.
HTTPS en todo el sitio, para que las cookies secure se envíen siempre.

Si usas un framework como Laravel o Symfony, ya trae protección CSRF integrada: actívala y no la desactives «para simplificar».

Conclusión

Con un token aleatorio, hash_equals() y cookies SameSite cubres la gran mayoría de los casos reales de CSRF en PHP, sin librerías complicadas.

Si quieres el ejemplo completo y la explicación detallada, está en el artículo original en Todo se Aprende.