GitLab, Cisco ASA/FTD and Ivanti Connect Secure Security Fixes (October 2026): What Is Affected and How to Fix It on Each Platform

Key Points

• Ivanti Connect Secure: upgrade to 25.1.1.3 / 22.8R2.6 / 25.1.3.x. Attacks chaining three flaws to gain root have been confirmed, and the first fixes are not enough
• GitLab: upgrade to 19.5.3 / 19.4.5 / 19.3.7. CVE-2026-97229 is in CISA KEV. Stopping at 19.4.2 or similar leaves CVE-2026-110264 unfixed
• Cisco ASA / FTD: CVE-2026-76418, which lets attackers reload SSL VPN devices, is being exploited and the September releases do not fix it. Move to ASA 9.20.4.50, FTD 7.6.7 or your train's fix
• KEV deadlines (for US federal agencies): 1 November for GitLab and Cisco; 16 October (passed), 2 November and 13 November for Ivanti. Patch internet-facing devices first
• Patching does not remove an attacker who is already inside. Check Ivanti and GitLab for signs of compromise, and rotate credentials, certificates and tokens if anything looks wrong

About This Article

This summary reflects primary sources as of 31 October 2026 (Japan time): the Ivanti, GitLab and Cisco advisories, the US CISA Known Exploited Vulnerabilities (KEV) catalog (catalog version 2026.10.30), CVE.org, NVD, JPCERT/CC, and the report by Volexity, which investigated the Ivanti attacks. Things change quickly, so check the official links at the end before you start.

Dates in KEV and in vendor announcements are the publisher's own dates (US time and so on). KEV deadlines are set for US federal agencies under directive BOD 26-04, but they are a useful guide to priority. The sections below follow the order of those deadlines: Ivanti, GitLab, then Cisco.

Severity scores differ between sources, so we always say whose rating we quote. When CISA's SSVC assessment on a CVE record says "exploitation: active", real-world exploitation has been confirmed.

In Japan, as of 31 October, neither JPCERT/CC nor IPA had issued an alert for any of the three products. JPCERT/CC's weekly reports have covered GitLab and Ivanti. The JVN iPedia and MyJVN vulnerability databases have been suspended since a notice dated 30 October, with service expected to resume in November.

First: Are You Affected?

Ivanti Connect Secure

• Check the version on System > Status, the first page you see after logging in to the admin console (over SNMP, read productVersion from the MIB)
• Affected: 25.1.0.0 to 25.1.1.2, 25.1.2.0 to 25.1.2.2, and 22.8R2 to 22.8R2.5. Fully fixed: 25.1.1.3 and 22.8R2.6 (Ivanti also says 25.1.3.0 and 25.1.3.1 "do not contain this vulnerability")
• The first fixes, 25.1.1.2 and 22.8R2.5, address only CVE-2026-104935, so you must upgrade again
• 22.7 and earlier are not affected, according to Ivanti. However, 22.7 reaches end of support on 31 January 2027
• Note for vulnerability scanners: the CVE record for CVE-2026-104935 does not list 25.1.1.2 as unaffected, so products that use CVE.org data may report 25.1.1.2 as affected

GitLab

• Check the version: on the Linux package run sudo gitlab-rake gitlab:env:info; on Docker run it inside the container (for example docker exec -it gitlab gitlab-rake gitlab:env:info); on source installations run bundle exec rake gitlab:env:info RAILS_ENV=production. In the web UI, Help > Help at the bottom left shows the version
• Helm: translate the chart version shown by helm list -n <namespace> using GitLab's version mapping table (for example chart 10.5.4 = GitLab 19.5.3)
• 19.5.3 / 19.4.5 / 19.3.7: contain all October fixes
• 19.5.1 / 19.4.3 / 19.3.6: CVE-2026-97229 and CVE-2026-110264 are fixed; the 29 October CVE-2026-111943 is not
• 19.5.0, 19.4.2, 19.3.5, 19.3.4 and 19.2.8: CVE-2026-110264 is unfixed. 19.4 up to 19.4.1, 19.3 up to 19.3.4 and 19.2 up to 19.2.7 also lack the CVE-2026-97229 fix
• 19.2 down to 18.11: the extended backports 19.2.10 / 19.1.10 / 19.0.11 / 18.11.14 do not include the other 11 fixes from 21 October, and 19.1.10 / 19.0.11 / 18.11.14 also lack most of the 12 October fixes (for example CVE-2026-14814). 18.10 and older have no fixed release (every version from 7.0 through 18.10 is affected by CVE-2026-110264)
• Check GitLab Runner with gitlab-runner --version (required versions below)

Cisco ASA / FTD

