Skip to content

Drop federation device list updates from non-compliant user IDs - #20115

Merged
sandhose merged 5 commits into
element-hq:developfrom
barodeur:fix-forwarding-invalid-usernames
Sep 16, 2026
Merged

sandhose merged 5 commits into
element-hq:developfrom
barodeur:fix-forwarding-invalid-usernames

Conversation

@barodeur

@barodeur barodeur commented Aug 17, 2026 •

Copy link
Copy Markdown
Collaborator

This partially fixes the bug #20116

Device list update EDUs from non-compliant (grandfathered historical) user IDs are currently accepted over federation, stored, and surfaced to clients in /sync's device_lists.changed array.

For current room versions, servers must still accept events using such user IDs over federation; however they SHOULD NOT forward such user IDs to clients when referenced outside the context of an event. For example, device list updates from non-compliant user IDs would be dropped by the receiving server.

-- Matrix spec, clarified in Matrix v1.14 by matrix-spec#1506

Problem Example

A remote server sends an m.device_list_update EDU for @héllo:remote.example (non-ASCII localpart, outside the compliant U+0021–U+007E range). Synapse:

  • accepts and processes the update (resyncing the user's device list if needed)
  • stores it in the remote device list cache
  • forwards @héllo:remote.example to local clients via device_lists.changed in /sync (the leak — a non-compliant user ID referenced outside event context)

Pull Request Checklist

  • Pull request is based on the develop branch
  • Pull request includes a changelog file. The entry should:
    • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
    • Use markdown where necessary, mostly for code blocks.
    • End with either a period (.) or an exclamation mark (!).
    • Start with a capital letter.
    • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
  • Code style is correct (run the linters)

…uld be dropped

Per https://spec.matrix.org/v1.14/appendices/#historical-user-ids, servers
SHOULD NOT forward non-compliant (grandfathered historical) user IDs to
clients outside the context of an event; the spec gives dropping their
device list updates as the example.
Per https://spec.matrix.org/v1.14/appendices/#historical-user-ids, servers
SHOULD NOT forward non-compliant (grandfathered historical) user IDs to
clients when referenced outside the context of an event. Device list
updates from such user IDs previously surfaced to clients via /sync's
device_lists.changed; drop the EDU on arrival instead.
@barodeur
barodeur marked this pull request as ready for review August 28, 2026 12:12
@barodeur
barodeur requested a review from a team as a code owner August 28, 2026 12:12
@barodeur
barodeur requested review from anoadragon453 and removed request for a team August 28, 2026 12:12
@sandhose
sandhose enabled auto-merge (squash) September 16, 2026 09:06
@sandhose
sandhose merged commit 84ac9ff into element-hq:develop Sep 16, 2026
76 of 78 checks passed
HarisDotParis pushed a commit to HarisDotParis/synapse that referenced this pull request Sep 16, 2026
…ment-hq#20115)

This partially fixes the bug
element-hq#20116

Device list update EDUs from non-compliant (grandfathered historical)
user IDs are currently accepted over federation, stored, and surfaced to
clients in `/sync`'s `device_lists.changed` array.

> For current room versions, servers must still accept events using such
user IDs over federation; however they SHOULD NOT forward such user IDs
to clients when referenced outside the context of an event. For example,
device list updates from non-compliant user IDs would be dropped by the
receiving server.
>
> -- [Matrix
spec](https://spec.matrix.org/v1.14/appendices/#historical-user-ids),
clarified in Matrix v1.14 by
[matrix-spec#1506](matrix-org/matrix-spec#1506)


### Problem Example

A remote server sends an `m.device_list_update` EDU for
`@héllo:remote.example` (non-ASCII localpart, outside the compliant
U+0021–U+007E range). Synapse:
- accepts and processes the update (resyncing the user's device list if
needed)
- stores it in the remote device list cache
- forwards `@héllo:remote.example` to local clients via
`device_lists.changed` in `/sync` (**the leak** — a non-compliant user
ID referenced outside event context)

---

### Pull Request Checklist

<!-- Please read
https://element-hq.github.io/synapse/latest/development/contributing_guide.html
before submitting your pull request -->

* [x] Pull request is based on the develop branch
* [x] Pull request includes a [changelog
file](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#changelog).
The entry should:
- Be a short description of your change which makes sense to users.
"Fixed a bug that prevented receiving messages from other servers."
instead of "Moved X method from `EventStore` to `EventWorkerStore`.".
  - Use markdown where necessary, mostly for `code blocks`.
  - End with either a period (.) or an exclamation mark (!).
  - Start with a capital letter.
- Feel free to credit yourself, by adding a sentence "Contributed by
@github_username." or "Contributed by [Your Name]." to the end of the
entry.
* [x] [Code
style](https://element-hq.github.io/synapse/latest/code_style.html) is
correct (run the
[linters](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#run-the-linters))
@barodeur barodeur mentioned this pull request Oct 9, 2026
3 tasks done
reivilibre pushed a commit that referenced this pull request Oct 13, 2026
Closes #20116

> [!NOTE]
> This PR Follows #20115 which already implemented this for
`m.device_list_update`

> User IDs with localparts containing characters outside the range
U+0021 to U+007E, or with
> an empty localpart, are considered non-compliant. For current room
versions, servers must
> still accept events using such user IDs over federation; however they
SHOULD NOT forward
> such user IDs to clients when referenced outside the context of an
event. For example,
> device list updates from non-compliant user IDs would be dropped by
the receiving server.
>
> — [Spec
1.19](https://spec.matrix.org/v1.19/appendices/#historical-user-ids)

This PR prevents from forwarding non compliant user ids for the
following events:

- `m.signing_key_update` 8c3c35e
- `m.presence` 26a8dfe
- `m.typing` 1110cf2
- `m.receipt` 9e2da8b
- `m.direct_to_device` 9541232
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants