Skip to content
Critical Vulnerabilities in PHP : CVE-2026-109618 and CVE-2026-109619

Critical Vulnerabilities in PHP : CVE-2026-109618 and CVE-2026-109619

Community.Fortinet • October 22, 2026

Has Fortinet issued any advisory regarding the recent PHP remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619? Are any Fortinet products affected?

There is currently no advisory. But Fortinet has begun tracking this issue.

For better or worse, Fortinet mostly use Nodejs/Javascript for their management interfaces, so unlikely to be affected as far as I know. I stand corrected - EMS uses PHP, but usually is not to be exposed to Internet.

Hello. Will Fortinet be providing an official response or advisory regarding these vulnerabilities?

Also, what web security updates? Fortiweb hasn’t seen a Fortiguard update in two weeks ( ). Cloudflare already updated their WAF rules earlier this morning.

I found cisco update it’s snort rules and as mmmpotato78 notes, cloudflare updated their WAF Rules, can we expect a fortigate IPS update as well?

maybe:

cravikumar :

But this says the FortiOS, Manager and Analyzer is impacted. Fortinet Releases Security Hardening Release for Multiple Products | CISO Collective

That looks like patches as a result of Frontier AI findings. Unrelated to these CVEs.

I’m part of the Fortinet Brasil community, where a customer shared this script. After making a few adjustments, I tested it on my FortiGate and confirmed that the blocking mechanism is working as expected.

Important note the rule’s behavior:

This rule does not block file uploads in general. Normal file uploads continue to work, including uploads of files with the .php extension.

The block is specifically triggered by upload attempts in which the filename contains embedded PHP code, such as filename="foto<?php.jpg" or filename="x<?=1". This pattern is associated with the format used by the exploit in question.

The other signatures remain configured for logging only and do not block traffic.

This approach aims to detect and block this specific exploitation pattern while preserving normal file-upload functionality.

I’m part of the Fortinet Brasil community, where a customer shared this script. After making a few adjustments, I tested it on my FortiGate and confirmed that the blocking mechanism is working as expected.

Important note the rule’s behavior:

This rule does not block file uploads in general. Normal file uploads continue to work, including uploads of files with the .php extension.

The block is specifically triggered by upload attempts in which the filename contains embedded PHP code, such as filename="foto<?php.jpg" or filename="x<?=1". This pattern is associated with the format used by the exploit in question. Additional note: So far, tests using several PoCs still indicate that the vulnerability is present. I’m investigating the behavior and checking for possible adjustments. This is the most promising approach I’ve found so far, but I cannot yet consider it a complete or definitive mitigation.

The other signatures remain configured for logging only and do not block traffic.

This approach aims to detect and block this specific exploitation pattern while preserving normal file-upload functionality.

Already have an account? Login

Login to the community

Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.

Extracted Entities

Attack Types (1)

Companies (1)

Platforms (3)

Tools (1)