• ASA: show version | include Version. The version may appear as 9.20(4)50, which is the same as 9.20.4.50
• FTD: show version on the CLI (the "Threat Defense ... Version" line), or Devices > Device Management in FMC. The ASA version shown by show version system is not the FTD version
• Configuration: use show running-config webvpn to see which interfaces have SSL VPN enabled and whether tunnel-group-list enable is set, and show running-config tunnel-group | include tunnel-group|secondary-authentication-server-group to see which tunnel groups use secondary authentication. On FTD, check Devices > VPN > Remote Access in FMC or Remote Access VPN in FDM
• Do not decide by comparing version numbers alone. ASA 9.18.4.135, 9.20.4.235, 9.23.1.195 and 9.24.1.155 are hot-fix builds that are listed as affected even though their numbers are higher than the fixed builds. Enter your exact version and platform in the Cisco Software Checker

Ivanti Connect Secure: CVE-2026-104935 and a Three-Vulnerability Chain

What happened

On 13 October 2026, Ivanti published a fix for CVE-2026-104935 in its Connect Secure advisory (Ivanti Hub article 000109571), and on 29 October it added two related vulnerabilities. Ivanti has confirmed that a limited number of customers were compromised by attacks chaining the three. Ivanti has published no workaround.

• CVE-2026-104935: authentication bypass by spoofing (CWE-290) that lets an unauthenticated remote attacker run arbitrary commands. Ivanti (the CVE numbering authority) scores it CVSS 8.6 (v3.1 in the CVE record, labelled v3.0 in the advisory). CISA's SSVC assessment is exploitation active, automatable, technical impact total
• CVE-2026-111357: missing authentication for a critical function that lets a local authenticated attacker escalate privileges. Ivanti scores it 8.8 (CVSS 3.1). The CVE record (assigned by MITRE) scores it 7.0 and lists only 22.8R2.4 as affected
• CVE-2026-118527: use of predictable filenames (CWE-340) that lets a remote authenticated attacker upload attacker-controlled content to a known location on disk. Ivanti scores it CVSS 4.3 (v3.0). As of 31 October it is still RESERVED on CVE.org and absent from NVD
• Ivanti found part of CVE-2026-104935 internally and fixed it in 25.1.3.0 in July; exploitation started while it was backporting the fix to older trains
• According to Volexity, which investigated, the attacks began on 3 October (Volexity calls the actor UTA0576) and compromised a fully patched 22.8R2.4 (build 19097), then the latest 22.8 release. After getting in, the attackers used an Active Directory service account to query AD for LAPS passwords and BitLocker recovery keys (saving the results to files), ran password spraying and captured network traffic
• KEV: CVE-2026-104935 was added on 13 October (deadline 16 October). CVE-2026-111357 and CVE-2026-118527 were added on 30 October, with deadlines of 2 November and 13 November. CVE-2026-104935 and CVE-2026-111357 carry a requirement to check for compromise (forensic triage)
• CISA issued an alert on 13 October and revised it on 30 October to cover all three. JPCERT/CC covered CVE-2026-104935 and its exploitation in its 21 October weekly report

Affected and unaffected products

• For 25.1.3.0 and later, Ivanti says they "do not contain this vulnerability". However, Ivanti does not explicitly list 25.1.3.x as the fixed release for CVE-2026-111357 / 118527
• Pulse Connect Secure 9.1x reached end of support on 31 December 2024 and is not mentioned in this advisory. It gets no code changes, so you need to migrate
• Ivanti Policy Secure, Neurons for ZTA gateways, Neurons for Secure Access and Ivanti Secure Access Client do not appear in this advisory or in Ivanti's October security update blog
• There is nothing to update in Linux distributions, Docker, Homebrew or winget. You must update the appliance itself

Fix: fixed versions and steps per version and platform

The general flow is: back up the configuration → run the Integrity Checker Tool (ICT) → upgrade → check the version → run ICT again.

1. Back up the configuration (binary configuration backup, Ivanti KB44759)
2. Run ICT before upgrading to look for signs of compromise (see below)
3. Download the fixed package from the Ivanti License System (ILS)
4. Install it under Maintenance > System > Upgrade/Downgrade > Install Service Package. Do not select "Deletes": it wipes all configuration. The appliance reboots after installation
5. Check the version on System > Status. In a cluster, check every node

