fluentd

The out_http output plugin allows the use of placeholders (such as ${tag}) in the endpoint configuration parameter. It was discovered that if the placeholder value is derived from untrusted user input, an attacker can maliciously control the destination hostname of the outbound HTTP requests made by Fluentd.

Impact

This vulnerability allows for a Server-Side Request Forgery (SSRF) attack. An unauthenticated attacker can force the Fluentd node to send HTTP requests to arbitrary internal services. This can lead to unauthorized access to internal APIs, data exfiltration, or the compromise of cloud metadata endpoints (e.g., AWS IMDS 169.254.169.254).

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Avoid Dynamic Hostnames

   • Do not use the placeholder in the endpoint parameter as hostname.

2. Restrict Network Access

   • Use firewall rules (e.g., iptables, AWS Security Groups) to block the Fluentd node from accessing sensitive internal IP addresses, specifically the cloud provider's metadata service and other internal microservices that Fluentd does not explicitly need to access.

3. Restrict allowed hosts

   • Inject filter to accept allowed hosts in placeholders explicitly if possible.

Fluentd's in_http and in_forward plugins support receiving gzip-compressed data. While Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via body_size_limit or chunk_size_limit), it was discovered that there is no limit enforced on the size of the decompressed data.

If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.

Impact

This vulnerability allows for a Denial of Service (DoS) attack via memory exhaustion. The rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system. This results in the disruption of all log collection and forwarding capabilities on the affected node.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as 9880 for in_http and 24224 for in_forward) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Use a Reverse Proxy
   • If developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.

Fluentd's Monitor Agent plugin (in_monitor_agent) exposes internal metrics and plugin information via a REST API. It was discovered that the API response (/api/plugins.json and related endpoints) unintentionally includes internal instance variables of loaded plugins.

If any plugins store sensitive information—such as database passwords, API keys, or cloud credentials—in its instance variables, this information may be exposed in plain text to any user or system that has HTTP access to the Monitor Agent API.

Impact

This vulnerability allows for unauthorized information disclosure. An attacker who can reach the Monitor Agent API port (default: 24220) can potentially extract sensitive credentials used by other Fluentd plugins. The impact severity depends highly on the network configuration (whether the Monitor Agent port is exposed to untrusted networks) and the specific plugins configured in the Fluentd instance.

Patches:

v1.19.3

Workarounds

If usesrs cannot immediately update Fluentd to the patched version, they can mitigate this risk by strictly controlling access to the Monitor Agent port.

Ensure the Monitor Agent is only bound to localhost (127.0.0.1) rather than 0.0.0.0.

<source>
  @type monitor_agent
  bind 127.0.0.1
  port 24220
</source>

Use firewall rules (e.g., iptables, AWS Security Groups) to block access to the Monitor Agent port (24220) from untrusted networks or instances.

Fluentd allows dynamically constructing file paths using the ${tag} placeholder. It was discovered that validation for this placeholder was insufficient.

If a Fluentd instance is configured to receive logs from untrusted sources and uses the ${tag} placeholder in file configurations (such as the path parameter in the out_file plugin), an attacker can inject path traversal characters (e.g., ../).

When combined with certain formatting options, this vulnerability allows an attacker to write arbitrary files or overwrite existing files on the system with attacker-controlled content, bypassing intended directory restrictions.

Impact

This vulnerability allows for Arbitrary File Write, which can be directly escalated to full Remote Code Execution (RCE). An attacker could achieve RCE by overwriting critical system files, injecting executable plugins, or modifying configuration files. The impact is Critical as it can lead to full system compromise without any authentication, depending on the Fluentd configuration and the privileges of the Fluentd process.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as in_forward on default port 24224) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Run Fluentd as a non-root user
   • Dropping privileges prevents Fluentd from writing to sensitive system directories (e.g., /etc/), significantly mitigating the risk of system-wide RCE.
3. Revise configurations
   • Do not use the ${tag} placeholder in the path parameter of output plugins (like out_file) if the tag originates from an untrusted source.
