See how rsyslog compares to other vendors in security performance
An issue was discovered in Rsyslog v8.1908.0. contrib/pmcisconames/pmcisconames.c has a heap overflow in the parser for Cisco log messages. The parser tries to locate a log message delimiter (in this case, a space or a colon), but fails to account for strings that do not satisfy this constraint. If the string does not match, then the variable lenMsg will reach the value zero and will skip the sanity check that detects invalid log messages. The message will then be considered valid, and the parser will eat up the nonexistent colon delimiter. In doing so, it will decrement lenMsg, a signed integer, whose value was zero and now becomes minus one. The following step in the parser is to shift left the contents of the message. To do this, it will call memmove with the right pointers to the target and destination strings, but the lenMsg will now be interpreted as a huge value, causing a heap overflow.
An issue was discovered in Rsyslog v8.1908.0. contrib/pmaixforwardedfrom/pmaixforwardedfrom.c has a heap overflow in the parser for AIX log messages. The parser tries to locate a log message delimiter (in this case, a space or a colon) but fails to account for strings that do not satisfy this constraint. If the string does not match, then the variable lenMsg will reach the value zero and will skip the sanity check that detects invalid log messages. The message will then be considered valid, and the parser will eat up the nonexistent colon delimiter. In doing so, it will decrement lenMsg, a signed integer, whose value was zero and now becomes minus one. The following step in the parser is to shift left the contents of the message. To do this, it will call memmove with the right pointers to the target and destination strings, but the lenMsg will now be interpreted as a huge value, causing a heap overflow.
Last updated 25 August 2025
The zmq3 input and output modules in rsyslog before 8.28.0 interpreted description fields as format strings, possibly allowing a format string attack with unspecified impact.
contrib/pmdb2diag/pmdb2diag.c in Rsyslog v8.1908.0 allows out-of-bounds access because the level length is mishandled.
The ACL handling in rsyslog 3.12.1 to 3.20.0, 4.1.0, and 4.1.1 does not follow $AllowedSender directive, which allows remote attackers to bypass intended access restrictions and spoof log messages or create a large number of spurious messages.
Rsyslog is a rocket-fast system for log processing. From 8.2110.0 until 8.2604.0, the optional imhttp module's parseauthheader function in contrib/imhttp/imhttp.c allocates a zero-byte heap buffer with calloc(0, len) when an HTTP Basic Authorization value exceeds its fixed work buffer, then passes that pointer to aprbase64decode. An unauthenticated remote attacker can send an oversized encoded credential to an imhttp endpoint configured for Basic Authentication, causing decoded data to overwrite adjacent heap memory before credential validation. Deployments that do not install, load, and use imhttp with Basic Authentication are not affected. The demonstrated impact is a process crash that interrupts log collection, and code execution has not been demonstrated. This issue is fixed in version 8.2604.0.
Last updated 20 July 2026
Rsyslog is a rocket-fast system for log processing. From versions 1.15.0 to 8.2610.0, rsyslog's omfile dynaFile facility intentionally allows templates to generate flexible output paths. This supports valid deployments that route logs into different directories or use dynamically generated file names. A deployment becomes unsafe when a dynaFile template uses a value influenced by untrusted input as a path component without explicit secure-path handling. In that configuration, the rendered path can escape the operator's intended log directory. This is not limited to the RFC5424 HOSTNAME field. Any untrusted value that reaches a dynaFile path component can create the condition. At time of publication, there are no publicly available patches.
Rsyslog is a rocket-fast system for log processing. From versions 1.15.0 to 8.2610.0, rsyslog's omfile dynaFile facility intentionally allows templates to generate flexible output paths. This supports valid deployments that route logs into different directories or use dynamically generated file names. A deployment becomes unsafe when a dynaFile template uses a value influenced by untrusted input as a path component without explicit secure-path handling. In that configuration, the rendered path can escape the operator's intended log directory. This is not limited to the RFC5424 HOSTNAME field. Any untrusted value that reaches a dynaFile path component can create the condition. At time of publication, there are no publicly available patches.
Rsyslog is a rocket-fast system for log processing. From 7.5.4 until 8.2606.0, the optional mmpstrucdata plugin's parseSDPARAM function in plugins/mmpstrucdata/mmpstrucdata.c stores RFC5424 parameter values in a fixed pVal[32 1024] stack buffer and calls parsePARAMVALUE without supplying the destination size. A remote unauthenticated attacker whose crafted RFC5424 message reaches an action using mmpstrucdata can provide a structured-data parameter larger than that buffer when MaxMessageSize permits it, causing an attacker-controlled stack overwrite. Deployments that do not install and use the plugin, or whose effective message-size limit remains below the required threshold, are not affected by this issue. The demonstrated impact is a crash and interruption of log collection; code execution is not demonstrated. This issue is fixed in version 8.2606.0.
Rsyslog is a rocket-fast system for log processing. Modules for TCP syslog reception have a potential heap buffer overflow when octet-counted framing is used. This can result in a segfault or some other malfunction. As of our understanding, this vulnerability can not be used for remote code execution. But there may still be a slight chance for experts to do that. The bug occurs when the octet count is read. While there is a check for the maximum number of octets, digits are written to a heap buffer even when the octet count is over the maximum, This can be used to overrun the memory buffer. However, once the sequence of digits stop, no additional characters can be added to the buffer. In our opinion, this makes remote exploits impossible or at least highly complex. Octet-counted framing is one of two potential framing modes. It is relatively uncommon, but enabled by default on receivers. Modules imtcp, imptcp, imgssapi, and imhttp are used for regular syslog message reception. It is best practice not to directly expose them to the public. When this practice is followed, the risk is considerably lower. Module imdiag is a diagnostics module primarily intended for testbench runs. We do not expect it to be present on any production installation. Octet-counted framing is not very common. Usually, it needs to be specifically enabled at senders. If users do not need it, they can turn it off for the most important modules. This will mitigate the vulnerability.
A flaw was found in rsyslog's reception TCP modules. This flaw allows an attacker to craft a malicious message leading to a heap-based buffer overflow. This issue allows the attacker to corrupt or access data stored in memory, leading to a denial of service in the rsyslog or possible remote code execution.
A configuration-dependent issue in rsyslog's optional imptcp input module can allow an unauthenticated remote peer to crash rsyslogd. The issue is not active in a default installation. Exploitation requires all of the following:
imptcp is explicitly loaded. An imptcp listener uses the non-default framing.delimiter.regex mode. An attacker can establish a TCP connection to that listener.
A crafted input sequence during oversize-frame recovery can cause an invalid internal message length and terminate rsyslogd. No confidentiality or integrity impact, privilege escalation, or code execution has been identified. imtcp and the default imptcp framing modes are not affected.
A unauthenticated remote peer may lead rsyslogd to crash due to a flaw in the optional imptcp module. A crafted input sequence during oversize-frame recovery can cause an invalid internal message length and terminate rsyslogd. No confidentiality or integrity impact, privilege escalation, or code execution has been identified. imtcp and the default imptcp framing modes are not affected.
A denial of service vulnerability was found in rsyslog in the imptcp module. An attacker could send a specially crafted message to the imptcp socket, which would cause rsyslog to crash.
SQL injection vulnerability in rsyslogd in RSyslog before 1.0.1 and before 1.10.1 allows remote attackers to execute arbitrary SQL commands via crafted syslog messages.
rsyslog before 7.6.6 and 8.x before 8.4.1 and sysklogd 1.5 and earlier allows remote attackers to cause a denial of service (crash), possibly execute arbitrary code, or have other unspecified impact via a crafted priority (PRI) value that triggers an out-of-bounds array access.
A configuration-dependent issue in rsyslog's optional imptcp input module can allow an unauthenticated remote peer to crash rsyslogd. The issue is not active in a default installation. Exploitation requires all of the following:
imptcp is explicitly loaded. An imptcp listener uses the non-default framing.delimiter.regex mode. An attacker can establish a TCP connection to that listener.
A crafted input sequence during oversize-frame recovery can cause an invalid internal message length and terminate rsyslogd. No confidentiality or integrity impact, privilege escalation, or code execution has been identified. imtcp and the default imptcp framing modes are not affected.
doFuncReplace() in grammar/rainerscript.c implements replace(source, find, replaceWith) as two passes over the source string: pass 1 computes the output length, pass 2 allocates that many bytes with esnewStr() and fills them. On partial-match failure the two passes rewind by different amounts — pass 1 does i -= (j - 1), pass 2 does i -= j — so pass 1 resumes scanning at matchStart + 2 while pass 2 resumes at matchStart + 1. Every match that begins one byte after a failed partial match is therefore counted by pass 2 but not by pass 1. When replaceWith is longer than find, each such match makes the allocation short by lReplaceWith - lfind bytes, and pass 2 writes past the end of the buffer. Neither store site is bounds-checked. The source string is normally a message property ($msg, $rawmsg, …), so an unauthenticated remote syslog sender chooses the number of missed matches and thus the size of the overflow.
Double free vulnerability in the writeDataError function in the ElasticSearch plugin (omelasticsearch) in rsyslog before 7.4.2 and before 7.5.2 devel, when errorfile is set to local logging, allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted JSON response.
A memory leak in rsyslog before 5.7.6 was found in the way deamon processed log messages were logged when multiple rulesets were used and some output batches contained messages belonging to more than one ruleset. A local attacker could cause denial of the rsyslogd daemon service via a log message belonging to more than one ruleset.
A memory leak in rsyslog before 5.7.6 was found in the way deamon processed log messages are logged when $RepeatedMsgReduction was enabled. A local attacker could use this flaw to cause a denial of the rsyslogd daemon service by crashing the service via a sequence of repeated log messages sent within short periods of time.
A memory leak in rsyslog before 5.7.6 was found in the way deamon processed log messages are logged when multiple rulesets were used and some output batches contained messages belonging to more than one ruleset. A local attacker could cause denial of the rsyslogd daemon service via a log message belonging to more than one ruleset
It was reported that rsyslogd creates log files world-readable, which might lead to an information disclosure.
Description of problem:
If we send to syslog a specially crafted log message, stack guard variable protecting bufParseTAG array in parseLegacySyslogMsg() gets rewritten and rsyslog gets terminated.
Version-Release number of selected component (if applicable):
rsyslog-4.6.2-3.el61.1.i686
How reproducible:
everytime on ia-32 on x86-64 stack guard variable won't get rewritten as it is located 8 bytes above bufParseTAG array
Actual results:
glibc prints the following message and rsyslog gets terminated:
stack smashing detected : rsyslogd terminated
Expected results:
No abortion.
Additional info:
For more info, please, see the following private comment.
Integer overflow in rsyslog before 7.6.7 and 8.x before 8.4.2 and sysklogd 1.5 and earlier allows remote attackers to cause a denial of service (crash) via a large priority (PRI) value. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-3634.
imudp in rsyslog 4.x before 4.1.2, 3.21 before 3.21.9 beta, and 3.20 before 3.20.2 generates a message even when it is sent by an unauthorized sender, which allows remote attackers to cause a denial of service (disk consumption) via a large number of spurious messages.
An integer signedness error, leading to heap based buffer overflow was found in the way the imfile module of rsyslog, an enhanced system logging and kernel message trapping daemon, processed text files larger than 64 KB. When the imfile rsyslog module was enabled, a local attacker could use this flaw to cause denial of service (rsyslogd daemon hang) via specially-crafted message, to be logged.
Upstream bug report: [1] http://bugzilla.adiscon.com/showbug.cgi?id=221
Upstream patch: [2] http://git.adiscon.com/?p=rsyslog.git;a=commit;h=6bad782f154b7f838c7371bf99c13f6dc4ec4101
Hello,
We are publishing CVE-2026-55556 for a heap overflow in the optional rsyslog imhttp input module.
imhttp is a contributed rsyslog plugin. It is not part of typical default rsyslog installations, is seldom installed in production deployments, and is not frequently packaged by distributions. Systems that do not build, package, install, load, and configure imhttp are not affected.
The issue is in the HTTP Basic Authentication parser used by imhttp. Older code used:
auth->pworkbuf = calloc(0, len);
when decoding an oversized Basic Authentication header, instead of allocating len bytes. If imhttp Basic Authentication was enabled, a remote client able to reach the imhttp listener could trigger heap memory corruption. The practical expected impact is denial of service; stronger impact would depend on platform, allocator behavior, compiler options, and process hardening.
Affected configurations require all of the following:
- rsyslog built with the contributed imhttp module - imhttp installed and available - imhttp loaded and configured - HTTP Basic Authentication enabled for the affected imhttp endpoint - attacker access to that HTTP endpoint
Default rsyslog configurations do not load imhttp.
The affected upstream code path was removed in rsyslog 8.2604.0 by commit:
acde2ba25ea33816694b787859f4a727a247b6d6 imhttp: add route-scoped API key authentication
That change was primarily a feature enhancement and general imhttp auth refactor adding route-scoped API key authentication and mixed auth selection. As is now common in rsyslog development, nearby hardening was done as part of that work. In this case, the old Basic Authentication parser and its dynamic work-buffer allocation were replaced with bounded parsing, including a cap on Basic Authentication header size.
For downstreams maintaining older branches that do not take the broader auth refactor, the reporter-provided minimal targeted fix is:
diff --git a/contrib/imhttp/imhttp.c b/contrib/imhttp/imhttp.c index d0b8a18b6..c0298856c 100644 --- a/contrib/imhttp/imhttp.c +++ b/contrib/imhttp/imhttp.c @@ -702,7 +702,7 @@ static int parseauthheader(struct mgconnection conn, struct auths auth) { sizet len = aprbase64decodelen((const char )src); auth->pworkbuf = auth->workbuf; if (len > sizeof(auth->workbuf)) { - auth->pworkbuf = calloc(0, len); + auth->pworkbuf = calloc(1, len); auth->workbuflen = len; } len = aprbase64decode(auth->pworkbuf, src);
Credit: reported by 0xseiryuu, who also provided the minimal targeted fix shown above.
References:
- CVE-2026-55556 - GHSA-947w-69ph-mc2r - upstream refactor: https://github.com/rsyslog/rsyslog/commit/acde2ba25ea33816694b787859f4a727a247b6d6
Regards, Rainer