[Q&A] Questions about CVE-2026_41316 in fluent-package v6.0.4

[ykai8975]

Hello,

We are currently using fluent-package v6.0.4.

Our vulnerability scanner reports CVE-2026-41316 against the default Ruby gem:

Name: erb
Version: 4.0.4

Path:
/opt/fluent/lib/ruby/gems/3.4.0/specifications/default

According to the advisory, the fixed version is erb 4.0.4.1.

Since erb is a default gem, installing a newer erb version without removing the original default gem will not work.

Questions:

1. Is fluent-package v6.0.4 affected by CVE-2026-41316?
2. Has the fix been backported into fluent-package v6.0.4?
3. Is there a planned fluent-package release that includes erb 4.0.4.1 or later?
4. What is the recommended remediation for customers using fluent-package v6.0.4?

Thanks in advance.

Environment

- Fluentd version:1.19.3
- TD Agent version:
- Fluent Package version:6.0.4
- Docker image (tag):
- Operating system:Red Hat 9.8
- Kernel version:

[Watson1978]

Thanks for the detailed report.

1. Is fluent-package v6.0.4 affected?

The scanner's detection is accurate: v6.0.4 bundles Ruby 3.4.9, whose default erb gem is 4.0.4, which matches the affected range of the advisory.

However, we do not consider Fluentd itself to have a practical attack path forthis CVE.
Exploitation requires Marshal.load() on attacker-controlled data in a process that has erb loaded (the published gadget chain additionally requires ActiveSupport).

In fluent-package v6.0.4:

• The erb library is not loaded by Fluentd core at runtime: require "erb" appears only in fluent-plugin-generate and fluent-plugin-config-format (developer CLI tools).
  Note that some bundled plugins can pull it in transitively -- for example out_prometheus_pushgateway requires prometheus/client/push, which requires erb. This does not change the assessment, since the decisive factor is the absence of any Marshal.load() on untrusted input, not whether ERB happens to be loaded.

If you run third-party plugins that call Marshal.load() on untrusted input,
that assessment would need to be revisited for your specific setup.

2. Has the fix been backported into v6.0.4?

No. fluent-package ships the upstream Ruby release as-is and does not patch
default gems independently, so v6.0.4 will continue to report erb 4.0.4.

3. Is a release with erb 4.0.4.1 or later planned?

Ruby 3.4.10 (released 2026-06-30) includes erb 4.0.4.1 with the def_method guard.
fluent-package v6.0.4 was released on 2026-06-26, just before that.
Bumping the bundled Ruby to 3.4.10 is the intended fix and will also pick up the net-imap security updates in that release.

We have a plan to release fluent-package v6.0.5 at end of September.
The version will bundle Ruby 3.4.10.

4. Recommended remediation for v6.0.4 users

1. Upgrade to v6.0.5 when it is released.
2. Until then, the analysis in (1) should support a documented risk acceptance for a default deployment.
3. One correction on your premise: installing a newer erb does work. RubyGems activates the highest available version, so require "erb" picks up the installed gem over the default one -- removing the default gem is not
   necessary:

   fluent-gem install erb -v 4.0.4.1
   /opt/fluent/bin/ruby -rerb -e 'puts ERB::VERSION'   #=> 4.0.4.1
   

   Two caveats: the erb gem builds a small C extension, so a compiler toolchain is required; and the default gemspec at .../specifications/default/erb-4.0.4.gemspec stays on disk, so most
   scanners will keep reporting the finding regardless. Deleting that file is not supported and we don't recommend it.

[ykai8975]

Thank you for the detailed explanation.
This answers all of our questions and gives us the information we need.
Much appreciated!