Xmpp id leaked in semi-anonymous MUC

Openfire
1

Hello! I post here because I am not able to post in the dev category as recommended in GitHub - igniterealtime/Openfire: An XMPP server licensed under the Open Source Apache License.

I noted that in a Semi-Anonymous MUC (hosted on OF 4.9.0) Participant with an affiliation (including the owner) has their xmpp id leaked in the Gajim info screen.

of-leaked-id
of-leaked-id711Ă—215 30.1 KB

2

Hello, i did try to replicate and what i notice was, if you create a public semi-anonymous room and then invite a Gajim user to a room, then at that particular time the Gajim will leak the JID of the one who invited(i believe that its because they are contacts already). However if you log out and in again, then there is no JID leak via the room.

I also tested with Guus, the scenario that the room is created, users are not in each others roster, the Gajim user join said room, and there is no leak.

I am using Openfire 5.0.2 and Gajim 2.3.6. In case you are still getting those leaks, you could maybe try to explain exactly the replication method.

3

Hello @zoidberg thanks for taking time to reply.

I am not the creator of the MUC, nor one of his contacts when I joined (simpy using the muc uri, it is an open one). The MUC server is OF 4.9.0. We will verify if promoting a no affiliation participant to Member will trigger that.

4

Thanks for reporting this @resoli . If the MUC is a public one, can you share its address so that we can test from our end?

5

Hello @guus I would prefer to replicate the problem on an ad-hoc muc. I have an account on the same server. Here’s the xmpp uri: xmpp:leakingjid@conference.cazzinostri.kenobit.it?join

6

Update: I made that room moderated, so you will enter with Visitor role, None affiliation

7

have tried to reproduce the issue by joining the room using a very low-level XMPP client, which allowed me to inspect the raw traffic easily. Joining the room worked without problems, and I inspected all traffic that was logged both during the join sequence and while attempting a number of MAM queries.

The MAM queries did not return any results, which is likely because the account I used does not have authorization to access archived data. Because of that, I might not be able to fully reproduce what Gajim is doing on your end.

From what I did see in the captured traffic, there is no indication of any real JIDs leaking. Specifically nothing from users “Rob” or “Ryoma123”. It would help if I knew their actual JIDs, as I could then search the logs for those exact values. What I can confirm is that no real JIDs from the cazzinostri.kenobit.it domain appear anywhere in the logs (“@cazzinostri.kenobit.it” does not occur at all). If Rob and Ryoma123 are users on that domain, then their true JIDs were not exposed in the traffic I inspected.

A few possibilities remain:

  • My test account may simply not have the required permissions to perform the same queries as your Gajim client, which would mean I am not reproducing the scenario fully.
  • Gajim might be issuing different MAM or history-related queries that I have not reproduced.
  • Or there is something else I have not considered yet.

It might be worthwhile to gather logs directly from Gajim, if that is feasible. You may need assistance from the Gajim developers to enable or interpret the relevant debugging outputs.

As mentioned earlier in the thread, @zoidberg tested later versions of Openfire and the Monitoring plugin and could not reproduce the issue there. It is possible that the problem you are seeing has already been resolved upstream. If you have not already, I would definitely recommend upgrading to a more recent Openfire release to check whether the behavior persists.

8

Besides the possibility of the bug not being present there, there is also Reactions on the newest how is that to sweeten the deal :-). i think however you also need to update your Gajim, that one do seem to be a bit old.

9

Hello @guus thank you, I reply after quoting

Yes, I think too it would be better. May you contact me by email?

Nevertheless, when I join the muc with Gajim (latest v2.4.0) using an external test account (not a @cazzinostri.kenobit.it one) I can see the jids of all participant with an affiliation. I tried to setup a fresh new Gajim user config, and recorded the xml traffic using Gajim’s debug console. I found two entries with jid:

<!-- Incoming mer 3 dic 2025, 15:10:29 (SANITIZED_TEST_JID) -->
<iq xmlns="jabber:client" xml:lang="en" type="result" id="f1f1571c-b2cd-4190-b1d1-eae2a6853d62" from="leakingjid@conference.cazzinostri.kenobit.it" to="SANITIZED_TEST_JID/gajim.53OPHSOS">
  <query xmlns="http://jabber.org/protocol/muc#admin">
    <item affiliation="owner" nick="SANITIZED_OWNER" role="moderator" jid="SANITIZED_OWNER@cazzinostri.kenobit.it" />
</query>
</iq>

<!-- Incoming mer 3 dic 2025, 15:10:29 (SANITIZED_TEST_JID) -->
<iq xmlns="jabber:client" xml:lang="en" type="result" id="6d3a6cc9-96c6-43e0-8699-975a13856630" from="leakingjid@conference.cazzinostri.kenobit.it" to="SANITIZED_TEST_JID/gajim.53OPHSOS">
  <query xmlns="http://jabber.org/protocol/muc#admin" />
</iq>


<!-- Incoming mer 3 dic 2025, 15:10:29 (SANITIZED_TEST_JID) -->
<iq xmlns="jabber:client" xml:lang="en" type="result" id="502afb2a-6aee-412d-bc66-bfee650cbfe1" from="leakingjid@conference.cazzinostri.kenobit.it" to="SANITIZED_TEST_JID/gajim.53OPHSOS">
  <query xmlns="http://jabber.org/protocol/muc#admin">
    <item affiliation="member" nick="SANITIZED_MEMBER" role="participant" jid="SANITIZED_MEMBER@cazzinostri.kenobit.it" />
</query>

MAM is broken in any MAM-enabled muc, may be a configuration issue server side?

Ok, I think upgrading to 5.0.2 should be feasible for the admin.

10

I’m using v2.4.0 (latest)

11

@guus If you provide me another channel, I can provide the whole recording, of course.

12

I tested myself v5.0.2 and I can confirm that affiliated jids leak disappeared. I don’t know how to create MUC with MAM there, but this is another story.

1 Like
13

Monitoring plugin, ok.