4. Filter incoming tags
   • Strictly validate and filter incoming tags at the input layer (e.g., using fluent-plugin-rewrite-tag-filter) to drop any tags containing . or / characters.

The out_http output plugin allows the use of placeholders (such as ${tag}) in the endpoint configuration parameter. It was discovered that if the placeholder value is derived from untrusted user input, an attacker can maliciously control the destination hostname of the outbound HTTP requests made by Fluentd.

Impact

This vulnerability allows for a Server-Side Request Forgery (SSRF) attack. An unauthenticated attacker can force the Fluentd node to send HTTP requests to arbitrary internal services. This can lead to unauthorized access to internal APIs, data exfiltration, or the compromise of cloud metadata endpoints (e.g., AWS IMDS 169.254.169.254).

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Avoid Dynamic Hostnames

   • Do not use the placeholder in the endpoint parameter as hostname.

2. Restrict Network Access

   • Use firewall rules (e.g., iptables, AWS Security Groups) to block the Fluentd node from accessing sensitive internal IP addresses, specifically the cloud provider's metadata service and other internal microservices that Fluentd does not explicitly need to access.

3. Restrict allowed hosts

   • Inject filter to accept allowed hosts in placeholders explicitly if possible.

Fluentd's in_http and in_forward plugins support receiving gzip-compressed data. While Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via body_size_limit or chunk_size_limit), it was discovered that there is no limit enforced on the size of the decompressed data.

If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.

Impact

This vulnerability allows for a Denial of Service (DoS) attack via memory exhaustion. The rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system. This results in the disruption of all log collection and forwarding capabilities on the affected node.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as 9880 for in_http and 24224 for in_forward) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Use a Reverse Proxy
   • If developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.

Fluentd's Monitor Agent plugin (in_monitor_agent) exposes internal metrics and plugin information via a REST API. It was discovered that the API response (/api/plugins.json and related endpoints) unintentionally includes internal instance variables of loaded plugins.

If any plugins store sensitive information—such as database passwords, API keys, or cloud credentials—in its instance variables, this information may be exposed in plain text to any user or system that has HTTP access to the Monitor Agent API.

Impact

This vulnerability allows for unauthorized information disclosure. An attacker who can reach the Monitor Agent API port (default: 24220) can potentially extract sensitive credentials used by other Fluentd plugins. The impact severity depends highly on the network configuration (whether the Monitor Agent port is exposed to untrusted networks) and the specific plugins configured in the Fluentd instance.

Patches:

v1.19.3

Workarounds

If usesrs cannot immediately update Fluentd to the patched version, they can mitigate this risk by strictly controlling access to the Monitor Agent port.

Ensure the Monitor Agent is only bound to localhost (127.0.0.1) rather than 0.0.0.0.

<source>
  @type monitor_agent
  bind 127.0.0.1
  port 24220
</source>

Use firewall rules (e.g., iptables, AWS Security Groups) to block access to the Monitor Agent port (24220) from untrusted networks or instances.

Fluentd allows dynamically constructing file paths using the ${tag} placeholder. It was discovered that validation for this placeholder was insufficient.

If a Fluentd instance is configured to receive logs from untrusted sources and uses the ${tag} placeholder in file configurations (such as the path parameter in the out_file plugin), an attacker can inject path traversal characters (e.g., ../).

When combined with certain formatting options, this vulnerability allows an attacker to write arbitrary files or overwrite existing files on the system with attacker-controlled content, bypassing intended directory restrictions.

Impact

This vulnerability allows for Arbitrary File Write, which can be directly escalated to full Remote Code Execution (RCE). An attacker could achieve RCE by overwriting critical system files, injecting executable plugins, or modifying configuration files. The impact is Critical as it can lead to full system compromise without any authentication, depending on the Fluentd configuration and the privileges of the Fluentd process.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as in_forward on default port 24224) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Run Fluentd as a non-root user
   • Dropping privileges prevents Fluentd from writing to sensitive system directories (e.g., /etc/), significantly mitigating the risk of system-wide RCE.
