FortiSIEM, GitLab and Oracle Access Manager: no login needed

This roundup covers 19 to 23 October 2026. Four flaws came together in tools that organisations run themselves and that can see into the rest of the environment: a SIEM from Fortinet, self-managed GitLab, Oracle Access Manager and the Redis database. Three of them can be exploited without logging in.

Two items were covered separately earlier in the week. The critical PHP flaws known as PHP2Shell are described in our article on firewalls and management consoles, which also tracks the status of enterprise products. Exploitation of the GlobalProtect flaw from Palo Alto Networks was covered in a separate article on 22 October. We do not repeat the full analysis here.

Six entries were added to the CISA KEV catalogue, the list of flaws with proven exploitation, on 20 October: four flaws in Plex Media Server, a local flaw in Siemens Software Center and a flaw in the Japanese web application firewall SiteGuard. For a mid-sized European organisation these are marginal. What follows are the four items worth acting on, ordered by impact.

1. FortiSIEM from Fortinet, a public exploit writes a file to the server without logging in

CVE-2026-106173 · CVSS 9.8 (the vendor advisory states 9.4) · public proof-of-concept exploit · patch available

FortiSIEM is a security information and event management (SIEM) platform. It collects logs from servers, networks and applications, looks for suspicious patterns and raises alerts for the security team.

The flaw is a path traversal in the phQueryMaster gRPC service listening on TCP port 27918. The service is meant for queries between FortiSIEM nodes, but according to Horizon3.ai it accepts connections without a client certificate. An attacker can therefore write a file to an arbitrary location without authentication, overwrite a script executed by a scheduled task and run code of their choosing.

This is worse than it looks because a SIEM is where an organisation sends logs from the whole environment and where it stores credentials used for collection. Whoever controls the SIEM gains an overview of the environment and at the same time takes away the eyes of the defenders. Horizon3.ai published a working proof of concept on 20 October. Fortinet states it is not aware of exploitation, and the flaw is not in the KEV catalogue. Note a discrepancy in affected versions: advisory FG-IR-26-180 lists only FortiSIEM 7.5.0, while the CVE record from the same vendor also lists branches 7.0.0 to 7.4.2 with a fix in 7.6.0. Fortinet has not explained the difference.

What to do: upgrade to FortiSIEM 7.5.1 or later. If you run a 7.0 to 7.4 branch, treat it as potentially affected and move to 7.6.0 or later. According to the vendor, FortiSIEM 7.6 and FortiSIEM Cloud are not affected. If you cannot upgrade right away, restrict access to TCP port 27918 to your own FortiSIEM nodes and check modification times of the files redishb.sh and phLicenseTool.

2. GitLab fixed a flaw scored 10, an attacker does not need an account

CVE-2026-110264 · CVSS 10.0 · no evidence of exploitation · patch available

GitLab manages source code and automates building and deployment of applications. This flaw affects only installations an organisation runs itself (self-managed), in both the Community and Enterprise editions.

It is an integer overflow in the regular expression compiler. GitLab states that under certain conditions an unauthenticated user could execute code on the GitLab server. The flaw has been in the code since version 7.0, released in 2014, and there is no workaround.

This is worse than it looks because GitLab usually holds source code, deployment pipelines and tokens to cloud and production. An attacker does not only reach data, but the path the organisation uses to deploy. No public proof of concept exists yet and nobody has confirmed exploitation. One detail matters for anyone who already patched this month: the versions released on 12 October (19.2.8, 19.3.5 and 19.4.2) are vulnerable to this flaw, so another maintenance window is needed. According to the vendor, GitLab.com and GitLab Dedicated are already fixed.

What to do: upgrade to 19.5.1, 19.4.3 or 19.3.6 depending on your branch. For older branches GitLab released 19.2.9, 19.1.9, 19.0.10 and 18.11.13. If maintenance cannot be scheduled immediately, restrict access to the instance to the corporate network or VPN, disable new user registration and watch web layer logs. After patching, consider rotating tokens and keys the server held.

3. Oracle shipped its quarterly bundle, the highest scores belong to Access Manager and SOA Suite

CVE-2026-87337, CVE-2026-91216 and CVE-2026-91221 · CVSS 10.0 · no evidence of exploitation · patch available

Oracle Access Manager provides single sign-on for enterprise applications. Oracle SOA Suite connects applications to each other and moves data between them. In larger organisations and financial institutions both products tend to sit in the core of operations.

Oracle released its quarterly Critical Patch Update on 20 October. According to analysis by Tenable it contains 1,295 patches covering 1,209 distinct flaws across 33 product families. Three of them carry the highest score. CVE-2026-87337 sits in the authentication engine of Access Manager in versions 12.2.1.4.0 and 14.1.2.1.0, and Oracle states that an unauthenticated attacker over HTTP can gain full read and write access to all Access Manager data, with impact reaching connected applications. CVE-2026-91216 and CVE-2026-91221 are in the Fabric layer of SOA Suite in versions 12.2.1.4.0 and 14.1.2.0.0 and allow takeover of the product by an unauthenticated attacker over the T3 or IIOP protocols.

