FortiSIEM CVE-2026-106173: Public PoC Turns a Critical SIEM Flaw Into a Patch-Now Problem
Last verified: October 21, 2026
Picture the one server in your network that every other system reports to. Firewalls, domain controllers, endpoints and cloud workloads all send it their logs, and your analysts trust whatever it shows them. Now imagine an attacker who can quietly write a file onto that server without ever logging in.
That is the real risk behind the FortiSIEM vulnerability tracked as CVE-2026-106173. Fortinet patched it on October 13, 2026. A week later, researchers at Horizon3.ai published a technical write-up and a proof-of-concept (PoC), and the clock for unpatched appliances started running faster.
In this post, I walk through what is confirmed, what is still unknown, and what a SOC team should do today to protect SIEM security in a real environment.
Table of Contents
- What Happened and Why It Matters
- Affected Versions at a Glance
- How the Flaw Works (Defender's View)
- CVSS 9.4 vs. 9.8: Why Scores Differ
- Real-World Risk Scenario
- Detection: What to Check on Your Appliances
- Defensive Commands for Admins
- Patch Management and Hardening Steps
- Expert Tips From the SOC Floor
- FAQ
- Conclusion
What Happened and Why It Matters
Per Fortinet's advisory (FG-IR-26-180), an improper limitation of a pathname to a restricted directory (CWE-22, path traversal) in FortiSIEM may let an unauthenticated attacker execute unauthorized code or commands through specially crafted packets. The affected component is the gRPC service called phQueryMaster.
Horizon3.ai later published a deep-dive and a GitHub PoC. According to their research, the service listens on TCP port 27918 and handles query-result data. It builds a file path from a value the client supplies, without validating it properly.
Here is the confirmed timeline:
| Date | Event |
| October 13, 2026 | Fortinet publishes advisory FG-IR-26-180 and releases FortiSIEM 7.5.1 |
| October 20, 2026 | Horizon3.ai publishes technical analysis and a PoC on GitHub |
| October 21, 2026 | Security outlets widely report the public PoC |
One point deserves emphasis. A public PoC proves the attack is reproducible. It does not prove anyone has been compromised. At the time of writing, trackers I reviewed did not list this CVE in the CISA Known Exploited Vulnerabilities catalog, and I found no confirmed reports of exploitation in the wild.
Still, FortiSIEM has a history here. Cyber Kendra notes that an earlier Horizon3-reported bug, CVE-2025-64155, drew exploitation attempts within days of disclosure. Public code tends to shorten the gap between "patched" and "attacked."
Affected Versions at a Glance
| Product / Version | Status (per Fortinet advisory) |
| FortiSIEM 7.5.0 | Affected. Upgrade to 7.5.1 or above |
| FortiSIEM 7.6 | Not affected |
| FortiSIEM Cloud | Not affected |
| Workaround | Restrict access to TCP port 27918 |
The affected range is narrow, which is good news. But if you run 7.5.0 on-premises, you are in scope, and the workaround is simple enough that there is no reason to wait.
How the Flaw Works (Defender's View)
I will keep this conceptual, because defenders need to understand the mechanism, not reproduce it. Per Horizon3.ai's analysis, the problem has two parts.
Part 1: An unvalidated path value
The service accepts a query identifier from the client and places it into a file path. Because the value is not checked, directory-traversal sequences can push the write outside the folder where query results are supposed to live. That is a classic CWE-22 pattern.
Part 2: A null byte that shortens the path
The service also appends its own text to the end of the filename, which would normally keep an attacker from choosing an exact target. Horizon3.ai found that a null byte inside the crafted field makes the operating system treat the path as ending early. That lets the write land on a precise, existing filename.
The researchers also noted that standard gRPC tools and libraries restrict null bytes in headers, so the request has to be assembled by hand. That is a speed bump for casual attackers, not a barrier for skilled ones.
Why a file write becomes code execution
An arbitrary file write becomes remote code execution when the attacker overwrites something the system runs automatically. In their demonstration, Horizon3.ai targeted a Redis health-check script that, according to Cyber Kendra's summary, a cron job runs every 60 seconds. The research also names a second file worth inspecting, the phLicenseTool binary.
Another detail from the research matters for threat modeling. The service uses TLS, but it does not require a client certificate. In practice, anyone who can reach the port can talk to the service. The question is not "who has credentials?" but "who has network access?"
CVSS 9.4 vs. 9.8: Why Scores Differ
If you have been comparing sources, you may have noticed two different severity scores. The Hacker News and Cyber Kendra report CVSS 9.4, which matches the figure attributed to Fortinet. Several NVD-based trackers list 9.8 (network vector, low complexity, no privileges, no user interaction, high impact on confidentiality, integrity and availability).
Both are Critical. Different scorers weigh the metrics differently, and the gap should not change your response. For prioritization, the more useful facts are that it is unauthenticated, network-reachable and now has public tooling.
Real-World Risk Scenario
Consider a mid-sized US healthcare provider running FortiSIEM 7.5.0 on-premises. The SIEM sits in a management VLAN, but a flat firewall rule lets several internal subnets reach it on all ports, including 27918. A vendor laptop on a guest-adjacent segment is compromised through an unrelated phishing email.
From that foothold, the attacker scans for management services, finds the gRPC port, and uses public research to turn it into code execution on the SIEM. What happens next is analysis, not confirmed fact, but it is a realistic worst case:
- Stored credentials and integration secrets become available to the attacker.
- Alerting rules can be quietly weakened, so the SOC sees less.
- Logs that would reveal the intrusion can be tampered with.
- The SIEM becomes a trusted pivot point toward the systems it monitors.
For HIPAA-regulated environments, a compromised monitoring platform also raises audit questions about log integrity. This is why the Tech Jacks Solutions advisory frames a compromised SIEM as a potential loss of visibility across the whole environment. It maps the issue to MITRE ATT&CK technique T1190 (Exploit Public-Facing Application).
Detection: What to Check on Your Appliances
Here is the uncomfortable part. According to Horizon3.ai, they did not find application logs that clearly identify exploitation of this flaw. You cannot rely on a neat alert saying "attack detected." Detection depends on integrity checks and network visibility.
1. Verify your version
Confirm whether any FortiSIEM node runs 7.5.0. Use the version information in your appliance administration interface, and check every node in a cluster, not only the supervisor.
2. Check for network exposure
Review firewall rules and flow logs for inbound connections to TCP 27918 on FortiSIEM hosts. Anything from external addresses, or from internal segments that have no reason to talk to the SIEM, deserves a closer look.
3. Inspect the files named in the research
Check modification times on the two files Horizon3.ai identified: the Redis health-check script under /opt/charting and the phLicenseTool binary under /opt/phoenix/bin. Compare their timestamps with nearby system files. A mismatch is a lead worth investigating, not proof of compromise, and an unchanged timestamp does not prove safety either, since timestamps can be altered.
4. Review service logs, with realistic expectations
The Tech Jacks Solutions advisory suggests searching phQueryMaster logs for traversal patterns. Treat this as a supplementary hunt only. Given Horizon3.ai's finding, a clean result does not rule out tampering.
Defensive Commands for Admins
These are read-only checks for your own appliances. Run them only on systems you are authorized to administer.
Check whether anything is listening on the gRPC port
ss -tlnp | grep 27918What it does: lists listening TCP sockets and filters for port 27918. When to use it: to confirm the service is running and to document exposure. Expected output: a listening entry for the phQueryMaster process on a vulnerable or unpatched node.
Review modification times on the files named in the research
ls -l --time-style=full-iso /opt/charting/redishb.sh /opt/phoenix/bin/phLicenseToolWhat it does: prints full timestamps, owner and permissions. When to use it: during triage, alongside a baseline from a known-good appliance or backup. Expected output: two lines with modification times. Look for dates that do not match your last patch or maintenance window.
Compare against neighboring files
ls -lt --time-style=full-iso /opt/charting/ | head -20What it does: lists the directory sorted by newest modification. When to use it: to see whether the script changed recently relative to its neighbors. Expected output: a time-sorted listing. Remember that a mismatch is only a lead.
Warning: do not edit, delete or restore these files while an investigation is open. Take a snapshot or forensic copy first so evidence is preserved.
Patch Management and Hardening Steps
This is where enterprise vulnerability management earns its keep. A sensible order of operations:
- Contain first. Restrict TCP 27918 to the specific internal systems that genuinely need it. Fortinet lists this as a workaround, and it should never be reachable from the internet.
- Patch next. Upgrade 7.5.0 nodes to 7.5.1 or later, following Fortinet's upgrade documentation and your change-control process.
- Hunt in parallel. Run the integrity and network checks above before and after patching, since a patch closes the hole but does not remove anything already planted.
- Rotate secrets if you find anything suspicious. Credentials stored in the SIEM should be treated as exposed if tampering is confirmed.
- Fix segmentation. Management interfaces for security tooling belong on restricted networks with explicit allow-lists.
The Tech Jacks Solutions playbook makes a point I agree with: a port restriction is a stopgap, not a substitute for patching. Document the exception, set a deadline and close it.
Fortinet's October 13 release also covered other products. According to Daily Security Review, that batch included a critical FortiSandbox authentication bypass (CVE-2026-107656). If you run both products, treat this as a single maintenance window rather than two separate projects.
Expert Tips From the SOC Floor
- Assume your SIEM is a high-value target. It aggregates sensitive data and holds privileged integrations. Protect it like a domain controller.
- Do not stop at one service. Earlier FortiSIEM research involved phMonitor on port 7900. This one involves a different service entirely. Hardening one port does not secure the others, so audit every listening service on the appliance.
- Keep baselines. File hashes and timestamps from a known-good state turn a vague "something looks off" into a real answer.
- Separate "exposed" from "compromised" in your reporting. Executives and auditors need both numbers, and conflating them causes either panic or complacency.
- Watch the monitoring blind spot. If the SIEM itself is suspect, validate with a second telemetry source such as firewall logs, EDR or network flow data.
Related Cybersecurity Topics You Should Explore
- Linux renice Command: 54 Examples to Control CPU Priority
- SBI Data Breach Claim: What's Real and What's Not
- Linux nice Command: 30 Examples to Protect Your Server CPU
- iOS 27.0.1 Untethered Jailbreak Explained: Risk and Fixes
- Nextcloud Servers Backdoored: Collabora Flaw CVE-2026-110447
- Linux killall Command: 31 Examples & Safe Usage Cheat Sheet
FAQ
Is CVE-2026-106173 being exploited in the wild?
I found no confirmed exploitation in the sources reviewed, and it was not listed in the CISA KEV catalog at the time of writing. A public PoC does raise the risk, so check KEV and vendor channels for updates.
Which FortiSIEM versions are affected?
Per Fortinet, only FortiSIEM 7.5.0. Version 7.6 and FortiSIEM Cloud are listed as not affected.
Do attackers need valid credentials?
No. The advisory describes an unauthenticated attacker. They do need network access to the vulnerable service on TCP 27918.
Can I rely on firewall restrictions instead of patching?
Fortinet lists port restriction as a workaround, and it is a strong stopgap. Patching remains the proper fix, because network controls can be misconfigured or bypassed from inside.
How do I know if my appliance was compromised?
There is no single reliable indicator. Horizon3.ai reported no application logs that clearly show exploitation, so combine file timestamp checks, network logs for port 27918, and baseline comparisons.
Why does a SIEM flaw matter more than a typical server bug?
A SIEM holds logs, credentials and detection logic for the whole environment. Compromise can mean both a foothold and reduced visibility at the same time.
Conclusion
CVE-2026-106173 is a reminder that security tools are software too, and they fail like any other software. The facts are clear: a critical, unauthenticated path to code execution in FortiSIEM 7.5.0, a vendor fix in 7.5.1, a simple workaround, and public research that attackers can read as easily as defenders.
The action list is short. Find your 7.5.0 nodes, lock down port 27918, patch, and verify file integrity. Then use this incident to review how reachable your other security management systems really are.
If this breakdown helped, share it with your SOC or infrastructure team, and leave a comment with how you are handling FortiSIEM patching in your environment. Subscribe for more practical CVE analysis written for defenders.