Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article4 min readViews0

Ruby Released Fixes for Critical GitLab Vulnerabilities

On October 23, Ruby versions 4.0.9, 3.4.12, and 3.3.13 were released. We explain which applications are affected, why the GitLab package requires separate verification, and what to ask the server administrator.

АльбинаCommunity author★ 144
Comments 0

Illustration: A red faceted crystal in a metal setting on a light stone
In this article

On October 23, 2026, the Ruby project released versions 4.0.9, 3.4.12, and 3.3.13 with fixes for regular expression handling bugs. These bugs underlie several critical GitLab vulnerabilities. If your organization hosts its own GitLab on a VPS or server, or uses a Ruby application with custom search templates, you should verify updates for the running application and its runtime environment.

What Changed on October 23

In the new Ruby notification, developers explained the link between Onigmo engine errors and four GitLab identifiers: CVE-2026-89078, CVE-2026-93577, CVE-2026-97229, and CVE-2026-110264. All listed fixes are included in Ruby 4.0.9, 3.4.12, and 3.3.13.

A significant risk boundary exists when compiling a regular expression from a string controlled by an attacker. If an application uses only expressions written by its developers, Ruby explicitly excludes it from this scenario. Limiting expression execution time and template length do not provide reliable protection against these bugs.

The identifiers refer to GitLab vulnerabilities. At the time of notification, the Ruby project did not request its own CVEs for these fixes and continues to discuss approaches for handling untrusted templates. Therefore, the mere presence of Ruby on a server does not mean that any application hosted there is vulnerable.

For a self-hosted GitLab, verify the GitLab package

GitLab released a critical update on October 21 to fix CVE-2026-110264. The vendor rated this vulnerability at 10.0 on the CVSS scale: under certain conditions, it allows code execution on the server without authorization. A new fact from October 23 is the release of fixes for the corresponding errors directly in Ruby; this represents a separate update level.

Fixes for CVE-2026-110264 are available for GitLab CE and EE in versions 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, and 19.5.1. Selecting the appropriate release depends on the current version and the standard update path. GitLab reports that the GitLab cloud service has already received the fix.

GitLab provides its own Ruby environment. Replacing the system interpreter without verifying the package contents does not confirm that the GitLab vulnerability is fixed. Conversely, for an application Ruby service, you must verify the execution environment actually used by its running processes. The package provider may backport a fix to a build with a different version number; confirmation must be sought in their notifications.

What to request from the administrator

  • Determine whether a self-hosted GitLab or a Ruby application accepting regular expressions from untrusted input is in use. Independently verify the application server and the container image being used.
  • Identify the installed package, the source of the fix, and the active execution environment. The version shown in the administrator's personal console may differ from the service environment.
  • Before updating, prepare a recovery plan and verify the vendor's requirements. GitLab warns about database migrations: for a single installation, these require downtime.
  • After updating, verify the used scenarios: repository access, build execution, and exchange with external systems. If signs of intrusion are detected, preserve the logs and conduct a separate investigation.

A vulnerability report does not prove a successful breach of a specific installation. For new deployments, also verify base images and pinned dependencies: a patched server does not prevent re-deploying an old environment from a saved image.

Information is current as of October 24, 2026, 03:00 MSK. Event dates: GitLab update — October 21; Ruby notifications and releases — October 23. Sources are official project announcements; the state of a specific server must be verified separately.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.