• 25.1.0.x / 25.1.1.x: upgrade to 25.1.1.3. Ivanti explicitly says "25.1.1.1 (ISA6000 or ISA8000): update to 25.1.1.3" and says nothing about virtual appliances on the same train, so confirm with Ivanti before applying it there
• 25.1.2.x (releases only for ISA-6500 / ISA-8500): upgrade to 25.1.3.0, then to 25.1.3.1. 25.1.3.1 can be reached only from 25.1.3.0
• 25.1.3.0 / 25.1.3.1: Ivanti says 25.1.3.0 and later "do not contain this vulnerability" (see above). Ivanti recommends the latest release, 25.1.3.1
• 22.8R2.x: Ivanti recommends moving to 25.1.1.3 or later. If you cannot move yet, install 22.8R2.6 (which resolves all of these vulnerabilities). 22.8 is only a temporary bridge to 25.1 and reaches end of support on 31 January 2027. Clusters cannot be upgraded directly from 22.8R2 to 25.x: break the cluster, upgrade each node, then rebuild it
• Platform limits when moving to 25.1.3.x: you need ISA4500 / ISA6500 / ISA8500 hardware, or a virtual or cloud instance newly built from the 25.1.3.0 template. ISA-6000 / ISA-8000 and existing virtual appliances cannot be upgraded in place and must migrate their configuration. Virtual appliances require a vTPM
• Ivanti's compatibility guide (updated 22 October) does not list source versions for 25.1.1.3 or 22.8R2.6, and their release notes were not public as of 31 October. Confirm on the Ivanti support portal before you start

If you suspect a compromise (ICT alone is not enough)

• Ivanti recommends running the built-in Integrity Checker Tool (ICT) regularly. It is configured under System > Configuration > Security > Miscellaneous; treat SYS32039 (new files) or SYS32040 (mismatched files) in the event log as warning signs. On SYS32039, Ivanti says to take the device off the network and send a system snapshot to support
• However, ICT may not detect these attacks. Volexity reports that ICT found nothing because the changes were made only in memory and later reverted. CISA also says network and memory forensics are needed. In-memory evidence is lost on reboot or reset, so if you plan to investigate, consider capturing evidence first (this is not a step CISA or Ivanti explicitly states)
• Indicators published by Volexity: large numbers of requests to /dana-na/auth/url_default/welcome.cgi, requests carrying an X-DSCGI-PATH header (especially where the URL path and the header value differ), the hidden directory /data/.icscap/, partially deleted logs, and the attacker IP address 108.165.147[.]64. Volexity warns that attackers may find other paths
• Volexity's YARA rules can be run against collected logs or memory images like this: curl -sLO 'https://raw.githubusercontent.com/volexity/threat-intel/main/2026/2026-10-13%20Ivanti/rules.yar' && yara -r rules.yar <path-to-collected-files>
• CISA's recovery steps: (1) back up the configuration; (2) factory reset and upgrade to the latest version (rebuild and upgrade virtual and cloud instances); (3) restore the configuration; (4) reset domain, administrator and local account passwords, revoke and reissue stored certificates, and replace API keys and license server credentials. A hardware factory reset is done from the serial console (Ivanti KB22964)
• Ivanti's recovery document (Recovery-Steps) says to work in an isolated environment and keep the device off the internet until it is fully upgraded. It still names 22.7R2.5 as the post-reset version (updated 26 August), so use the current fixed releases instead
• Given what Volexity saw the attackers access, also consider rotating LAPS passwords and BitLocker recovery keys (an extra check beyond the vendor steps). The appliance's AD service account that the attackers used is already covered by Ivanti's recovery steps, which require resetting the passwords of service accounts used in auth-server configurations

If you cannot update right away

• Ivanti has published no workaround or configuration mitigation. Upgrading to a fixed release is the only remedy
• Volexity recommends monitoring request volume to welcome.cgi and the X-DSCGI-PATH header, but this only detects attacks; it does not block them
• The attacker IP address belonged to a single VPS that ran an OpenVPN server from 30 September to 7 October, so blocking it has limited value. It is mainly useful for searching past logs

GitLab: CVE-2026-97229, CVE-2026-110264 and Three October Patch Releases

What happened

GitLab's security fixes cover the current monthly release and the two before it (currently 19.5 / 19.4 / 19.3). Releases for 19.2 and older are exceptional backports that carry only some fixes.

• 12 October: 19.4.2 / 19.3.5 / 19.2.8 fixed 24 issues, including CVE-2026-97229. On the 19.3 line, 19.3.4 shipped first with a bug and was replaced by 19.3.5 the same day. 19.3.4 is affected by CVE-2026-97229
• 21 October: 19.5.1 / 19.4.3 / 19.3.6 fixed 12 issues, including CVE-2026-110264. Only CVE-2026-110264 was also backported to 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13
• 29 October: 19.5.3 / 19.4.5 / 19.3.7 plus the extended 19.2.10 / 19.1.10 / 19.0.11 / 18.11.14. This release addresses CVE-2026-111943 by removing trust in eight compromised eMudhra intermediate CA certificates, and also requires GitLab Runner and AI Gateway updates
• 19.5.2 and 19.4.4 were skipped: there are no packages or images. 19.5.0 (15 October) and the 12 October releases do not fix CVE-2026-110264