3. Revise configurations
   • Do not use the ${tag} placeholder in the path parameter of output plugins (like out_file) if the tag originates from an untrusted source.
4. Filter incoming tags
   • Strictly validate and filter incoming tags at the input layer (e.g., using fluent-plugin-rewrite-tag-filter) to drop any tags containing . or / characters.

The out_http output plugin allows the use of placeholders (such as ${tag}) in the endpoint configuration parameter. It was discovered that if the placeholder value is derived from untrusted user input, an attacker can maliciously control the destination hostname of the outbound HTTP requests made by Fluentd.

Impact

This vulnerability allows for a Server-Side Request Forgery (SSRF) attack. An unauthenticated attacker can force the Fluentd node to send HTTP requests to arbitrary internal services. This can lead to unauthorized access to internal APIs, data exfiltration, or the compromise of cloud metadata endpoints (e.g., AWS IMDS 169.254.169.254).

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Avoid Dynamic Hostnames

   • Do not use the placeholder in the endpoint parameter as hostname.

2. Restrict Network Access

   • Use firewall rules (e.g., iptables, AWS Security Groups) to block the Fluentd node from accessing sensitive internal IP addresses, specifically the cloud provider's metadata service and other internal microservices that Fluentd does not explicitly need to access.

3. Restrict allowed hosts

   • Inject filter to accept allowed hosts in placeholders explicitly if possible.

Fluentd's in_http and in_forward plugins support receiving gzip-compressed data. While Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via body_size_limit or chunk_size_limit), it was discovered that there is no limit enforced on the size of the decompressed data.

If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.

Impact

This vulnerability allows for a Denial of Service (DoS) attack via memory exhaustion. The rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system. This results in the disruption of all log collection and forwarding capabilities on the affected node.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as 9880 for in_http and 24224 for in_forward) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Use a Reverse Proxy
   • If developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.

Fluentd's Monitor Agent plugin (in_monitor_agent) exposes internal metrics and plugin information via a REST API. It was discovered that the API response (/api/plugins.json and related endpoints) unintentionally includes internal instance variables of loaded plugins.

If any plugins store sensitive information—such as database passwords, API keys, or cloud credentials—in its instance variables, this information may be exposed in plain text to any user or system that has HTTP access to the Monitor Agent API.

Impact

This vulnerability allows for unauthorized information disclosure. An attacker who can reach the Monitor Agent API port (default: 24220) can potentially extract sensitive credentials used by other Fluentd plugins. The impact severity depends highly on the network configuration (whether the Monitor Agent port is exposed to untrusted networks) and the specific plugins configured in the Fluentd instance.

Patches:

v1.19.3

Workarounds

If usesrs cannot immediately update Fluentd to the patched version, they can mitigate this risk by strictly controlling access to the Monitor Agent port.

Ensure the Monitor Agent is only bound to localhost (127.0.0.1) rather than 0.0.0.0.

<source>
  @type monitor_agent
  bind 127.0.0.1
  port 24220
</source>

Use firewall rules (e.g., iptables, AWS Security Groups) to block access to the Monitor Agent port (24220) from untrusted networks or instances.

Fluentd allows dynamically constructing file paths using the ${tag} placeholder. It was discovered that validation for this placeholder was insufficient.

If a Fluentd instance is configured to receive logs from untrusted sources and uses the ${tag} placeholder in file configurations (such as the path parameter in the out_file plugin), an attacker can inject path traversal characters (e.g., ../).

When combined with certain formatting options, this vulnerability allows an attacker to write arbitrary files or overwrite existing files on the system with attacker-controlled content, bypassing intended directory restrictions.

Impact

