Roundup: Critical Ivanti, Fortinet, and VMware Flaws Patched
Just caught the latest release regarding a wave of patches from major vendors. It’s looking like a heavy patching cycle, particularly for those running Ivanti Xtraction.
The critical vulnerability here is CVE-2026-8043 (CVSS 9.6). The "External control of a file name" mechanism is nasty—it essentially allows attackers to manipulate file paths to achieve information disclosure or conduct client-side attacks. If left unpatched, this could easily lead to further lateral movement, especially if the Xtraction instance has ties to domain controllers.
We also have fixes for:
- Fortinet: RCE vulnerabilities.
- SAP: Security updates for various components.
- VMware: Flaws requiring immediate attention.
- n8n: Privilege Escalation and SQL Injection fixes.
For those needing to audit their Ivanti Xtraction instances quickly, I threw together a basic script to pull version info from the registry (adjust the path as per your install):
$servers = Get-Content ".\server_list.txt"
Invoke-Command -ComputerName $servers -ScriptBlock {
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" |
Where-Object { $_.DisplayName -like "*Ivanti*Xtraction*" } |
Select-Object PSComputerName, DisplayName, DisplayVersion
}
Given the frequency of these reporting tool exploits (think MOVEit, etc.), how is everyone justifying the ROI of keeping these on-prem versus moving to SaaS offerings where the vendor manages the patching cadence?
Great post. For the n8n instances, I'd strongly recommend checking your webhook logs for unusual SQL payloads if you can't patch immediately. We've been seeing automation tools targeted heavily recently.
I'm drafting a quick KQL query for our SIEM to look for potential exploitation attempts on the Fortinet side:
DeviceVendor == "Fortinet" && ActionType == "network" && DestinationPort == 443
| where NetworkProtocol == "HTTPS" and Message has "admin"
| summarize count() by SourceIP, DestinationIP
Better safe than sorry with those RCEs.
Ivanti strikes again. We actually deprecated Xtraction for a client last quarter after a risk assessment, which looks like a lucky break now. It feels like every legacy reporting tool is a ticking time bomb.
For those patching VMware, don't forget to snapshot before applying. We had an ESXi patch break a host last month—always test in non-prod if you can afford the time.
Spotting path traversal is crucial here. If patching isn't immediate, monitoring for directory traversal sequences in your Xtraction logs is a solid stopgap. Attackers often leverage this to grab config files.
You can run a quick audit using grep on your access logs to look for classic traversal patterns:
grep -iE "(\.\./|%2e%2e)" /var/log/apache2/access.log
Excellent breakdown. Beyond log monitoring, consider implementing strict egress filtering on the Xtraction server. Since this flaw allows reading local files, preventing the server from connecting back to external endpoints adds a crucial layer of defense against data exfiltration.
# Example to block outbound connections except necessary ports
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -j DROP
This limits the blast radius if an attacker successfully compromises the application.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access