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.

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 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.

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

Hello,

A CVE identifier, CVE-2026-61548, has been assigned to a stack-based buffer overflow in rsyslog's optional mmpstrucdata module.

GitHub advisory:

GHSA-8qmr-c66f-g368

Affected versions:

rsyslog 7.5.4 and later, before 8.2606.0

Fixed version:

rsyslog 8.2606.0

Severity:

High, CVSS 3.1 score 8.1

Weakness:

CWE-121: Stack-based Buffer Overflow

Technical details -----------------

The issue occurs while mmpstrucdata parses RFC 5424 structured-data parameter values.

In affected versions, parseSDPARAM() allocates a fixed 32,768-byte stack buffer:

uchar pVal[32 1024];

It then passes this buffer to parsePARAMVALUE() without providing its size.

parsePARAMVALUE() writes the parameter value into the buffer without checking the destination size. Its loop is bounded only by the length of the structured-data input.

If rsyslog accepts a structured-data parameter value larger than the fixed buffer, attacker-controlled data can overwrite the stack.

Affected configurations -----------------------

A deployment is affected only when all of the following conditions are met:

- the optional mmpstrucdata plugin is installed;

- the plugin is explicitly loaded and used in the rsyslog configuration;

- attacker-controlled RFC 5424 structured data reaches the mmpstrucdata action; and

- the effective MaxMessageSize setting permits a structured-data parameter value exceeding the historical 32 KiB buffer.

Default configurations that do not load and use mmpstrucdata, or whose effective message-size limit is below the required threshold, are not affected by this specific issue.

Downstream packaging differs between distributions. The module may be included in the main rsyslog package, provided as a separate package, or not shipped at all.

Users and distributions should therefore verify both the presence of the module and whether it is used by the active configuration.

Raising MaxMessageSize above the upstream default is used in some larger log-processing deployments and should not be treated as a purely theoretical configuration.

Impact ------

A remote, unauthenticated attacker who can send crafted RFC 5424 messages through an input path processed by mmpstrucdata can crash the rsyslog process.

This can cause denial of service and interruption of log collection.

The demonstrated impact is a process crash.

Because this is a stack overwrite containing attacker-controlled data, code execution may be possible on some platforms or builds, depending on compiler, libc, and runtime hardening.

The rsyslog project has not demonstrated code execution on standard hardened glibc-based distribution builds.

The reporter reproduced the crash on Debian 12 with rsyslog 8.2302.0 over both TCP and UDP.

The test configuration used:

global(maxMessageSize="40000")

with mmpstrucdata loaded and an action invoking the module.

Fix ---

The vulnerable code path is no longer present in upstream main.

After the vulnerability was reported, PR #6991 was merged as part of broader mmpstrucdata cleanup and refactoring.

That refactoring removed the fixed-size structured-data parameter buffer and therefore also removed the vulnerability.

The PR was merged publicly before coordination of the private advisory had been completed. This was a process error on our side.

As a consequence, the security-relevant code change became public earlier than intended.

The public PR did not disclose the vulnerability details, proof of concept, CVSS analysis, or exploitability assessment.

Nevertheless, it contained the effective correction and was therefore regarded by some distributions as an already public fix.

For stable downstream versions, taking the complete refactoring is not required.

The recommended minimal backport is to replace the fixed stack buffer with a dynamically allocated buffer sized according to the already validated structured-data length, including space for the terminating NUL byte.

Conceptually, the relevant change is:

uchar pVal = malloc((sizet)lenbuf + 1); if (pVal == NULL) { iRet = RSRETOUTOFMEMORY; goto finalizeit; }

CHKiRet(parsePARAMVALUE(sdbuf, lenbuf, &i, pVal));

...

finalizeit: free(pVal);

The first upstream release containing the fix is rsyslog 8.2606.0.

Workarounds -----------

Users unable to update immediately can reduce exposure by:

- not loading or using mmpstrucdata unless it is required;

- restricting network inputs whose messages reach an mmpstrucdata action; or

- keeping MaxMessageSize below the threshold required for an oversized structured-data parameter value, where operationally possible.

These mitigations may not be suitable for deployments that require both mmpstrucdata and large RFC 5424 messages.

Credits -------

The vulnerability was reported by Mike Cole, GitHub user mikecole-mg.

Regards, Rainer Gerhards rsyslog project

Last updated 20 July 2026

Hello,

