UnrealIRCd Bug Tracker - Issues

0006144: Make zline, gline, kline, shun create an ID.

Fri, 06 Mar 2026 08:26:29 +0100

Will be nice if this can be done directly from the IRCD and not only with operserv.
/gline *@etc - whatever reason -> this part be automatic ID: XZ9YCRP1E8.

Will make my life easier.

thanks.

0006612: Implement extbans support in the SILENCE list

Sat, 14 Feb 2026 20:05:16 +0100

The feature request is to extend the SILENCE list to supporting extbans as well, in the same fashion as the channel b/E/I lists. Currently the SILENCE list only supports the format nick!user@host.

It could be convenient for the user to be able to use extbans in the SILENCE list also, such as: ~account, ~asn, ~country, ~realname, ~security-group, ~certfp and ~text. Maybe ~time also in case it is possible to manage temporary items in the SILENCE list.
The other extbans might not be relevant for the SILENCE list.

This would also opens the possibility of remotely managing the SILENCE list through the services and the use of SVSSILENCE.

Once implemented the usage could be similar (and a bit different due to the SILENCE syntax) to the channels: SILENCE +~realname:qwerty, SILENCE -~account:some-account

SILENCE list could look like:
-> server. SILENCE
<- :server. 271 Nick *!user4@host4
<- :server. 271 Nick nick3!*@*
<- :server. 271 Nick nick2!user2@host2
<- :server. 271 Nick ~asn:65536
<- :server. 271 Nick ~security-group:some-insecure-group
<- :server. 271 Nick ~text:a_spammy_spam
<- :server. 272 Nick :End of Silence List

0006611: RPC_CALL_ERROR - Every refresh i have a error to logs.

Sat, 07 Feb 2026 11:49:07 +0100

Hello all,

i have a error with panel, when i click to Servers or any button i see a error to logs.

timestamp:"2026-02-07T10:43:20.404Z"
level:"info"
subsystem:"rpc"
event_id:"RPC_CALL_ERROR"
log_source:"chati.shprehu.net"
msg:"[rpc] Client RPC:adminpanel: RPC call server.module_list"
client:Object
name:"RPC:adminpanel"
id:"2424A7VUA"
hostname:"127.0.0.1"
ip:"127.0.0.1"
details:"RPC:adminpanel@127.0.0.1"
server_port:8600
client_port:42972
connected_since:"2026-02-07T10:43:19.000Z"
idle_since:"2026-02-07T10:43:19.000Z"
method:"server.module_list"

0006610: Move "make pem" to its own "./unrealircd" subcommand

Sun, 01 Feb 2026 19:38:02 +0100

Currently if we want to generate a new certificate/key, we nee to run the "make pem" command.

While I expected the "make install" command to replace the older certificate/key, it doesn't, which is by design to avoid some rare issues, like replacing certs on test instances, debugging, etc.

After discussing it on IRC, it was decided that it should be better to move it to its own "./unrealircd" subcommand and get rid of the "make pem", while being able to generate them from "./Config" on initial setup.

The command can probably be called "./unrealircd makecert" and throw a warning to the user, like: "This command will replace your existing server certificate and key. Do you wish to proceed? [Y|N]"

0005849: WHOISASN like on Inspircd - Very useful

Fri, 30 Jan 2026 16:27:46 +0100

Would it be possible to add ASN to whois in the future?
It would be very useful to me

On Inspircd it looks like this:

if (asn)
whois.SendLine(RPL_WHOISASN, asn, "is connecting from AS" + ConvToStr(asn));
else
whois.SendLine(RPL_WHOISASN, "*", "is connecting from an unknown autonomous system");

https://github.com/inspircd/inspircd-contrib/blob/master/3.0/m_asn.cpp

Where is it possible to build in module like showwebirc.c with whoisasn ?

0005278: Add extban to ban users banned in another channel

Fri, 30 Jan 2026 16:00:24 +0100

We currently have the extban to ban users that are in a channel, with "+b ~c:#channelname".

