UnrealIRCd Command Injection, Exploited in the Wild (CVE-2026-114713)
A label tag escaping flaw lets an UnrealIRCd user run server commands on linked networks; fixed in 6.2.7.1 and exploited in the wild.
TL;DR
- An escaping flaw in UnrealIRCd's labeled-response module lets any ordinary user inject server-to-server commands that run with server authority. UnrealIRCd shipped 6.2.7.1 and a hot-patch on November 7, 2026.
- Every UnrealIRCd 6.0.0 to 6.2.7 server that loads the module, which the default configuration does, is exposed when the network has two or more linked servers.
- The CVE record rates it CVSS v3.1 8.6 High. CISA's Known Exploited Vulnerabilities (KEV) catalog added it on November 13, 2026, and its Stakeholder-Specific Vulnerability Categorization (SSVC) record marks exploitation active.
- Upgrade to 6.2.7.1 or run the vendor's hot-patch, then verify the module version. See "How do I fix it?" for the SPAMFILTER workaround.
Am I affected?
You are exposed when all of these hold:
- The server runs UnrealIRCd 6.0.0 through 6.2.7, or an end-of-life 5.x release.
- The
labeled-responsemodule is loaded. The defaultmodules.default.confloads it. - The network has two or more linked servers. The CVE describes command execution with server authority in that topology.
- An ordinary user can connect and send IRCv3 message tags.
A single, unlinked server does not relay the injected line to a peer, so the server-authority path in the CVE does not apply to it. Upgrade anyway: 6.2.7.1 also fixes eight other issues, including two IP address leaks.
| Branch | Affected versions | Fixed version |
|---|---|---|
| 6.x | 6.0.0 to 6.2.7 | 6.2.7.1 |
| 5.x | All releases (end of life since 2023-07-01) | None; upgrade to 6.2.7.1 |
Check the running version and the module state:
# Version of the running server
./unrealircd version
# Is the module loaded, and at which version?
./unrealircd module-status | grep labeled-response
The module line is the patch state. labeled-response 5.0 means the server is not patched. labeled-response 5.0-hot-patch-bundle-20261107 or labeled-response 6.2.7.1 means it is fixed.
How do I fix it?
Upgrade to 6.2.7.1, or apply the hot-patch without a restart, then verify the module line.
- Apply the vendor's temporary SPAMFILTER on the network. Run it as an IRCOp on every server:
SPAMFILTER add -regex T block - Invalid_label ^label=(?![^\r\n;\x20]*\z). It blocks labels that carry a carriage return, a line feed, a semicolon or a space, and it works only when every server runs 6.0.4 or later. - On each server, run
./unrealircd hot-patch bundle-20261107. The last line should say the patch was installed and the server rehashed correctly. - Or upgrade with
./unrealircd upgradeand restart. Windows users download 6.2.7.1 from the vendor site. - Verify with
./unrealircd module-status | grep labeled-response. The output must name the hot-patch bundle or 6.2.7.1. - Remove the SPAMFILTER once every server is patched.
For end-of-life 5.x, add blacklist-module "labeled-response"; to the configuration on every server and restart them, not just rehash. UnrealIRCd 5 has been end of life since 2023-07-01 and receives no fix.
The hot-patch covers all nine issues in the release. If it fails, the vendor's hot-patch FAQ lists the distro-upgrade and build cases; upgrading to 6.2.7.1 is the fallback.
What is the root cause?
The server copied the IRCv3 label message tag into a fixed buffer and later formatted it into replies without escaping the delimiters that separate tags, parameters and lines.
In UnrealIRCd 6.2.7, lr_pre_command() copies the tag value with strlcpy into currentcmd.label. The only validation is in labeled_response_mtag_is_ok(). It checks that the value is not empty, that the client supports the labeled-response and batch capabilities, and that the value is 64 bytes or shorter. It does not check the bytes inside the value.
int lr_pre_command(Client *from, MessageTag *mtags, const char *buf)
{
lr_clear();
if (IsServer(from))
return 0;
for (; mtags; mtags = mtags->next)
{
if (!strcmp(mtags->name, "label") && mtags->value)
{
strlcpy(currentcmd.label, mtags->value, sizeof(currentcmd.label));
currentcmd.client = from;
break;
}
}
return 0;
}
gen_start_batch() then writes the label into @label=%s :%s BATCH +%s labeled-response with snprintf. lr_post_command() does the same in its single-response path:
snprintf(packet, sizeof(packet) - 3,
"@label=%s%s%s",
currentcmd.label,
more_tags ? ";" : " ",
more_tags ? currentcmd.firstbuf + 1 : currentcmd.firstbuf);
In IRC, a message is a tag section, a source, a command and parameters. The delimiters work like this:
- A semicolon separates tags.
- A space ends the tag section.
- A carriage return or line feed ends the message.
A label that contains one of those bytes therefore changes the structure of the reply that UnrealIRCd builds. The label is also copied into the ACK reply through the message-tag library. That library uses the same unescaped value.
How is it exploited?
- The attacker connects to any server on the network as an ordinary user, with a client that can send IRCv3 tags.
- The attacker sends a command with a
labeltag whose value contains a tag separator, a space, or a line break. The server accepts it because the validation checks only the length and the client capabilities. - UnrealIRCd echoes the label into the
BATCHstart, theACKreply, or the single buffered response it builds for that command. - The delimiters split the generated text into extra tags, parameters or a second IRC message.
- The reply crosses a server link. The peer parses the extra message as a server-to-server command from a trusted link, so it runs with server authority.
No public exploit code is needed to explain the bug, and none is linked here. The vendor says any ordinary user can KILL, GLINE and do many other bad things. The CISA record marks exploitation active, so the technique is in use.
How does the attack flow?
An ordinary user puts tag and line delimiters inside a label. UnrealIRCd copies the label into a reply without escaping it, and the peer server runs the injected command as a trusted server.
with a crafted label tag"] --> B["Module copies the label
with no delimiter check"] B --> C["Reply is built as
@label=<value> ..."] C --> D["Delimiters split the reply
into extra tags or a second line"] D --> E["Reply crosses a server link"] E --> F["Peer runs the injected line
with server authority"] F --> G["KILL, GLINE and other
server commands execute"]
What can an attacker do?
An ordinary user can run commands that only a server or an IRCOp should run, including KILL and GLINE against other users and channels.
The impact needs all of these conditions:
- The server runs an affected version and loads
labeled-response. - The network has two or more linked servers, so the injected line is parsed by a peer as a server command.
- The attacker can connect as an ordinary user. No account on the server and no operator status is needed.
- The attacker can send IRCv3 tags. A raw socket or a scripted client is enough.
The vendor describes the issue as the most critical in UnrealIRCd in 15 years. The CISA SSVC record lists technical impact total and automatable yes. The CVE record rates integrity impact only (C:N/I:H/A:N); availability and confidentiality impact depend on the commands the attacker runs.
Why does the fix work?
The fix rejects any label that contains a space, a semicolon, a backslash, a carriage return or a line feed. The value can no longer change the structure of the reply.
The fix commit 05b5f5fdc8bb adds one check to labeled_response_mtag_is_ok():
int labeled_response_mtag_is_ok(Client *client, const char *name, const char *value)
{
if (BadPtr(value))
return 0;
+ if (strpbrk(value, " ;\\\r\n"))
+ return 0;
+
if (IsServer(client))
return 1;
The check runs before the server branch, so it also applies to tags that arrive from a linked server. Every reply path that uses currentcmd.label now receives a value with no tag separator, parameter separator or line break. That covers the batch start, the ACK reply and the single-response buffer.
The vendor shipped the same change in 6.2.7.1 and in the hot-patch bundle. The patch is complete for this CVE; the other eight issues in the release are separate changes.
How do I check if I was compromised?
No indicators of compromise have been published. CISA marks exploitation active, but neither the vendor nor CISA has published request patterns, victim counts or log signatures for this CVE.
Check the patch state first, because an unpatched server is the exposure:
./unrealircd module-status | grep labeled-response
./unrealircd version
Then review the server logs for the effects the vendor names:
- KILL, GLINE, SVS* and other server commands that were not issued by an IRCOp or a known server link.
- Server-link disconnects or protocol errors around the same time.
- Configuration or ban-list changes that no operator made.
UnrealIRCd logs vary by build and log level, and a blocked attempt may leave no trace. The SPAMFILTER logs matches when it blocks a label; search for its block message if the filter was enabled.
Timeline
- 2026-11-04: The fix commit
05b5f5fdc8bbis authored. - 2026-11-07: UnrealIRCd releases 6.2.7.1 and the
bundle-20261107hot-patch at 15:00 UTC. - 2026-11-08: The CVE record is published, and the vendor posts the advisory to the oss-security mailing list.
- 2026-11-12: CISA's SSVC record marks exploitation active.
- 2026-11-13: CISA adds CVE-2026-114713 to the KEV catalog, with a due date of 2026-11-16.
FAQ
Is CVE-2026-114713 exploited in the wild?
Yes. CISA added it to the KEV catalog on November 13, 2026, and its SSVC record marks exploitation active as of November 12. The vendor's advisory describes the impact but does not name a campaign or a victim.
Does the SPAMFILTER workaround fully fix the issue?
No. It blocks the critical label injection only when every server on the network runs 6.0.4 or later. It does not fix the other eight issues in 6.2.7.1, and it is a temporary filter, not a patch.
I run UnrealIRCd 5. What do I do?
UnrealIRCd 5 is end of life since 2023-07-01 and is affected by the critical issue. Add blacklist-module "labeled-response"; to every server and restart, then move to 6.2.7.1. The vendor says other end-of-life versions were not checked and are likely affected too.
Is a single server exposed?
The CVE describes command execution with server authority on a network with two or more linked servers. A single, unlinked server does not relay the injected line to a peer, so that path does not apply. Upgrade anyway, because 6.2.7.1 fixes eight other issues.
How do I verify the hot-patch?
Run ./unrealircd module-status | grep labeled-response. The line must read labeled-response 5.0-hot-patch-bundle-20261107 or labeled-response 6.2.7.1. A bare labeled-response 5.0 means the patch is not installed.
References
- CVE-2026-114713 record, MITRE CNA, published 2026-11-08, CVSS v3.1 8.6, CWE-140 and the CISA ADP SSVC block: https://www.cve.org/CVERecord?id=CVE-2026-114713 (checked November 14, 2026)
- UnrealIRCd, "UnrealIRCd 6.2.7.1 released and hot-patch to fix 9 security issues", November 7, 2026, the vendor advisory text and the full issue list: https://www.openwall.com/lists/oss-security/2026/11/08/1 (checked November 14, 2026)
- UnrealIRCd news index, the release date, the 38 percent market share and the hot-patch instructions: https://www.unrealircd.org/index/news (checked November 14, 2026)
- Fix commit
05b5f5fdc8bb, "Fix CRITICAL issue where anyone could execute commands as server/IRCOp", November 4, 2026: https://github.com/unrealircd/unrealircd/commit/05b5f5fdc8bb (checked November 14, 2026) - UnrealIRCd 6.2.7 source, the unvalidated label copy at
src/modules/labeled-response.cand the reply builders: https://github.com/unrealircd/unrealircd/blob/59546a20f6c9b0dae1646727acf74b4b744e9b09/src/modules/labeled-response.c (checked November 14, 2026) - UnrealIRCd default module list,
labeled-responseloaded by default: https://github.com/unrealircd/unrealircd/blob/unreal60_dev/doc/conf/modules.default.conf (checked November 14, 2026) - CISA Known Exploited Vulnerabilities catalog, CVE-2026-114713 added 2026-11-13 with a due date of 2026-11-16: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (checked November 14, 2026)