This vulnerability allows for Arbitrary File Write, which can be directly escalated to full Remote Code Execution (RCE). An attacker could achieve RCE by overwriting critical system files, injecting executable plugins, or modifying configuration files. The impact is Critical as it can lead to full system compromise without any authentication, depending on the Fluentd configuration and the privileges of the Fluentd process.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as in_forward on default port 24224) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Run Fluentd as a non-root user
   • Dropping privileges prevents Fluentd from writing to sensitive system directories (e.g., /etc/), significantly mitigating the risk of system-wide RCE.
3. Revise configurations
   • Do not use the ${tag} placeholder in the path parameter of output plugins (like out_file) if the tag originates from an untrusted source.
4. Filter incoming tags
   • Strictly validate and filter incoming tags at the input layer (e.g., using fluent-plugin-rewrite-tag-filter) to drop any tags containing . or / characters.

The out_http output plugin allows the use of placeholders (such as ${tag}) in the endpoint configuration parameter. It was discovered that if the placeholder value is derived from untrusted user input, an attacker can maliciously control the destination hostname of the outbound HTTP requests made by Fluentd.

Impact

This vulnerability allows for a Server-Side Request Forgery (SSRF) attack. An unauthenticated attacker can force the Fluentd node to send HTTP requests to arbitrary internal services. This can lead to unauthorized access to internal APIs, data exfiltration, or the compromise of cloud metadata endpoints (e.g., AWS IMDS 169.254.169.254).

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Avoid Dynamic Hostnames

   • Do not use the placeholder in the endpoint parameter as hostname.

2. Restrict Network Access

   • Use firewall rules (e.g., iptables, AWS Security Groups) to block the Fluentd node from accessing sensitive internal IP addresses, specifically the cloud provider's metadata service and other internal microservices that Fluentd does not explicitly need to access.

3. Restrict allowed hosts

   • Inject filter to accept allowed hosts in placeholders explicitly if possible.

Fluentd's in_http and in_forward plugins support receiving gzip-compressed data. While Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via body_size_limit or chunk_size_limit), it was discovered that there is no limit enforced on the size of the decompressed data.

If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.

Impact

This vulnerability allows for a Denial of Service (DoS) attack via memory exhaustion. The rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system. This results in the disruption of all log collection and forwarding capabilities on the affected node.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as 9880 for in_http and 24224 for in_forward) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Use a Reverse Proxy
   • If developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.

Fluentd's Monitor Agent plugin (in_monitor_agent) exposes internal metrics and plugin information via a REST API. It was discovered that the API response (/api/plugins.json and related endpoints) unintentionally includes internal instance variables of loaded plugins.

If any plugins store sensitive information—such as database passwords, API keys, or cloud credentials—in its instance variables, this information may be exposed in plain text to any user or system that has HTTP access to the Monitor Agent API.

Impact

This vulnerability allows for unauthorized information disclosure. An attacker who can reach the Monitor Agent API port (default: 24220) can potentially extract sensitive credentials used by other Fluentd plugins. The impact severity depends highly on the network configuration (whether the Monitor Agent port is exposed to untrusted networks) and the specific plugins configured in the Fluentd instance.

Patches:

v1.19.3

Workarounds

If usesrs cannot immediately update Fluentd to the patched version, they can mitigate this risk by strictly controlling access to the Monitor Agent port.

Ensure the Monitor Agent is only bound to localhost (127.0.0.1) rather than 0.0.0.0.

<source>
  @type monitor_agent
  bind 127.0.0.1
  port 24220
</source>

Use firewall rules (e.g., iptables, AWS Security Groups) to block access to the Monitor Agent port (24220) from untrusted networks or instances.

Fluentd allows dynamically constructing file paths using the ${tag} placeholder. It was discovered that validation for this placeholder was insufficient.

If a Fluentd instance is configured to receive logs from untrusted sources and uses the ${tag} placeholder in file configurations (such as the path parameter in the out_file plugin), an attacker can inject path traversal characters (e.g., ../).

When combined with certain formatting options, this vulnerability allows an attacker to write arbitrary files or overwrite existing files on the system with attacker-controlled content, bypassing intended directory restrictions.

Impact

