Synapse makes use of various properties within the unsigned object of events - either internally, or by passing them on to clients. One example is replaces_state, which is used to store the event id of the previous event with the same type and state_key, and is later used to populate the prev_content property for events served to clients.

The problem is that homeservers are free to populate unsigned, without it affecting the event hashes or signatures; a malicious or buggy homeserver could therefore populate the content with incorrect data.

Taking the example of replaces_state, Synapse overwrites this property when receiving an event, but only if there was previously an event with the same type and state_key in the room state; it is otherwise passed through unchanged. So, a malicious homeserver could confuse remote servers' clients by sending incorrect values of replaces_state over federation.

The specification is not clear on how unspecified properties within unsigned should be handled, but I think they should be stripped off by the receiving homeserver. This will ensure that if, in future, the C-S API spec is extended to specify new properties be added to unsigned, there will be no confusion about whether they were added by the local or remote homeserver.

As far as I am aware, the only properties that should be allowed in unsigned over federation are:

• invite_room_state
• knock_room_state
• age - though see also age logic for events is broken #8429.

[Aside: in an ideal world, we might have different properties for "things added by the remote homeserver - treat with caution!" vs "things added by the local homeserver - can be trusted". However, that ship has probably sailed for now.]