Would be nice if we could have an extban to ban users banned in another channel (so we can keep some kind of banlist sync across channels registered by the same person.

I was thinking in something like "+b ~b:#channelname" or "+b ~C:#channelname".

The latter goes in hand with the extban "~c" as they're kinda related.

Thoughts?

0006607: Documentation update

Fri, 30 Jan 2026 07:53:21 +0100

Hello team,

in the documentation of the connthrottle.set, you've said that we should use action = on in the parameter.
while it works well when you provide : enabled : true or false

0006608: connthrottle.set not working

Fri, 30 Jan 2026 07:41:17 +0100

Hello,
when you set the connthrottle to false and you call the status endpoint are we expecting to have the enabled field to false ?

0006578: Failed unrealircd module install exits with code 0

Fri, 23 Jan 2026 13:16:52 +0100

The exit code of "./unrealircd module install" is 0 (Success) even if the command has failed

0006602: Invalid channel user limits are normalized to 1

Fri, 23 Jan 2026 08:46:32 +0100

When sending "MODE #chan l :abc" or "MODE #chan l :-1", Unreal converts it to "MODE #chan l :1": https://github.com/unrealircd/unrealircd/blob/1c461db46de2b0d7d0c5b0b1f4e71439170f87e0/src/modules/chanmodes/limit.c#L191-L199

This is inconsistent with other IRCds: Charybdis/Solanum, Ergo, Hybrid/Plexus4, irc2, ircu2/Nefarious ignore the MODE command entirely, while InspIRCd and ngIRCd send ERR_INVALIDMODEPARAM then ignore it too.

0006579: usermodes/privdeaf

Fri, 23 Jan 2026 08:28:07 +0100

It seems logical that usermodes/privdeaf should ignore TAGMSG otherwise users receive the "User does not accept private messages" notice multiple times before they've even sent the message that should trigger it.

0006606: Regression: services kill users who use post-registration SASL

Fri, 23 Jan 2026 07:48:55 +0100

1. User "bar" connects (without authenticating), gets RPL_WELCOME, MOTD, etc.
2. User "bar" SASLs, gets back "My.Little.Server 903 bar :SASL authentication successful"
3. User "bar" gets RPL_WELCOME and MOTD **again**
4. User "bar" gets killed: :My.Little.Services KILL bar :My.Little.Services (Ghost detected via nick collision (new))

This happens with both Atheme and Anope, since https://github.com/unrealircd/unrealircd/commit/0cf0c0faa27ccfc4308834cb98ae92dcc0c31b64

0006591: OOM kill because of low memory during installation

Mon, 19 Jan 2026 10:33:38 +0100

Upgrade fails at this stage:

CC src/libpcre2_8_la-pcre2_match.lo
gcc: internal compiler error: Killed (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-6/README.Bugs> for instructions.
Makefile:2721: recipe for target 'src/libpcre2_8_la-pcre2_match.lo' failed
make[1]: *** [src/libpcre2_8_la-pcre2_match.lo] Error 1
make[1]: Leaving directory '/home/test/unrealircd-6/extras/pcre2-10.45'
Makefile:1581: recipe for target 'all' failed
make: *** [all] Error 2

dmesg tells me it's because of low memory:

and I have this error in dmesg: Out of memory in UB 1905: OOM killed process 32385 (cc1) score 0 vm:173224kB, rss:128360kB, swap:0kB

0006604: ~msgbypass:censor does not work on ~text:censor bans

Thu, 15 Jan 2026 08:21:43 +0100

A ~msgbypass:censor exemption does not work on ~text:censor bans, as it may be expected.

0006603: Granular command control for SHUN (Stealth/Shadow-Shun support)

Sun, 11 Jan 2026 18:34:42 +0100

Hi,

I’m reaching out to request an enhancement to the current SHUN implementation. After some discussion in #unreal-support and comparing notes with other IRCds, it seems that UnrealIRCd is currently missing a critical tactical feature for modern network moderation: Shadow "Shunning".
The Problem: "The Ban-Evader Feedback Loop" - Currently, an UnrealIRCd shun is very "loud." If a shunned user tries to JOIN a channel, the command is blocked.

For persistent ban-jumpers and trolls, this is an immediate signal that their current identity (IP/Fingerprint) is burned. Their reaction is predictable:

- They notice they can't join.
- They immediately disconnect.
- They change their IP (VPN/Proxy/Tor) and return within seconds.
- The current system essentially "trains" the abuser to rotate their IP faster.

The most effective way to handle these users is to let them think their connection is working, while silently neutralizing their impact. We want them to JOIN channels successfully (so they stay on their current IP) and PART/QUIT normally and type messages that are silently dropped (the "void").

As long as the user believes they are still "in," they won't switch their IP. This keeps them contained and makes the moderator's life much easier.
This isn't a new concept; InspIRCd has had this solved for years via their shun module configuration. They use an enabledcommands directive:

enabledcommands="ADMIN OPER PING PONG QUIT JOIN PART"
notifyuser="no"

This allows admins to decide exactly how "invisible" the shun should be.

It would be ideal to have a similar granular control in the set block or a specific shun block:

set {
options {
shun-allowed-commands { "JOIN"; "PART"; "QUIT"; "PING"; "PONG"; };
shun-notify-user no;
}
}

Addressing Concerns (because it was mentioned on #unreal): During the discussion, it was mentioned that allowing JOIN could lead to join-flooding. However, UnrealIRCd already has excellent anti-flood and rate-limiting modules. Join-flooding should be (and already is) handled by those layers, rather than being a hardcoded side-effect of a shun. And, of course, backward Compatibility: The default could remain as it is now, so no existing setups break.

By making shuns configurable, we gain a powerful psychological tool against trolls. Instead of a "Hard Wall" that triggers an IP-switch, we get a "Silent Void" that keeps the abuser busy and localized.

0006572: Ability to cloak a host/IP via oper command and/or external API/tool

Mon, 05 Jan 2026 21:34:24 +0100

I would like to request a feature in UnrealIRCd that allows opers (or a utility script/tool) to generate a cloaked hostname from a given IP address or hostname, without the user being connected. This would use the same cloaking algorithm and network-specific keys currently used by the IRCd.

Why this is useful?
In some scenarios, services or bots only have access to a user’s real IP/host (for example, web-based things, forms, or external integrations). For privacy reasons, we don’t want to expose raw IPs/hosts to channel operators or users..
Instead, it would be extremely useful to convert that IP/host into the cloaked hostname UnrealIRCd would generate on the network.

This allows channel staff to:

Apply bans using cloaked hosts instead of exposing raw IPs.
Correlate external actions (like web actions) with connected users on IRC in a privacy-preserving way.
Keep consistency: bans or matching rules would work the same way as if they were set against cloaked hosts in the IRC session.
Many other use cases where external tools have a real host/IP and the chat has "another version"

Requested implementation ideas:

- An oper-only command such as: /GETCLOAK which outputs the cloaked hostname as Unreal would display it.
- An external API/utility/library function (maybe in PHP, C, or via JSON-RPC to the IRCd) that can be used by services/web interfaces. This way, developers can generate cloaks on demand without duplicating Unreal’s internal cloaking code.

Having this functionality externalized (e.g., bash via unrealircd cloak ) would also make sense.

Ofcourse, the exact cloaking algorithm and keys in use by the network should be applied, so the result matches what IRC clients see.

0006511: accidental permanent gline even though default-bantime is 7d

Wed, 17 Dec 2025 17:30:56 +0100

I noticed that a colleague from IRCop sometimes bans users with the following command:
/gline *@2a02:1808:* Dehors !
but forgets to add the ":" before the reason. As a result, the ban duration is set to 'permanent.' He doesn’t correct it. Is there a way to block this, prevent the permanent bans, or make the permanent ban expire after 7 days? Or perhaps in UnrealIRCd, is there a place where I can change the default '0' or 'permanent' to something like '7d' ?

0006598: First message of a labeled-response BATCH ends with \r\r\n instead of \r\n

Sun, 07 Dec 2025 08:54:51 +0100

Hi,
It appears that the first message of a labeled-response BATCH ends with 2 carriage returns instead of 1.
Here are some examples taken from the server, with \r shown explicitly.

```
@label=4 :irc4.unrealircd.org BATCH +nrysFdQ9a22iJNd0Yz7Wz4 labeled-response\r
@batch=nrysFdQ9a22iJNd0Yz7Wz4 :irc4.unrealircd.org BATCH +9wfdGGp2wQJMuf1ng5nQMM draft/chathistory-targets\r\r
@batch=nrysFdQ9a22iJNd0Yz7Wz4 :irc4.unrealircd.org BATCH -9wfdGGp2wQJMuf1ng5nQMM\r
:irc4.unrealircd.org BATCH -nrysFdQ9a22iJNd0Yz7Wz4\r
@label=5 :irc4.unrealircd.org BATCH +DeeYaIrhp7OBSxiWm1XTj2 labeled-response\r
@batch=DeeYaIrhp7OBSxiWm1XTj2;msgid=EN36ZrCZLBLjdzDHawFdAq-BiS7YM4lYJ3lH3Hk9v/W/w;time=2025-12-04T11:54:00.703Z :skibixonx!~skibixonx@Clk-A8912720.ipv6.abo.wanadoo.fr JOIN :#fooxx\r\r
@batch=DeeYaIrhp7OBSxiWm1XTj2;msgid=EN36ZrCZLBLjdzDHawFdAq-ntNfEbBj/+TzhiL4f5IWbA;time=2025-12-04T11:54:00.703Z :irc4.unrealircd.org MODE #fooxx +nt \r
@batch=DeeYaIrhp7OBSxiWm1XTj2 :irc4.unrealircd.org 353 skibixonx = #fooxx :@skibixonx\r
@batch=DeeYaIrhp7OBSxiWm1XTj2 :irc4.unrealircd.org 366 skibixonx #fooxx :End of /NAMES list.\r
:irc4.unrealircd.org BATCH -DeeYaIrhp7OBSxiWm1XTj2\r
@label=6 :irc4.unrealircd.org BATCH +fUGxsVL7HMEswEfLcsNiee labeled-response\r
@batch=fUGxsVL7HMEswEfLcsNiee :irc4.unrealircd.org 354 skibixonx ~skibixonx Clk-A8912720.ipv6.abo.wanadoo.fr skibixonx Hs@\r\r
@batch=fUGxsVL7HMEswEfLcsNiee :irc4.unrealircd.org 315 skibixonx #fooxx :End of /WHO list.\r
:irc4.unrealircd.org BATCH -fUGxsVL7HMEswEfLcsNiee\r
@label=7 :irc4.unrealircd.org BATCH +wGxT7Ndt10FRrmYbJAYf3I labeled-response\r
@batch=wGxT7Ndt10FRrmYbJAYf3I :irc4.unrealircd.org BATCH +gvIymYLCYrqRyezi6plJij chathistory #fooxx\r\r
@batch=wGxT7Ndt10FRrmYbJAYf3I :irc4.unrealircd.org BATCH -gvIymYLCYrqRyezi6plJij\r
:irc4.unrealircd.org BATCH -wGxT7Ndt10FRrmYbJAYf3I\r
```

You can see the \r\r at the end of those messages. In the examples this happened both on inner chathistory batches, and on a plain WHO response.

0006227: JSON-RPC : sent a message to a bot to give it an order

Fri, 28 Nov 2025 18:00:10 +0100

Hi
https://www.unrealircd.org/docs/JSON-RPC:Technical_documentation#JSON-RPC_Methods
Would it be possible to send a message to a bot via the JSON-RPC API?

Here is a useful example:
1) For example, a user sends a PHP request (SQL & INSERT) as a service to report abuse
2) Me (or us admins) deal with abuse (on a PHP page)
3) But now I would like when the INSERT is done (from step 1) as soon as the insert is successful this php page would send a PRIVMSG to a NodeJS robot such as: PRIVMSG Sysop ABUS from: for: id:
The robot would then send a private message in real time to the specific ircops an alert in private message telling them that an abuse has just been posted between FROM and TO and with the url containing the id directly and here is the request for abuse would be dealt with directly.