This vulnerability allows for Arbitrary File Write, which can be directly escalated to full Remote Code Execution (RCE). An attacker could achieve RCE by overwriting critical system files, injecting executable plugins, or modifying configuration files. The impact is Critical as it can lead to full system compromise without any authentication, depending on the Fluentd configuration and the privileges of the Fluentd process.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as in_forward on default port 24224) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Run Fluentd as a non-root user
   • Dropping privileges prevents Fluentd from writing to sensitive system directories (e.g., /etc/), significantly mitigating the risk of system-wide RCE.
3. Revise configurations
   • Do not use the ${tag} placeholder in the path parameter of output plugins (like out_file) if the tag originates from an untrusted source.
4. Filter incoming tags
   • Strictly validate and filter incoming tags at the input layer (e.g., using fluent-plugin-rewrite-tag-filter) to drop any tags containing . or / characters.

The out_http output plugin allows the use of placeholders (such as ${tag}) in the endpoint configuration parameter. It was discovered that if the placeholder value is derived from untrusted user input, an attacker can maliciously control the destination hostname of the outbound HTTP requests made by Fluentd.

Impact

This vulnerability allows for a Server-Side Request Forgery (SSRF) attack. An unauthenticated attacker can force the Fluentd node to send HTTP requests to arbitrary internal services. This can lead to unauthorized access to internal APIs, data exfiltration, or the compromise of cloud metadata endpoints (e.g., AWS IMDS 169.254.169.254).

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Avoid Dynamic Hostnames

   • Do not use the placeholder in the endpoint parameter as hostname.

2. Restrict Network Access

   • Use firewall rules (e.g., iptables, AWS Security Groups) to block the Fluentd node from accessing sensitive internal IP addresses, specifically the cloud provider's metadata service and other internal microservices that Fluentd does not explicitly need to access.

3. Restrict allowed hosts

   • Inject filter to accept allowed hosts in placeholders explicitly if possible.

Fluentd's in_http and in_forward plugins support receiving gzip-compressed data. While Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via body_size_limit or chunk_size_limit), it was discovered that there is no limit enforced on the size of the decompressed data.

If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.

Impact

This vulnerability allows for a Denial of Service (DoS) attack via memory exhaustion. The rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system. This results in the disruption of all log collection and forwarding capabilities on the affected node.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as 9880 for in_http and 24224 for in_forward) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Use a Reverse Proxy
   • If developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.

Fluentd's Monitor Agent plugin (in_monitor_agent) exposes internal metrics and plugin information via a REST API. It was discovered that the API response (/api/plugins.json and related endpoints) unintentionally includes internal instance variables of loaded plugins.

If any plugins store sensitive information—such as database passwords, API keys, or cloud credentials—in its instance variables, this information may be exposed in plain text to any user or system that has HTTP access to the Monitor Agent API.

Impact

This vulnerability allows for unauthorized information disclosure. An attacker who can reach the Monitor Agent API port (default: 24220) can potentially extract sensitive credentials used by other Fluentd plugins. The impact severity depends highly on the network configuration (whether the Monitor Agent port is exposed to untrusted networks) and the specific plugins configured in the Fluentd instance.

Patches:

v1.19.3

Workarounds

If usesrs cannot immediately update Fluentd to the patched version, they can mitigate this risk by strictly controlling access to the Monitor Agent port.

Ensure the Monitor Agent is only bound to localhost (127.0.0.1) rather than 0.0.0.0.

<source>
  @type monitor_agent
  bind 127.0.0.1
  port 24220
</source>

Use firewall rules (e.g., iptables, AWS Security Groups) to block access to the Monitor Agent port (24220) from untrusted networks or instances.

Fluentd allows dynamically constructing file paths using the ${tag} placeholder. It was discovered that validation for this placeholder was insufficient.

If a Fluentd instance is configured to receive logs from untrusted sources and uses the ${tag} placeholder in file configurations (such as the path parameter in the out_file plugin), an attacker can inject path traversal characters (e.g., ../).

