Nickname field silently populated with incorrect data (own profile name / garbled text)

[PierroKo]

Guidelines

• I have searched open and closed issues for duplicates
• I am submitting a bug report for existing functionality that does not work as intended
• This isn't a feature request or a discussion topic

Environment

• Platform: iOS (iPhone) + Signal Desktop (linked device)
• iPhone model: iPhone 14 Pro
• iOS version: 26.5
• Signal iOS version: 8.18.1 (1691)
• Signal Desktop version: Signal Desktop 8.18.0

Bug description

The Nickname field (Signal Settings > 1:1 chat > tap header > Nickname) is being silently populated with incorrect data for two different contacts, without me ever having set a nickname for them. This causes the wrong name to display everywhere the contact's name normally appears (chat list, chat header), even though the contact's actual profile-name-change events are being tracked correctly in the conversation timeline (see attached screenshot showing correct sequential profile name change notifications: "A.toute → Pomme → ail").

I have found two separate occurrences of this bug, with two distinct symptoms:

Case 1 — Nickname populated with my own profile name

• This contact is not saved in my iPhone's system Address Book.
• This contact has no avatar/photo (only the default first-letter icon, using the first letter of the corrupted nickname).
• The "Conversation/Contact info" screen (showing the contact's real profile info) is not accessible/not present for this contact — unlike for a normal contact.
• Going to Nickname for this contact shows: First name / Last name fields populated with the exact nickname/profile name I use for myself — not an approximation, an exact match.
• Displayed identically on both iOS and Desktop (linked device).

Case 2 — Nickname populated with garbled/interleaved text

Unlike Case 1, this contact's profile data is being retrieved and displayed correctly by Signal: I have not manually saved her in my iPhone's system Address Book — she appears in my Signal contact list automatically (we've exchanged messages before) — and her name updates correctly each time she changes her profile name, most recently yesterday.
Going to "Contact info" for this conversation correctly shows her actual, current self-chosen profile name.

• However, the Nickname fields show corrupted text that looks like two strings merged/interleaved character-by-character: First name field = "De eu a c", Last name field = "Décédé" (this does not correspond to any name she has ever used, nor to any name I would have typed).
• This corrupted nickname is the one displayed in the chat list and chat header, overriding her correct, current profile name.
• Displayed identically on both iOS and Desktop (linked device), consistent with the Nickname being synced via the encrypted Storage Service (PIN-protected).
• The conversation timeline correctly logged her sequence of profile name changes (with correct "before/after" name pairs in each system message) — so the profile-name-change tracking itself is not the source of the bug.

Steps to reproduce

Unclear — I never manually set a Nickname for either contact. The corrupted values appear to have been set automatically at some point (possibly around a profile name change event, or during a Storage Service sync), without any deliberate action on my part.

Expected result

The Nickname field should remain empty unless I explicitly set it. The name displayed for a contact should be their address-book name (if saved) or their current self-chosen profile name (if not) — never my own profile name or corrupted/garbled text.

Actual result

The Nickname field is being auto-populated with incorrect data:

• In one case, with my own profile name (exact match).
• In another case, with garbled text unrelated to any name involved in the conversation.

This overrides the correct name and is confusing, and in the case of my own name appearing on someone else's contact card, mildly concerning from a data-integrity standpoint.

Additional notes

• Both corrupted Nicknames are synced identically across my linked devices (iPhone + Desktop), suggesting the corruption is present in the encrypted Storage Service record itself, not just a local rendering glitch.
• Clearing the Nickname fields manually appears to be the only current workaround.
• Happy to provide a debug log if useful (Signal Settings > Help > Contact Us > include debug log).

[PierroKo]

Update: I manually cleared the Nickname fields for both contacts as a workaround.

• Case 2 (garbled nickname "De eu a c" / "Décédé"): clearing the Nickname fields immediately fixed both the displayed name and the avatar — her current profile name and letter-avatar now display correctly.
• Case 1 (nickname = my own profile name): clearing the Nickname fields fixed the displayed name immediately, but the avatar kept showing the first letter of my own (previous, corrupted) nickname even after saving — it only updated to reflect the correct current data (first letter of his actual profile name) after I force-quit and reopened the app on iOS. This indicates the corruption also affected a locally cached avatar/letter value, separate from the synced Nickname field itself, and that this local cache isn't automatically invalidated when the underlying Nickname is cleared — it required an app restart to refresh.

Security concern: I want to flag that, independent of the display bug itself, I'm concerned about the underlying mechanism that caused my own profile data to be written into another user's local contact record without any action on my part. I understand this occurred entirely within my own account's encrypted Storage Service (synced across my own linked devices via my own PIN), so I don't believe this represents data being exposed to the other user or a third party — but I'd appreciate confirmation from the team on whether this is understood to be a purely local/client-side data-integrity bug (e.g. record index confusion during a sync), or whether it could have broader implications worth investigating further.

Happy to provide a debug log if that would help narrow down the cause.