You have to be honest but I don't receive any notification there currently and I don't immediately think of going to the php page to moderate abuse. If only there was something that alerts in real time like api-rpc that would be great.

There are only about 7 to 10 abuse requests per day (the abuse button is very discreet so that it is only used by people who have a good level of intelligence so as not to be inundated.

If this command cannot be created on json-rpc There would be another quick trick to implement, here is an example:
1) Create a sql table named: "irc_commands_to_execute" and I put 2 columns id|cmd
2) The nodejs robot (ircop) it recovers via a select and once a minute everything that is there in this sql table and it directly sends the command received
3) and in php I just put the message hard in sql, example: privmsg Sysop ABUS from: for: id:
or directly the processing of the "ABUS" command to send the message directly to the ircops concerned with the url.

Salutations

0006406: RPL_LISTSTART terminated with crcrlf

Thu, 20 Nov 2025 11:29:24 +0100

After sending a LIST command the server responds with a RPL_LISTSTART message that is terminated with an extra carriage return (i.e. crcrlf instead of crlf). The rest of the messages sent by the server (the ones with the important data) are terminated with the expected crlf.

0006592: IRCD warning about the wrong TLS cert expiring, despite what is configured in use

Sat, 15 Nov 2025 17:43:24 +0100

Since upgrading my servers to 6.2.1, they have been warning at startup and on occasion that the configured cert has expired years ago, when it has not.