The rsyslog project has published a security advisory and proposed upstream fix for a configuration-dependent denial-of-service issue in the optional imptcp input module.

Summary =======

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.

Affected versions =================

The vulnerable regex-framing implementation was introduced in rsyslog v8.36.0. Scheduled stable releases from v8.36.0 through v8.2606.0 are affected, as are daily stable builds published before 2026-07-23 CEST.

Severity ========

CVSS v3.1: 7.5 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

The practical exposure is limited because both imptcp and regex framing are optional and not enabled by default.

Mitigations ===========

Until updating, users can disable the affected imptcp listener, remove its framing.delimiter.regex setting, restrict network access to the listener, or replace the listener with an equivalent imtcp listener.

Fix and advisory ================

The proposed upstream fix is public and available for review:

https://github.com/rsyslog/rsyslog/pull/7410

A fixed daily stable package will be published through the normal daily stable workflow on 2026-07-23 CEST. The next scheduled stable release, v8.2608.0, will include the same fix.

The GitHub Security Advisory is available at:

https://github.com/rsyslog/rsyslog/security/advisories/GHSA-cj5r-wh2m-7w29

A CVE has been requested through GitHub and is pending. Current CVE status is tracked in the GitHub Security Advisory.

Credit ======

Thanks to Raphael Eikenberg, independent security researcher, for reporting the issue.

AI assistance disclosure ========================

The reporter stated that he used AI tools to help identify the issue and draft the reproducer and report. He personally built the reported rsyslog revision, reproduced the daemon termination in all six test runs, and confirmed that the daemon remained operational after applying the proposed guard.

The maintainer-side minimal patch and regression-test changes were prepared with OpenAI Codex assistance and subsequently reviewed and validated through the rsyslog testbench, static analysis, PR-ready container validation, and focused ASan/UBSan testing.

Independent maintainer review and patch verification were the final acceptance gate. The patch was accepted based on that verification, not on the AI output alone.

Regards, Rainer Gerhards rsyslog project

Patch =====

diff --git a/plugins/imptcp/imptcp.c b/plugins/imptcp/imptcp.c index 838e1648f..90a7d6f7e 100644 --- a/plugins/imptcp/imptcp.c +++ b/plugins/imptcp/imptcp.c @@ -1053,7 +1053,7 @@ static rsRetVal ATTRNONNULL() processDataRcvdregexFraming(ptcpsesst const pThis->iCurrLine = pThis->iMsg; } else { const int isMatch = !regexec(&inst->startpreg, (char )pThis->pMsg + pThis->iCurrLine, 0, NULL, 0); - if (isMatch) { + if (pThis->iCurrLine > 0 && isMatch) { DBGPRINTF("regex match (%d), framing line: %s\n", pThis->iCurrLine, pThis->pMsg); memmove(pThis->pMsgsave, pThis->pMsg + pThis->iCurrLine, ustrlen(pThis->pMsg + pThis->iCurrLine) + 1); pThis->iMsg = pThis->iCurrLine - 1;

Hello,

rsyslog has published GHSA-xmp9-244p-5ggv covering hardening of dynamic filename handling in the omfile output module:

https://github.com/rsyslog/rsyslog/security/advisories/GHSA-xmp9-244p-5ggv

The affected area is omfile configurations that use dynaFile. Dynamic filenames are intentionally flexible: some established deployments need that flexibility, including paths that cannot be restricted to one static base directory. Consequently, preserving this mode is important for compatibility.

Historically, configurations using this flexible behavior did not provide a clear warning about the associated path-containment risk. The secure configuration mechanisms have always been documented as the recommended way to constrain dynamic output paths, but the legacy behavior remained the default to avoid silently breaking existing logging configurations.

The current hardening adds default lexical containment where a static base path can be determined, together with diagnostics and an explicit, per-action compatibility opt-in for configurations that intentionally require path escape. This provides an additional containment layer for users who need dynaFile flexibility; it is not presented as a complete filesystem sandbox.

For deployments where untrusted data can influence dynamic filename expansion, the recommended mitigation is to use the documented secure path options, including securepath and the secpath-drop or secpath-replace policies. These options are the reliable security boundary and should be applied by affected users. Building a universally complete sandbox around all legacy dynamic-path semantics would be difficult to do reliably and would risk breaking legitimate existing configurations.

The advisory intentionally avoids unnecessary reproduction details. The attached patch is provided for downstream maintainers.

Regards, Rainer Gerhards rsyslog project