This is worse than it looks because Access Manager stands at the entrance to the other applications. Whoever controls it does not need to guess passwords, because they can issue an identity themselves. With SOA Suite the risk is that T3 and IIOP are often open inside the internal network in a configuration nobody has reviewed for years. Neither exploitation nor a public exploit has been confirmed for these three flaws.

What to do: apply the Critical Patch Update of 20 October 2026 for your version. For these products Oracle does not publish a new version number, the fix comes as a patch bundle for a given version. Start with instances reachable from the internet. If maintenance cannot happen right away, restrict network access to middleware administration interfaces and to the T3 and IIOP ports. For Oracle E-Business Suite, patching the application part is not enough, the database and Fusion Middleware components are patched separately.

4. Redis, a flaw from May is now being probed

CVE-2026-25243 · CVSS 8.8 per NVD, some sources state 7.7 · actively exploited · patch available

Redis is a database that keeps data in memory. Organisations typically use it for caching, job queues and user sessions.

The RESTORE command recreates a key from a binary serialised value. Redis did not sufficiently validate the structure and length fields in the supplied data, so a crafted value corrupts the heap and can lead to code execution in the redis-server process. The attacker needs to be authenticated and permitted to run RESTORE.

This is worse than it looks for two reasons. Honeypots run by Defused recorded repeated scripted exploitation attempts on 16 and 17 October, and one attacker wiped the contents of the database after each run. The fix, however, dates to 5 May 2026, so what is being hit now are instances organisations forgot about. The flaw is not in the CISA KEV catalogue, while the company VulnCheck tracks it in its own catalogue of exploited flaws. The second reason is how Redis is operated: it often runs inside the internal network without authentication and several applications share one set of credentials.

What to do: upgrade to Redis 8.6.3, or to 7.2.14, 7.4.9, 8.2.6 or 8.4.3 depending on your branch. If you installed Redis from a distribution, apply the vendor package, Red Hat released RHSA-2026:14316 and RHSA-2026:23229. If you cannot upgrade right away, deny the RESTORE command through an ACL rule for every account that does not genuinely need it, enable authentication and do not expose Redis outside the application network.

Priority summary

Elsewhere in security

A supply chain attack reached more than forty maritime companies

According to the Risky Bulletin newsletter, the extortion group n0n listed more than forty port authorities, shipping companies and logistics firms from eighteen countries on its site at once on 12 October, with a payment deadline that expired on 19 October. The security company CyDome states that half of the listed firms are known customers of CyberLogitec, a South Korean supplier of IT platforms for the maritime sector, and that the CyberLogitec website has been down for weeks. In its view this points to the supplier as the entry point. No confirmation from CyberLogitec is available, and no authority has publicly tied the group to a specific point of intrusion.

Review which suppliers have access to your systems and answer, for each of them, what happens in your organisation if that supplier goes down or is compromised.

A credential stealer made it into the LiteLLM package

On 21 October the LiteLLM project, a library through which applications call language models, published its own notice that malicious code made it into release 1.107.0 on PyPI and Docker Hub. The packages contained three extra files that run on every start of Python in that environment, even if nobody imports the library, and collected cloud credentials, private keys and tokens for developer tools. According to the project notice, the releases were built from a lookalike copy of the repository, not from the official tag on GitHub. The infected version was available on PyPI from 11:39 to 13:23 UTC and on Docker Hub from 11:46 to 14:20 UTC. Version 1.106.2 is clean. There is no CVE number for this incident.

If you installed or started LiteLLM in that window, rotate the credentials and keys present in that environment and rebuild the machine.

What to take away from this week

All four items share one trait: they are tools an organisation runs itself and that can see into the rest of the environment. These are exactly the places where patching slips the most, because an upgrade means an outage of monitoring, builds or cache. For an attacker they pay off the most: one server gives an overview, access and the trust of other systems.

The second observation concerns the way in. Two of this week's events did not arrive through the network perimeter, but through a supplier and through a dependency in code. Usually nobody in the organisation is named as the owner of either.

A task for this week: list the administration and development tools running on your own servers, and for each add the version, who maintains it and where it is reachable from. With that list, the items in this roundup immediately tell you whether they concern you. It is worth keeping the list, rather than rebuilding it for every roundup.

Struggling to keep track?

We publish this roundup every week. Following it is only the first step. The harder part is knowing which vulnerabilities concern you specifically, in what order to address them and who in the organisation is responsible.

We help with that: security assessment and vulnerability management · external security manager · technology selection and deployment

A no-obligation consultation · Dealing with an incident right now?

We will tell you plainly what is worth addressing first. The initial consultation is free of charge.

Sources: CISA, Known Exploited Vulnerabilities catalogue · CISA, cybersecurity advisories · Fortinet, advisory FG-IR-26-180 on FortiSIEM · CSA Singapore, alert AL-2026-153 on FortiSIEM · NVD, record for the GitLab flaw · Oracle, Critical Patch Update of October 2026 · NVD, record for the Redis flaw · securityonline.info, exploitation of the Redis RESTORE command · Risky Bulletin, supply chain attack on the maritime sector · LiteLLM, incident notice of 21 October 2026 · Socket, analysis of the malicious LiteLLM release