The occasional warning, from my weechat server buffer:

11:48:17 -- [hostname]: tls.TLS_CERT_EXPIRING [warn] Warning: TLS certificate '/etc/unrealircd/fullchain.pem': certificate expired 492d2h54m19s ago

Ditto if I unrealircdctl rehash:

[warn] Warning: TLS certificate '/etc/unrealircd/fullchain.pem': certificate expired 492d3h9m19s ago

When I connect to said server, the client connection is fine:

14:56:19 -- gnutls: receiving 2 certificates
14:56:19 -- - certificate[1] info:
14:56:19 -- - subject `CN=*.[domainname]', blah blah blah, activated `2025-11-11 18:10:19 UTC', expires `2026-02-09 18:10:18 UTC'
14:56:19 -- - certificate[2] info:
...

And if I check the cert directly:

bss@[hostname] ~ % sudo openssl x509 -enddate -noout -in /etc/unrealircd/fullchain.pem
notAfter=Feb 9 18:10:18 2026 GMT

But while checking, I realized I had the default certs as cruft in my config directory, and what do you know:

bss@[hostname] ~ % sudo openssl x509 -enddate -noout -in /etc/unrealircd/tls/server.cert.pem
notAfter=Jul 10 14:53:58 2024 GMT

bss@[hostname] ~ % python
Python 3.13.5 (main, Sep 21 2025, 23:32:29) [GCC 14.3.1 20250801] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.now() - datetime.timedelta(days=492)
datetime.datetime(2024, 7, 10, 12, 15, 59, 263964)
>>>

