As we can see here, even though the listener correctly states that the buffer can be null, it doesn't handle that, resulting in NPE on serialization

Maybe it should have been like that?

ServerboundCustomQueryAnswerPacket packet = new ServerboundCustomQueryAnswerPacket(queryId, result == null ? null : new PacketByteBufLoginQueryResponse(result));

I would highly reccomend looking into doing this during the configuration phase, its the perfect place to send addional data such as this.

Just to confirm are you using Minecraft 1.20.2?

yes

Out of intrest whats your usecase for using the login networking APIs? In 1.20.2 in most cases the configuration phase should be a tottal replacement for the login phase.

For several reasons from the past we add an additional security level for top admins, we'll feel safer that way

No, this logic should be kept in the login phase.

I would highly reccomend looking into doing this during the configuration phase, its the perfect place to send addional data such as this.

The login query request is guaranteed to receive a response from a vanilla client. In comparison, detecting whether a packet is understood with ping and pong to and attaching pending authentication info onto server-side client objects are more error-prone and is more invasive. And the login network handler has a hold of the vanilla authentication information that modders wish to access.

detecting whether a packet is understood with ping and pong to and attaching pending authentication info onto server-side client objects are more error-prone and is more invasive.

This is handled by Fabric API, if its error-prone I need to know about it ASAP as reg sync and other critical parts of fabric API wont be working as expected.

The problem here is not that configuration networking is doomed (it isn't), it is that for this specific use (security check) you don't want to even proceed to configuration in the first place.