When combined with certain formatting options, this vulnerability allows an attacker to write arbitrary files or overwrite existing files on the system with attacker-controlled content, bypassing intended directory restrictions.

Impact

This vulnerability allows for Arbitrary File Write, which can be directly escalated to full Remote Code Execution (RCE). An attacker could achieve RCE by overwriting critical system files, injecting executable plugins, or modifying configuration files. The impact is Critical as it can lead to full system compromise without any authentication, depending on the Fluentd configuration and the privileges of the Fluentd process.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as in_forward on default port 24224) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Run Fluentd as a non-root user
   • Dropping privileges prevents Fluentd from writing to sensitive system directories (e.g., /etc/), significantly mitigating the risk of system-wide RCE.
3. Revise configurations
   • Do not use the ${tag} placeholder in the path parameter of output plugins (like out_file) if the tag originates from an untrusted source.
4. Filter incoming tags
   • Strictly validate and filter incoming tags at the input layer (e.g., using fluent-plugin-rewrite-tag-filter) to drop any tags containing . or / characters.

The out_http output plugin allows the use of placeholders (such as ${tag}) in the endpoint configuration parameter. It was discovered that if the placeholder value is derived from untrusted user input, an attacker can maliciously control the destination hostname of the outbound HTTP requests made by Fluentd.

Impact

This vulnerability allows for a Server-Side Request Forgery (SSRF) attack. An unauthenticated attacker can force the Fluentd node to send HTTP requests to arbitrary internal services. This can lead to unauthorized access to internal APIs, data exfiltration, or the compromise of cloud metadata endpoints (e.g., AWS IMDS 169.254.169.254).

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Avoid Dynamic Hostnames

   • Do not use the placeholder in the endpoint parameter as hostname.

2. Restrict Network Access

   • Use firewall rules (e.g., iptables, AWS Security Groups) to block the Fluentd node from accessing sensitive internal IP addresses, specifically the cloud provider's metadata service and other internal microservices that Fluentd does not explicitly need to access.

3. Restrict allowed hosts

   • Inject filter to accept allowed hosts in placeholders explicitly if possible.

Fluentd's in_http and in_forward plugins support receiving gzip-compressed data. While Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via body_size_limit or chunk_size_limit), it was discovered that there is no limit enforced on the size of the decompressed data.

If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.

Impact

This vulnerability allows for a Denial of Service (DoS) attack via memory exhaustion. The rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system. This results in the disruption of all log collection and forwarding capabilities on the affected node.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

1. Restrict Network Access
   • Ensure that Fluentd input ports (such as 9880 for in_http and 24224 for in_forward) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
2. Use a Reverse Proxy
   • If developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.

Fluentd's Monitor Agent plugin (in_monitor_agent) exposes internal metrics and plugin information via a REST API. It was discovered that the API response (/api/plugins.json and related endpoints) unintentionally includes internal instance variables of loaded plugins.

If any plugins store sensitive information—such as database passwords, API keys, or cloud credentials—in its instance variables, this information may be exposed in plain text to any user or system that has HTTP access to the Monitor Agent API.

Impact

This vulnerability allows for unauthorized information disclosure. An attacker who can reach the Monitor Agent API port (default: 24220) can potentially extract sensitive credentials used by other Fluentd plugins. The impact severity depends highly on the network configuration (whether the Monitor Agent port is exposed to untrusted networks) and the specific plugins configured in the Fluentd instance.

Patches:

v1.19.3

Workarounds

If usesrs cannot immediately update Fluentd to the patched version, they can mitigate this risk by strictly controlling access to the Monitor Agent port.

Ensure the Monitor Agent is only bound to localhost (127.0.0.1) rather than 0.0.0.0.

<source>
  @type monitor_agent
  bind 127.0.0.1
  port 24220
</source>

Use firewall rules (e.g., iptables, AWS Security Groups) to block access to the Monitor Agent port (24220) from untrusted networks or instances.