Ruby 3.4.12: Regexp Fixes, GitLab CVEs and Checks

Ruby 3.4.12, 4.0.9 and 3.3.13 include fixes for regular-expression compilation bugs underlying four GitLab CVEs. Ruby’s October 23, 2026 notice identifies CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264. The relevant application boundary is compiling an attacker-controlled pattern, not merely matching user text against a developer-written expression. Ruby’s official Regexp compilation notice.

For a Ruby application owner, begin with the feature that accepts a pattern. A saved search, tenant-configurable filter or CI rule can turn user data into executable pattern syntax. An application that accepts ordinary text and applies a fixed validation expression presents a different boundary. That distinction determines where to review code and what an upgrade needs to verify.

GitLab CVEs and Ruby releases answer different questions

The Ruby notice explains that GitLab patched the Ruby runtime it distributes. Ruby has not requested its own CVE identifiers for these fixes at the time of that notice. Do not invent a separate Ruby CVE or assume an operating-system Ruby update upgrades the runtime bundled inside a GitLab installation. CVE ownership and recommended releases.

Build the inventory around executable ownership. The web tier, job runner and maintenance container may use different Ruby installations. A deployment ticket should name the application artifact and the process family it replaces. A package installation in a shared base image is only useful if a rebuilt artifact actually reaches those processes.

Compilation happens before matching protections help

Ruby’s notice says untrusted patterns can enter through Regexp constructors or interpolation, and that Regexp.timeout and short pattern limits do not reliably prevent these compilation defects. Applications using only developer-written expressions are outside the described input path. Affected input path and mitigation limits.

The operational consequence is that a matching-time test can answer the wrong question. A request may fail while constructing the expression, before the application attempts to match any subject string. Review where the pattern is created and cached, not only where the matching function receives text. Error handling can explain a failure to the caller, but it cannot retroactively make an unsafe native compilation safe.

Explore Penligent for authorized security testing

Review every place that promotes text into pattern syntax

Use the following read-only search from the root of a repository you are authorized to review. It identifies obvious constructors; it is neither a complete data-flow analysis nor a vulnerability detector. Follow wrappers and configuration loaders when they construct patterns indirectly. The Regexp API documentation helps identify constructors; use the documentation for your deployed Ruby version.

rg -n 'Regexp\.(new|compile|union)' --glob '*.rb' .

For each result, document who controls the input, whether it is stored, and which identities can trigger compilation later. A low-privilege account saving a rule and a background worker compiling it are one workflow, even though they execute in different processes. Treat imported configuration and integration-provided patterns as separate input sources rather than assuming every value originated with a trusted developer.

Avoid declaring every constructor unsafe. A fixed constant passed to a constructor does not acquire attacker control simply because the API name appears in a search. Conversely, a wrapper with a harmless name can hide the same boundary. A useful review record explains the source and transformation of the value, then identifies the runtime that consumes it.

When the feature needs text search, keep the input as text

If the product requirement is literal substring search, prefer a literal operation. Ruby’s String#include? documentation defines that operation without granting regular-expression syntax to the search term. Changing a regex feature to literal matching changes its semantics, so make that a deliberate product decision rather than a silent emergency substitution.

# Proposed Ruby application pattern for literal substring search.
# No dynamic regular expression is compiled.
text = "build agent.a completed"
term = "agent.a"
puts text.include?(term)

We did not execute Ruby in this environment. The Python model below was executed locally to illustrate the same literal-search requirement with benign strings. It is not a Ruby runtime test, patch validation or reproduction of a memory-safety defect.

text = "build agent.a completed"
checks = {"agent.a": True, "agent.*": False, "[agent]": False}
for term, expected in checks.items():
    actual = term in text
    assert actual == expected
    print(repr(term), actual)

'agent.a' True
'agent.*' False
'[agent]' False

The example gives the reviewer a concrete requirement: punctuation remains punctuation. A staging test should then verify that behavior in the real application, including encoding, case handling and existing saved searches. If users need genuine regex syntax, literal search is not a drop-in replacement; upgrade the runtime and review the feature’s trust and resource boundaries.

Collect runtime evidence inside the deployed application environment

ruby -v
ruby -rrbconfig -e 'puts RUBY_DESCRIPTION; puts RbConfig.ruby'
bundle exec ruby -rrbconfig -e 'puts RUBY_DESCRIPTION; puts RbConfig.ruby' 

These commands are proposed inventory checks, not commands we ran against your service. Execute them only in the intended application environment. A shell can select one interpreter while a service manager launches another, so compare the output with the service definition, container image or platform deployment record.

Explore Penligent for authorized security testing

Make the upgrade record survive a rolling deployment

For the first rollout, retain the old and new image identities, the selected release line and the owner of every worker group. Verify the application’s supported dependency set before switching major versions merely to reach a fixed number. The complete fixed release set is in the official notice; use vendor backport documentation when your platform maintains its own revision scheme.

Retest a conventional pattern supplied by a trusted test fixture, the literal-search feature if present, a normal CI or filtering workflow, and a supported error case. Use small benign inputs. A job failing after the upgrade can reflect changed behavior or a dependency mismatch; it does not establish that an exploit was blocked. Record the expected outcome and the actual result separately.

Keep Regexp fixes separate from unrelated release contents

A release can contain several fixes with different exposure conditions. Ruby 3.3.13 also updates resolv for separate CVEs, according to its release announcement. Do not describe every change in the release as a regular-expression vulnerability or assume one application test covers them all.

If a service accepts customer-defined pattern languages, a failed compilation or worker crash deserves correlation with request and job records. Preserve the pattern source, application role, worker identity and time under your incident process, while avoiding unnecessary retention of customer secrets. A crash alone is not proof of remote code execution, and a successful update does not resolve an earlier compromise investigation.

Frequently asked questions

Does this mean every Ruby website has GitLab’s RCE?

No. The described boundary requires attacker-controlled pattern compilation. Assess the actual application feature and runtime rather than transferring GitLab’s impact to every Ruby service.

Is Regexp.timeout a substitute for upgrading?

No. The official notice distinguishes compilation defects from matching-time controls. Follow the fixed-release or vendor-backport guidance.

Does updating host Ruby repair GitLab?

Not necessarily. Verify the runtime delivered and used by the GitLab package and follow GitLab’s own release guidance.

Can literal search replace a user-supplied regex?

Only when the product requirement is literal text matching. Regex-enabled features need a deliberate compatibility decision.

Did Penligent reproduce the vulnerability?

No. The executed example is a benign Python literal-search model; proposed Ruby inventory commands require validation in your own environment.

For an authorized assessment, define the permitted systems and evidence requirements before testing. Evaluate any automation by the observations it can actually preserve. This article does not claim a dedicated Penligent detector or a Penligent reproduction of the reported flaw.

The video below introduces a general AI-assisted pentesting workflow. It is not an exploit demonstration for the issues discussed here.