Main vulnerabilities fixed

• CVE-2026-97229 (12 October): an integer overflow (CWE-190) in the code that compiles CI/CD regular expressions (Ruby's Onigmo regex engine). It lets an attacker run code as the git user on the GitLab server, leading to theft of gitlab-secrets.json, CI/CD variables, runner tokens and access tokens, and read/write access to every repository. Entry points are the CI Lint API, the GraphQL call used by the pipeline editor, and processing of a pushed .gitlab-ci.yml. Affected: 19.2 to 19.4 before 19.2.8 / 19.3.5 / 19.4.2
• Severity: GitLab (the CVE numbering authority) scores it CVSS 3.1 10.0. Red Hat rates it Critical (9.8) and Amazon Linux Important (8.1). CISA's SSVC assessment is exploitation active, automatable, technical impact total
• Exploitation: CISA added it to KEV on 29 October (deadline 1 November, with a forensic triage requirement). JPCERT/CC's 21 October weekly report says it confirmed that proof-of-concept code is public. A Metasploit exploit module was merged on 30 October; it assumes an account that can push to a public project. As of 31 October, none of GitLab's release posts mention exploitation or KEV
• GitLab's detection rules describe CVE-2026-97229 as a bypass of the incomplete fix for CVE-2026-93577 (GitLab score 9.9) shipped in 19.4.1 on 23 September
• CVE-2026-110264 (21 October): org-ruby 0.9.12, used to render Org-mode (.org) files, builds a regular expression from a keyword in the file and triggers an out-of-bounds write in Onigmo. A single public project holding the attacker's crafted .org file is enough for an unauthenticated attack. Every version from 7.0 before 18.11.13 / 19.0.10 / 19.1.9 / 19.2.9 / 19.3.6 / 19.4.3 / 19.5.1 is affected. GitLab scores it CVSS 10.0 and Red Hat Critical (9.8). As of 31 October it is not in KEV, and its SSVC assessment shows no evidence of exploitation
• CVE-2026-111943 (29 October): adds a mechanism to Go's crypto/x509 that rejects the compromised eMudhra intermediate CA certificates. It was assigned by Go; the only CVSS score is CISA's reference value of 6.8. GitLab updated its CA certificate bundle to the 20 October version
• Other fixes: the other 11 issues of 21 October include improper authentication in OmniAuth-to-LDAP auto-linking (CVE-2026-15723, 8.2), and the other 23 of 12 October include CVE-2026-92883 (8.7). These are GitLab's scores; as of 31 October none of them is in KEV and there is no evidence of exploitation
• September KEV entry: the path traversal in the commits API, CVE-2026-85706 (GitLab score 10.0), was added to KEV on 11 September. Versions from 18.7 before 19.3.2 / 19.2.6 / 19.1.8 / 19.0.9 / 18.11.12 are also unpatched for it

GitLab.com, Dedicated and self-managed instances

• GitLab.com already has all October fixes, and GitLab Dedicated tenants on 19.4.3-internal0 or later need no action
• If you run GitLab yourself on a VPS, a cloud server or an in-house server, you must upgrade it yourself. There is no GitLab server that runs directly on Windows or macOS; follow the Docker or Linux VM steps
• JiHu GitLab in China (gitlab-jh) had published only releases equivalent to upstream 19.5.1 / 19.4.3 / 19.3.6 and so on as of 31 October; releases equivalent to the 29 October fixes were not yet available

Fix: fixed versions and steps per installation method

The general flow is: back up → upgrade to the latest release of your line → confirm the services restarted → check the version. GitLab's release posts offer no workaround other than upgrading.

1. On 19.3 to 19.5, upgrade to 19.3.7 / 19.4.5 / 19.5.3 on the same line. On 19.2 or older, plan a move to 19.3.7 or later
2. Do not skip required upgrade stops. They are 18.2, 18.5, 18.8 and 18.11 for GitLab 18, and 19.2 and 19.5 for GitLab 19. You can go directly to 19.5.3 only from 19.2.x or later (Upgrade Path tool)
3. Take a backup. The Linux package backs up the database automatically before upgrading (skipped if /etc/gitlab/skip-auto-backup exists), but GitLab recommends your own full backup as well
4. 19.5.3 and 19.4.5 include database migrations, so single-node instances will have downtime
5. Never pin a version lower than what you run. Package managers will downgrade as told (for example, pinning 19.3.7 on a 19.4.x host). If newer patches have shipped since this article, use those

• Debian / Ubuntu: sudo apt update && sudo apt install gitlab-ee=19.5.3-ee.0 (to stay on 19.4 use gitlab-ee=19.4.5-ee.0; on 19.3 use gitlab-ee=19.3.7-ee.0; for CE change the suffix to -ce.0, as in gitlab-ce=19.5.3-ce.0). Ubuntu 20.04 tops out at the 18.11 line, gitlab-ee=18.11.14-ee.0, which lacks the other 11 fixes from 21 October and most of the 12 October fixes, so plan a move to a newer Ubuntu release
• RHEL / AlmaLinux / Oracle Linux: sudo dnf install gitlab-ee-19.5.3-ee.0.el9 (change the suffix to .el8 on 8 or .el10 on 10)
• Amazon Linux: on 2023, sudo dnf install gitlab-ee-19.5.3-ee.0.amazon2023. Amazon Linux 2 tops out at sudo yum install gitlab-ee-19.2.10-ee.0.amazon2, which lacks the other 11 fixes from 21 October, so plan a move to 2023
• SLES / openSUSE Leap 15.6: sudo zypper install gitlab-ee=19.5.3-ee.0.sles15
• Official Docker images: gitlab/gitlab-ee:19.5.3-ee.0 (CE: gitlab/gitlab-ce:19.5.3-ce.0). With Compose, change the tag in docker-compose.yml and run docker compose pull && docker compose up -d. With docker run, run sudo docker stop gitlab && sudo docker rm gitlab, pull the new image, and recreate the container with the same options and volumes as before. latest points to 19.5.3, but there are no per-line tags, so use an explicit version tag in production
• Helm chart: chart versions do not match GitLab versions (10.5.4 = 19.5.3, 10.4.6 = 19.4.5, 10.3.9 = 19.3.7). After helm repo update and helm get values gitlab > gitlab.yaml, the upgrade-with-downtime method is helm upgrade gitlab gitlab/gitlab --version 10.5.4 -f gitlab.yaml --set gitlab.migrations.enabled=true. For zero-downtime upgrades, follow GitLab's chart procedure
• Geo (multiple sites): upgrade the primary site first, then the secondaries. /etc/gitlab/gitlab-secrets.json must be identical on every node. Finish with sudo gitlab-rake gitlab:geo:check
• GitLab built on the system Ruby: the official Linux package and images ship a Ruby that GitLab has patched, but source installations, Arch Linux, FreeBSD, NixOS and similar builds use the system Ruby, which must also be 3.3.13 / 3.4.12 / 4.0.9 or later. On Arch, sudo pacman -Syu brings gitlab 19.5.3-1 and ruby 3.4.12-1 together, but as of 31 October the Ruby in FreeBSD ports and NixOS unstable predates the fixes
• Community sameersbn/gitlab image: the 30 October tags (19.5.3 and others) use Ruby 3.3.13, but the 22–26 October tags still use Ruby 3.3.12. Check with docker exec <container> ruby -v
• Raspberry Pi OS (32-bit): GitLab stopped at the 17.11 line, so CVE-2026-110264 will not be fixed. Move to the 64-bit OS and the Debian arm64 package

GitLab Runner and AI Gateway (upgrade separately from GitLab)

Upgrading GitLab does not upgrade Runner or AI Gateway. Runner is not affected by the regex vulnerabilities; it needs an update only for CVE-2026-111943 (the eMudhra certificates).

• Runner: 19.5.1 or later (19.5.2 was also released on 28 October). GitLab names only 19.5.1. Runner 19.4.3 and 19.3.5 also carry the fixed Go, but GitLab has not said they are sufficient (19.4.1 and 19.3.3 still use the unfixed Go)
• sudo apt update && sudo apt install gitlab-runner on Debian / Ubuntu and sudo yum update gitlab-runner on RHEL-family systems install the latest release (do not run a bare sudo yum update: it upgrades every package, including an unpinned GitLab package on the same server). If you pin a version (gitlab-runner=<version>-1 gitlab-runner-helper-images=<version>-1), never pin one lower than what you run (for example, pinning 19.5.1-1 on a 19.5.2 host downgrades it)
• On Docker, run docker pull gitlab/gitlab-runner:v19.5.2, remove the old container and start a new one with the same config volume. On Windows and macOS, replace the official binary; on Homebrew, run brew upgrade gitlab-runner. Alpine's package (18.6.1 on v3.22) is outdated, so use GitLab's official builds
• CI/CD job images: rebuild images that ship their own ca-certificates (on Alpine-based images, RUN apk upgrade --no-cache ca-certificates brings in 20261020-r0)
• AI Gateway (Duo Self-Hosted): you need 18.11.8 / 19.0.13 / 19.1.9 / 19.2.5 / 19.3.3 / 19.4.3 / 19.5.3 or later. GitLab says to use the latest self-hosted-vX.Y.*-ee tag that matches your GitLab version; as of 31 October the newest include self-hosted-v19.5.4-ee. Images for 18.11.8 and 19.1.9 had not been published as of 31 October

Other software using Ruby's Onigmo regex engine

The root cause of CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264 is a set of bugs in Onigmo, the regex engine built into Ruby. On 23 October Ruby released 4.0.9 / 3.4.12 / 3.3.13, which fix all of them. CISA's KEV note also warns that products other than GitLab may be affected.

• Affected applications are those that build regular expressions from externally supplied strings (Regexp.new, Regexp.union and so on). Until you can upgrade, stop doing that
• Ruby has not requested CVE IDs of its own and asks users to track the issues under GitLab's CVE IDs. Regexp.timeout does not protect, and limiting pattern length is not a reliable defence either. Ruby 3.2 reached end of life on 1 April 2026 and will not be fixed
• Fixed: official Docker images ruby:4.0.9 / ruby:3.4.12 / ruby:3.3.13, Homebrew (brew upgrade ruby), RubyInstaller 4.0.9-1 / 3.4.12-1 / 3.3.13-1, ruby-build v20261023, Fedora 46 (ruby-4.0.9-41.fc46), Alpine edge and v3.22 (3.4.12-r0), Arch, and openSUSE Tumbleweed
• Not fixed as of 31 October: Debian (ruby3.1 in bookworm, ruby3.3 in trixie), RHEL's ruby streams, Amazon Linux (no fix planned for AL2023 ruby3.2), and SLES 15 SP7 / SLES 16. On Fedora 43 to 45 the fix is only in updates-testing
• After upgrading, restart every long-running Ruby process, such as Puma and Sidekiq

If you cannot update right away (all partial)

These are the interim risk reductions that GitLab's security team lists in its detection rules.

• CVE-2026-97229: limit who can create accounts and personal access tokens (for example, turn off open sign-up). This only shrinks the pool of possible attackers; it does not fix the bug
• CVE-2026-110264: reduce public projects, and delete or make private any project that holds a malicious .org file. The path for signed-in users remains open
• Keep GitLab off the open internet with a VPN or source-address restrictions. This is not a GitLab workaround, but CISA's BOD 26-04 treats removing a system from the internet as a valid mitigation

After updating: checks and compromise assessment

• Use sudo gitlab-ctl status to confirm that puma, sidekiq and gitlab-workhorse uptimes start after the upgrade; if not, run sudo gitlab-ctl restart. On Docker, use docker ps --format '{{.Names}} {{.Image}}' to make sure no container still runs an old tag
• GitLab has published six detection rules for CVE-2026-97229 and two for CVE-2026-110264. For example, Workhorse 502 responses to CI Lint or GraphQL can be found with grep -E '"uri":"[^"]*(ci/lint|/api/graphql)' /var/log/gitlab/gitlab-workhorse/current* | grep -E '"status":502|badgateway', and worker crashes with grep -B1 -A20 '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log* (use zgrep for compressed logs)
• Clean logs do not prove you were not exploited. GitLab notes that a successful attack can be quiet
• If you find signs of code execution, treat the instance as compromised: rotate the secrets in gitlab-secrets.json, all CI/CD variables, runner tokens and access tokens, and preserve the logs. Also look for new files owned by the git user in /tmp, unexpected child processes, outbound connections, and changed crontabs or SSH keys

Cisco ASA / FTD: CVE-2026-76418 (Out-of-Cycle Advisory, 28 October)

What happened

On 28 October 2026 (GMT), Cisco published an out-of-cycle advisory (cisco-sa-asaftd-tunnel-dos-s6mgkb75) for remote access SSL VPN on Secure Firewall ASA and Secure Firewall Threat Defense (FTD).

• Impact: an unauthenticated remote attacker can make the device reload, causing a denial of service (NULL pointer dereference, CWE-690). A successful VPN login is not required
• Severity: Cisco PSIRT (the CVE numbering authority) scores it CVSS 3.1 8.6 (Cisco Security Impact Rating: High). CISA's SSVC assessment is exploitation active, automatable, technical impact partial
• Exploitation: Cisco PSIRT says it became aware of active exploitation in October 2026, but it has published no indicators of compromise (IoCs) or Snort rules. CISA added the CVE to KEV on 29 October (deadline 1 November)
• The September releases do not fix it. The fixes for August's CVE-2026-20349 (also a VPN denial of service, already in KEV) and the September hardening releases (such as ASA 9.22.3.26 and FTD 7.6.6) are all within the affected range
• Cisco has published an unofficial Japanese translation (the English version prevails). As of 31 October, neither JPCERT/CC nor IPA had issued an alert

Affected configurations and products

• ASA / FTD devices are affected if remote access SSL VPN is enabled (enable <interface> in the webvpn configuration) and a tunnel group has secondary-authentication-server-group (secondary authentication) configured
• With tunnel-group-list enable, every tunnel group is in scope, including DefaultWEBVPNGroup and profiles not shown on the login page; without it, only DefaultWEBVPNGroup is in scope
• Unlike August's CVE-2026-20349, IKEv2 client services and ZTNA are not listed as vulnerable configurations
• Not affected (confirmed by Cisco): Cloud-delivered Firewall, cdFMC, Secure Access and Secure FMC Software. Cisco-run cloud services need no action, but self-managed ASAv / FTDv must be upgraded

Fix: fixed versions and steps per platform and manager

• ASA fixed releases: 9.16 and earlier → 9.16.4.104, 9.18 → 9.18.4.96, 9.20 → 9.20.4.50, 9.22 → 9.22.3.200, 9.23 → 9.23.1.48, 9.24 → 9.24.1.27 (9.24.10 line → 9.24.10.1)
• FTD fixed releases: 7.0 and earlier → 7.0.11, 7.2 → 7.2.13, 7.4 → 7.4.9, 7.6 → 7.6.7, 7.7 → 7.7.14, 10.0 → 10.0.3, 10.1 → 10.1.1
• Trains without a fix: ASA 9.19 and FTD 7.3 left maintenance on 18 May 2026; they are affected but have no fixed release. Move ASA 9.19 to 9.20.4.50 or later, and FTD 7.3 to 7.4.9 or 7.6.7
• Avoid downgrades: do not move a device on the 9.24.10 line to 9.24.1.27. If you run a hot-fix build numbered higher than the fixed build, also confirm with the Software Checker or Cisco TAC
• Trains nearing end of maintenance: ASA 9.16 / 9.18 and FTD 7.0 / 7.2 stop receiving updates on 18 November 2026; Cisco points ASA users to 9.20. Also, 7.6.6, the suggested release in the FTD compatibility guide, is affected, and Cisco says the advisory's version takes precedence
• Getting the software: downloads require a Cisco.com account and a service contract. Without a contract, Cisco's policy allows free updates case by case for serious vulnerabilities; ask TAC and quote the advisory URL
• ASA (standalone appliance): back up the configuration (on appliance-mode models such as Firepower 1000 / 2100 and Secure Firewall 1200 / 3100 / 4200, if you previously set a non-default ASDM image, first run asdm image disk0:/asdm.bin after configure terminal, then write memory; on ASAv, ISA 3000 and ASA 5500-X, also copy the new ASDM image and set it with asdm image disk0:/<asdm-image> in step 3), then run the following in order

1. Copy the image to the device: copy https://<server>/<image> disk0:/<image> (note that a password in the URL stays on the command line)
2. After configure terminal, check the current boot image setting with show running-config boot system
3. Remove the old entry with no boot system disk0:/<old-image> and set the new image with boot system disk0:/<image>. ASAv, ISA 3000 and ASA 5500-X allow up to four boot entries, so remove them all
4. Save with write memory, reload with reload, and confirm with show version

• Failover pairs: copy the image to the standby as well with failover exec mate copy /noconfirm https://<server>/<image> disk0:/<image>, change the boot setting and run write memory. Reload the standby with failover reload-standby, wait until show failover shows Standby Ready, switch over with no failover active, and run failover reload-standby again from the new active unit. Apart from GTP inspection state, this upgrade causes no downtime
• Platform limits: on Firepower 2100, ASA 9.20 is the last train, so use 9.20.4.50. Firepower 4110 / 4120 / 4140 / 4150 and Firepower 9300 SM-24 / 36 / 44 stop at 9.18, and ASA 5506-X / 5508-X / 5516-X stop at 9.16, so use 9.18.4.96 and 9.16.4.104 respectively (both trains stop receiving updates on 18 November 2026). ASA 5525-X / 5545-X / 5555-X (last: 9.14) and ASA 5512-X / 5515-X / 5585-X and ASASM (last: 9.12) have no fixed release they can run. On Firepower 4100 / 9300, upgrade FXOS first if needed (traffic stops for up to about 45 minutes). ASAv in public clouds is upgraded the same way, with an image downloaded from Cisco.com
• FTD managed by FMC: upgrade FMC first. FMC must run the same or a newer version than its devices (FMC 7.6.7 was also released on 28 October). If FMC is older than the fix for its own CVE-2026-20079 (Cisco score CVSS 10.0, added to KEV on 9 September; fixed in 7.4.8, 7.6.6 and others), take its management interface off the internet and upgrade FMC first
• On FMC 10.x, upgrade from Administration > Upgrades & updates > Product Upgrades. HA pairs upgrade the standby first and the roles switch. Do not deploy configuration during the upgrade, and expect Snort to restart on the first deployment afterwards, briefly interrupting inspection. Fixes in fourth-digit patch releases can be missing from later releases, so confirm your target with the Software Checker
• FTD managed by FDM: upgrade to the same fixed release following Cisco's FDM upgrade steps, then check with show version

If you cannot update right away (temporary mitigations)

Cisco says no workarounds address the vulnerability, but it gives two temporary mitigations. They were validated only in Cisco's test environment, and you must judge their impact yourself.

• Case 1 (DefaultWEBVPNGroup does not use secondary authentication): after configure terminal, enter WebVPN configuration mode with webvpn and run no tunnel-group-list enable. Users can then no longer choose a connection profile on the login page
• Case 2 (DefaultWEBVPNGroup uses secondary authentication): after configure terminal, enter tunnel-group DefaultWEBVPNGroup general-attributes and remove secondary authentication with no secondary-authentication-server-group. Removing the second factor lowers VPN security. The Case 1 change alone does not remove exposure here
• In both cases, save the change with write memory; otherwise the device returns to the old configuration when an attack makes it reload
• On FTD, the same change would be made in the remote access VPN policy in FMC or FDM and then deployed, but Cisco gives no FTD-specific steps
• If a device has reloaded unexpectedly, show crashinfo shows the crash information

FTD Snort 3 fixes of 21 October

In its scheduled 21 October publication, Cisco released Snort 3 fixes for FTD. The new FTD fixed releases (such as 7.6.7) are all later than those.

• Snort 3 hardening release (Cisco Security Impact Rating: Critical): the highest is CVE-2026-20043 (Cisco score CVSS 9.0). FTD fixed releases are 7.0.10 / 7.2.12 / 7.4.8 / 7.6.6 / 7.7.13 / 10.0.2 / 10.1.0
• The individual advisories (MIME, Netflow, GRE, GTP, VBA macro decompression and others) are all denials of service scored CVSS 5.3 to 5.8 by Cisco. VBA macro decompression (CVE-2026-20218) does not affect you if it stays disabled, which is the default
• ASA and FMC are not among the affected products of these advisories, and as of 31 October none of them had been seen exploited. Use show snort3 status to check whether FTD is running Snort 3

What to Check After Updating

• Versions: for Ivanti, System > Status on every node; for GitLab, sudo gitlab-rake gitlab:env:info and gitlab-runner --version; for ASA and FTD, show version. For Cisco, also use the Software Checker
• Restarts: on GitLab, check uptimes with sudo gitlab-ctl status; restart long-running processes of Ruby applications; pull images again and recreate containers. On ASA failover pairs, check both units with show failover
• Patching does not undo an intrusion: for Ivanti, do network and memory forensics (memory evidence is lost when the upgrade reboots the appliance, so capture it before upgrading if you can); for GitLab, review logs with the detection rules and rotate secrets; for Cisco, check for unexpected reloads, and if an FMC on a release affected by CVE-2026-20079 was reachable from the internet, look for the indicator in Cisco's advisory (/var/tmp/license.tmp in the logs) and contact TAC if you find it
• KEV status: KEV is updated continually. Check the latest entries and deadlines in CISA's KEV data
• For products that embed GitLab or Ruby, and for managed services built on Cisco or Ivanti equipment, check each provider's information

Official Sources

• Ivanti: Ivanti advisory, 25.x compatibility guide, Ivanti recovery steps, CISA alert, Volexity report, Volexity IOCs and YARA rules
• GitLab: 19.5.3 patch release, 19.5.1 patch release, 19.4.2 patch release, required upgrade stops, Linux package upgrade steps, Runner upgrade steps, Ruby announcement
• Cisco: CVE-2026-76418 advisory, Japanese translation of the advisory, Snort 3 hardening release, ASA upgrade guide
• Public agencies: CISA KEV addition notice (29 October), JPCERT/CC weekly report, 21 October, JPCERT/CC weekly report, 28 October

Disclaimer

This article is Two Sheep Co., Ltd.'s summary of public information as of 31 October 2026 and does not guarantee the behaviour or safety of any product. Always check each vendor's latest information before you start. Company and product names are trademarks or registered trademarks of their respective owners.

If you need on-site work for servers in a data center, such as reboots, console access or hardware swaps, contact us about our Remote Hands service.