UnrealIRCd Bug Tracker - Issues (all-but-resolved)

0006579: usermodes/privdeaf

Fri, 05 Jun 2026 18:14:40 +0200

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.

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

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.

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' ?

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?

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?

0006431: Underscore and match_simple()

Sun, 14 Sep 2025 18:52:56 +0200

As mentioned in https://forums.unrealircd.org/viewtopic.php?t=9370 the match_simple() function (and thus in spamfilter type simple too) seems to treat underscore as meaning: underscore or space.

It was intentional for things like +b ~realname:*some_bad_person* where it would match "Some bad person" and I think it was only meant to be like that in match_esc() but I'm not entirely sure. This was done 15+ years ago and the behavior has been like that since then.

match_simple() is called from 110+ places (and even more indirect), so.. needs some careful consideration if we want to change that back to _ meaning really _.

I don't want to do this post-rc1 of 6.1.7 and.. yeah.. to be honest not sure if i will change this in 6.1.8 either either, but it is good to have this issue filed to look at it some day.

0005304: Allow different options/features for different IP addresses or ports of the same ircd

Sun, 14 Sep 2025 18:03:27 +0200

Currently we have to run multiple instances of the ircd to achieve that.
One possible solution would be to allow "set" options in "class" blocks, and allow selecting ports in "allow" blocks.
Example (i have added "no" prefix to disable the following option in case it's enabled in the global set block):

class normal {
pingfreq 100;
maxclients 1000;
sendq 100k;
recvq 4000;
set {
prefix-quit "Quit";
options {
no websocket;
identd-check;
show-connect-info;
};
};

class websocket {
pingfreq 100;
maxclients 1000;
sendq 100k;
recvq 4000;
set {
prefix-quit "Web client exited";
options {
websocket;
no identd-check;
no show-connect-info;
};
};

allow {
ip *@*;
// all ports except those "caught" by allow blocks below
class normal;
maxperip 10;
};

allow {
ip *@*;
port 8080;
class websocket;
maxperip 2;
};

listen {
ip *;
port 6667-6669;
};

listen {
ip *;
port 8080;
options { ssl; };
};

0006567: server_ban_exception.get return strange response!

Mon, 25 Aug 2025 15:57:37 +0200

Hi,
Case 1:
When trying getting this server_ban_exception (*@::1) i have this error.
Error: For technical reasons you cannot start the host with a ':', sorry

Case 2:
There is also something strange. When i try to get information about the name (*) i have also this error
"Error: Nickname not found"

Thanks.

0006512: CHATHISTORY TARGETS has incorrect selection semantics

Wed, 11 Jun 2025 07:52:25 +0200

`CHATHISTORY TARGETS timestamp=A timestamp=B 100` has the following intended semantics: it should return targets whose *latest* message is between those two timestamps. This allows the timestamps to be used for pagination of the response.

Unreal's implementation instead returns targets that have *any* message between those two timestamps. This impedes use of the timestamps to page backwards in time.

Thanks for your work on Unreal!

0006501: CHATHISTORY BETWEEN treats both directions the same way

Wed, 09 Apr 2025 14:22:45 +0200

I have been working on an implementation of a client requesting CHATHISTORY and the use case I'm focused on is getting slices via CHATHISTORY BETWEEN. Testing on my network has led me to the conclusion that CHATHISTORY BETWEEN behavior does not match the spec, and I believe I understand the reason why in the code.

Take for instance this situation: assume the history is 100 messages long, msgids 1 (oldest) through 100 (newest). If I request BETWEEN msgid=1 msgid=100 5 (never mind for the moment how I know 100 is the newest, in practice I use a timestamp). I should get 2,3,4,5,6 as I started at the first message selector and went forward in time. If I request BETWEEN msgid=100 msgid=1 5, I should get 99,98,97,96,95 (from first selector but backwards in time).

(I asked in #ircv3 and this was agreed to be the intended behavior --- "With respect to the limit, the returned messages MUST be counted _starting from and excluding the first message selector_, while finishing on and excluding the second. This may be forwards or backwards in time.", emphasis mine.)

However, on my ircd (6.1.9), in my testing I get the same set, 2,3,4,5,6, in either request.

Digging into the code I think I understand why. hbm_return_between_figure_out_direction is a bit hard to understand, but assuming it works correctly, the implementation of hbm_return_between is incorrect for the backwards case. How the code seems to work:

* BETWEEN msgid=1 msgid=100
* direction == forwards
* return hbm_return_after() w/ timestamp_a null, timestamp_b null, msgid_a = 1, msgid_b = 100, limit = 5
* BETWEEN msgid=100 msgid=1
* direction == backwards
* create new filter
* swap timestamp_a and timestamp_b (null and null, no effect)
* swap msgid_a and msgid_b (parameter msgid=1 becomes msgid_a, parameter msgid=100 becomes msgid_b)
* return hbm_return_after() w/ timestamp_a null, timestamp_b null, msgid_a = 1, msgid_b = 100, limit = 5

Hence the identical results for both.

I may still dig deeper to understand if there's a quick fix in how the library methods work, but I believe my reading of the defect is correct at least.

0006499: Some spamfilter options are currently config-file-only and not in SPAMFILTER command

Tue, 18 Feb 2025 19:03:34 +0100

The following spamfilter features are currently only available in the spamfilter { } block but not in the SPAMFILTER command:
* spamfilter::rule (on its own or as a filter)
* spamfilter::input-conversion
* combining multiple spamfilter::action's
* spamfilter::action: set, report, stop. With the first two also having the thing that they accept parameters (mandatory for set, optional for report)

Obviously some day we would want this to be available in the SPAMFILTER command as well. And in RPC.

0006496: Mask item and destination

Wed, 12 Feb 2025 15:53:35 +0100

Earlier we had the request for set::restrict-commands on channel-message to exempt a target channel. So mask item / security group item "destination" was added in commit e03a5dfd5ffe47fe186165b8b94c7cbc935a10bb (shipped in UnrealIRCd 6.1.7).

Recently Valware suggested allowing something similar: set::restrict-commands private-message but with an exemption to sending to ircops. Of course, you could add something like destination-ircop or something but I think we first need to take a step back and consider if we need something bigger here.

Like, maybe we want all the security group checks be able to run on the destination user? Like destination ip/mask/identified/certfp/asn... ? Is that useful or is that overkill?
So...
destination-ip 1.2.3.4;
destination-tls yes;
etc... I dunno.

We could also do some extra nesting, like:
destination { ip 1.2.3.4; }
destination { rule "has_user_mode('o')"; }
destination {
ip 1.2.3.4;
tls yes;
}
etc..

I think I like the extra nesting better and it makes it more clear if you have multiple rules there that it works with the regular ANY (OR) criteria.

For crules another idea is to clone all functions and prefix the function with "destination_", so you have like destination_has_user_mode('o'). I think that would make sense because the alternative would be to force the admin (if they would like to select on both source and destination properties) to have like two crules, one in ::rule and the other in ::destination::rule which seems weird and not so flexible.

We could also start with the more simple part, the nested destination thingy, first, and then later do the improved crule stuff.

0005306: Support PROXY protocol used by TCP load balancers

Tue, 21 Jan 2025 11:28:05 +0100

Many TCP load balancers support the PROXY protocol to pass along client IP information at the start of a connection.
UnrealIRCD should support for trusting the PROXY data and using the provided client IP for connection throttling and ident.

Docs can be found here: https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/

0006493: Allow message tag to access target information (eg channel)

Fri, 03 Jan 2025 16:32:49 +0100

This because some message tags may or should behave differently depending the channel.

For example, a message tag to edit the message (and yes, i hate those, but this aside). Without knowing the channel it cannot know if +S/+c/+G are in effect and thus if some filtering would be needed.

Regarding the current API limitations:
* The mtag->is_ok() happens too soon, before running the command, and a PRIVMSG or NOTICE can be directed to multiple targets anyway (with or without filtering)
* In HOOKTYPE_NEW_MESSAGE we don't pass any information about the target (eg channel) either

I think, if anything, we could add some HOOKTYPE_NEW_MESSAGE_EX or something with the target or... some other hook.

This popped up with the irccloud-tags module but was encountered before by Valware with draft/reply and... i think a third person too... just never made it to bugs.unrealircd.org (unless I am blind)

0006491: channel privmsg / notice with prefix not sending correctly

Tue, 24 Dec 2024 22:15:53 +0100

when sending a channel notice, any prefix gives to +hoaq including voice

0006486: UnrealIRCd Windows binaries have incorrect PE header when built from source

Fri, 06 Dec 2024 08:37:54 +0100

this only affects builds from source.
i am using a extension for the version tab but basically details tab also shows there's a issue as well.
CompanyName is none for some reason as well.
regression

0006479: Extban to handle Anope's account ID

Tue, 29 Oct 2024 20:55:48 +0100

Recently, Anope added account identifiers on the 2.1 branch with the commit https://github.com/anope/anope/commit/378ae21ac7e26b551cf79368264a93450370abca which is something very useful.

Currently, if we use the extban ~account, it can be easily bypassed by doing `/ns set display `, which changes the account main nickname. On the other hand, account identifiers are kept the same, which means that a user needs to drop their nickname and register it again in order to change it.

I suggest that we add the ~account-id (this is just a name suggestion) extban to be used with Anope's account identifiers.

0005938: Some "About" buttons returning blank text box named "UnrealIRCd License".

Tue, 22 Oct 2024 18:29:24 +0200

Using version 5.2.0.2, downloaded from site.

About -> UnrealIRCd Team
About -> Additional Credits
About-> License

All show a blank box called "UnrealIRCd License"

0006475: Information that would be useful in the Event TKL_ADD JSON

Sat, 12 Oct 2024 03:43:32 +0200

Hi
I’m showing a JSON log of this TKL_ADD to better explain

Object
timestamp:"2024-10-12T01:22:01.639Z"
level:"info"
subsystem:"tkl"
event_id:"TKL_ADD"
log_source:"irc.d.com"
msg:"Soft G-Line added: '%*@92.xx' [reason: xxxx] [by: Sysop!SysOp@admin.d.com] [duration: 1d]"
tkl:Object
type:"gline"
type_string:"Soft G-Line"
set_by:"Sysop!SysOp@admin.d.com"
set_at:"2024-10-12T01:22:01.000Z"
expire_at:"2024-10-13T01:22:01.000Z"
set_at_string:"Sat Oct 12 01:22:01 2024 GMT"
expire_at_string:"Sun Oct 13 01:22:01 2024 GMT"
duration_string:"1d"
set_at_delta:0
name:"%*@92.xxx"
reason:"xxx"

Would it be possible to create a new key that would add the list of nicknames of the users affected by a tkl ?

0006474: Support for "is_shunned()" in crules

Thu, 10 Oct 2024 09:35:12 +0200

It's not the first time I see someone asking for actions related to when a user is shunned.

Recently the user Shems wanted to prevent users that are shunned from being affected by the TLD block.

If we had something like "is_shunned()", we could probably use something like:

tld {
    mask {
        country CH;
        exclude-rule "is_shunned()";
    }
    motd "ircd.motd";
    rules "ircd.rules";
    channel "#Suis";
}

This could be useful for other things, but this is one example

0005290: U5: extban to prevent channel history

Sun, 15 Sep 2024 19:10:57 +0200

'i' suggested an extban to ban people from seeing channel history.
Similarly, if combined with +e, you could create a whitelist for channel history.
In all cases, +H will need to be set.

0006466: server.rehash over HTTP POST succeeds but gives empty response

Sat, 07 Sep 2024 09:08:14 +0200

Someone on IRCd mentioned that the server.rehash JSON-RPC API call over HTTPS POST closes the connection without a response. The same API call works well over UNIX sockets (tested) and to my knowledge also over Websockets (untested, so I may be wrong there).

Rehashing is a complex task and the webserver module gets unloaded and loaded again, maybe something goes wrong there. I had to do various things to make this API call work in the first place.

Must confess this has low priority for me and.. I think the closing without a response only happens for the successful case" and not when "rehash failed", so that way you can differentiate... but of course this bug should not be there... it should work regardless of the transport type.

0006465: Extban ~partmsg doesn't filter quit messages, only part ones

Sat, 31 Aug 2024 16:31:10 +0200

I've used extban `~partmsg` on a relayed/bridged channel to hide part/quit reasons to cut some info on the quit messages.

While part reasons are correctly hidden/filtered, quit messages aren't