bss@[hostname] ~ % sudo grep server.cert.pem /etc/unrealircd/unrealircd.conf
bss@[hostname] ~ %

Replacing server.cert.{pem,key} with symlinks to the files in /etc/unrealircd/ removed the error. It seems as if the expiry checker was picking up the "default" files somehow, which leads me to my next question --- at first I just nuked the server.cert.{pem,key} files in the directory, but then rehash complained that the default certificate was missing. Did I miss a step somewhere, or is there no way to point the config away from those files?

0006575: Feature Request: WebHooks

Wed, 12 Nov 2025 11:58:52 +0100

It would be really useful to have webhooks in UnrealIRCd. Right now SSE is the only option, but that means keeping a persistent connection open all the time. For some use cases that's fine, but requires user attendance for the app to receive, or some other persistent connection solution. Webhooks are a feasible workaround, and will be useful for future development of the webpanel.

0006590: security group rules priority

Sat, 08 Nov 2025 15:17:18 +0100

when you're in more than one security group with maxchannelsperuser, it only gives you the minimum number of channels in that group

so if you're in known-users registered-users and high-reputation, and:

set known-users {
    max-channels-per-user 10;
}

set high-reputation {
    max-channels-per-user 15;
}

set registered-users {
    max-channels-per-user 20;
}

how do you select which group's rules takes precedence? if you have earned/been given more max channels, and qualify for three groups it picks the lowest - but all three of these groups are true for a registered user

0006422: query security-groups

Fri, 31 Oct 2025 13:35:51 +0100

I would like to be able to query
* which security-groups there are
* members of a given security-group.

The former could possibly best be done with /STATS?
The latter would possibly best be done with a /WHO flag?

0006580: default profile for +F (transparency for chanops/users)

Wed, 29 Oct 2025 13:58:47 +0100

Hi,

This is not necessarily a bug, maybe more of an improvement(?)...
When a sysadmin sets a default-profile in the anti-flood setting like:

anti-flood { channel { default-profile very-strict; } }

Channel owners are not aware of this, because in the channel the mode +F is not explicitly shown.
When the limit is exceeded, the restriction mode occurs, like:

*** Channel msg/noticeflood detected (limit is 30 per 15 seconds), setting mode +M

But the chanop doesn’t know why this happened, since there is no explicit +F mode set in the channel.
Most likely many chanops will contact IrcOps to understand what happened.
If the mode +F appeared explicitly in the channel, the channel owners would know the reason and could then change the +F to another profile if convenient.

I believe that modes applied to a channel should be quite transparent, both for users and for chan owners.
I understand that some already existing channels may have mlock restrictions... but if the mode +F were already explicit in newly created channels, that would be interesting.

Thanks