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.
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
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.
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,
This is the public follow-up to the earlier embargoed notification to the distros list. The embargo ended on 2026-08-24. We apologize for the delayed oss-security posting.
rsyslog contains a heap buffer overflow in the core RainerScript replace() function. The three-argument form of wrap() uses the same implementation and is also affected.
The issue is not active in the default configuration. A deployment is exposed only when a ruleset applies replace(), or the three-argument form of wrap(), to sender-controlled or otherwise untrusted data.
Technical details =================
replace() calculates the required output-buffer size and constructs the output in two separate passes. Following certain failed partial matches, the two passes resumed scanning at different source positions. The construction pass could consequently write more data than the sizing pass had allocated.
Triggering the issue requires:
A ruleset that calls replace() or three-argument wrap(). Sender-controlled or otherwise untrusted source data. A search string containing at least two characters. A replacement string longer than the search string. Input containing the partial-match pattern that causes the sizing and construction passes to diverge.
Impact ======
A remote sender able to submit messages to an affected ruleset can trigger heap corruption and termination of rsyslogd, interrupting log processing. No authentication is required when the configured network input accepts unauthenticated senders.
The heap-buffer overflow and daemon termination were reproduced with AddressSanitizer. Confidentiality loss, integrity loss, and code execution have not been demonstrated.
Affected versions =================
The vulnerable implementation was introduced in rsyslog 8.6.0.
Affected scheduled releases:
rsyslog 8.6.0 through 8.2608.0
Affected daily stable builds:
Builds published before the fixed 2026-08-24 daily stable build
Fixed versions ==============
The fix is available in the rsyslog daily stable build dated 2026-08-24 and later daily stable builds. It will also be included in the scheduled rsyslog 8.2610.0 release.
Users of affected configurations should update to a fixed daily stable build rather than wait for the scheduled release.
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 score reflects the demonstrated, repeatable, network-triggered availability impact. Practical exposure is limited to deployments whose rulesets explicitly apply the affected function to untrusted data.
Weakness classifications:
CWE-122: Heap-based Buffer Overflow CWE-131: Incorrect Calculation of Buffer Size
Mitigations ===========
Until an update can be installed, operators can prevent exploitation by:
Not applying replace() or three-argument wrap() to untrusted message content. Ensuring that the replacement string is not longer than the search string. Restricting affected network inputs to trusted senders.
These mitigations should not replace installing a fixed package.
Fix ===
The sizing pass now uses the same rewind behavior as the output-construction pass, so both passes identify the same replacement positions and calculate a matching output length.
Minimal patch:
--- a/grammar/rainerscript.c +++ b/grammar/rainerscript.c @@ -1827,8 +1827,8 @@ static esstrt doFuncReplace(struct svar restrict const operandVal, if (srcbuff[i] == find[j]) { j++; } else if (j > 0) { - i -= (j - 1); - lDst -= (j - 1); + i -= j; + lDst -= j; j = 0; } }
References ==========
GitHub Security Advisory: https://github.com/rsyslog/rsyslog/security/advisories/GHSA-g72f-gc6v-f2w3
Fix: https://github.com/rsyslog/rsyslog/commit/667e3f61aec5ee02c5c2ee6f0f8accf6fe4301a9
Pull request and regression test: https://github.com/rsyslog/rsyslog/pull/7525
rsyslog downloads and package repositories: https://www.rsyslog.com/downloads/
Identifier:
CVE-2026-78002
Credit ======
The issue was found by Anthropic using Claude to study the security of open-source software and manually validated by Ada Logics. It was reported by David Korczynski.
Regards, Rainer Gerhards rsyslog project