Immich 3.3.1 Bug Review: Any Cluster Group Member Can Reset Everyone’s Facial Recognition Data
Immich 3.3.1 contains a striking permission problem in its new People cluster group system. A GitHub user reported on October 8, 2026 that a nonadministrator account inside a cluster group could reset facial recognition for the entire group, forcing several hours of recovery afterward. Immich itself warns that this operation deletes all recognized people for every user in the group and removes names and birth dates that have already been assigned. Inspection of the current implementation shows that the reset operation requires only ordinary cluster group membership, not administrator status or a separate elevated permission.
The timing makes the report particularly relevant. Immich released version 3.3.1 on October 8, only hours after the issue was filed, and the same permission structure is still present in that release. The destructive operation remains available through the server API and the normal sharing settings interface. At the time of writing, the GitHub issue is open and has not yet received a maintainer response.
What the Immich 3.3.1 bug does
Immich recently expanded its People system so several users can participate in the same facial recognition cluster group. Faces across the photographs of group members can be clustered together, allowing recognized people to be shared between accounts rather than maintaining completely isolated recognition databases. The same settings page includes a button named “Reset facial recognition” that reruns recognition across the group. Immich warns before execution that resetting recognition will delete all people for all users in the group and that existing names and birth dates will be lost.
That scope is intentional rather than an accidental side effect of the reset process. The problem reported on GitHub concerns who is allowed to initiate it. According to the reporter, a normal nonadministrator group member was able to trigger the reset for everyone. The current Immich implementation supports that observation rather than contradicting it.
Immich uses a read permission for a destructive group operation
The relevant Immich server endpoint is POST /cluster-groups/:id/regenerate-people. Its own API description says the endpoint will “Forcefully re-run facial recognition for all faces of users in this group.” Instead of requiring an administrative or destructive action permission, the controller protects the endpoint with Permission.ClusterGroupRead. The service performs the same ClusterGroupRead access check immediately before placing the forced facial recognition job into the queue.
A read permission would ordinarily imply that the account is permitted to see information about the cluster group, while resetting everyone’s recognition database changes data belonging to multiple users. Immich does not currently introduce a separate permission such as cluster group management or facial recognition administration for this operation. The practical result is that the ability to belong to the group is also enough to request a complete group recognition reset.
The membership check confirms the behavior
Immich's access implementation makes the permission boundary clearer. For ClusterGroupRead, the server checks whether the current user's clusterGroupId matches the requested group and treats that user as having access. There is no administrator test inside that membership check. An invited user can also receive read access to a group in some contexts, although the reset service itself still requires the requested group to pass the server access check.
The relevant database check is therefore concerned with membership, not authority over the other members. A user does not need to own the server, hold the Immich administrator role, or possess a special cluster management designation before reaching the reset operation. This aligns with the GitHub report from a user who says a nonadministrator account successfully reset recognition for everyone. It also means the behavior can be traced to an explicit permission decision rather than merely inferred from the interface.
The Immich interface exposes the same capability
The web interface does not appear to hide the reset button from ordinary cluster group members. The sharing settings page loads the current user's cluster group and displays a button that invokes clusterGroupRegeneratePeople after showing a confirmation dialog. The same page also shows group membership and other cluster controls. There is no visible administrator condition surrounding the facial recognition reset button in the current implementation.
The warning dialog accurately describes how destructive the action is. Immich tells the user that resetting facial recognition will delete all people for all users in the group and that names and birth dates will be lost. This means the software clearly understands that the operation affects data beyond the account pressing the button. The unusual part is that the permission protecting the operation does not reflect that broader scope.
The damage is not the loss of the original photos
The bug does not delete the photographs stored in Immich. Facial recognition data is derived from those photographs, so Immich can process the images again and reconstruct clusters after a reset. That distinction keeps the issue separate from permanent photo deletion or storage corruption. The reporter nevertheless says recovery took several hours, and some manually entered information has a different recovery story.
Immich's own warning specifically states that existing names and birth dates will be lost. Automatic facial analysis may eventually rediscover groups of similar faces, but a machine cannot necessarily reconstruct the human supplied identity information that was attached to those groups before the reset. A large library with many identified people can therefore lose substantial organizational work even though every original photograph remains intact. The cost is partly computation and partly the destruction of metadata that users created themselves.
A second permission concern appears in the same cluster group design
The same GitHub report raises another concern: ordinary members can invite additional users into the cluster group. The current implementation again supports the basic observation. Creating a cluster group request uses Permission.ClusterGroupRequestCreate, and the access check permits the operation when the requesting user's account belongs to the relevant cluster group. There is no separate cluster owner or administrator check in that path.
Whether this second behavior is a bug or an intentional collaborative design choice is less clear. A group can reasonably be designed so every member may invite another person, while a different product might reserve invitations for the original creator or an administrator. Immich currently appears to follow the collaborative model even though the reporter expected stricter control. The facial recognition reset is harder to dismiss as a mere difference in expectations because the operation explicitly destroys shared recognition data and manually assigned metadata.
Immich 3.3.1 does not appear to fix the reset permission
Immich 3.3.1 was published on October 8, 2026. The release still protects the regenerate-people endpoint with Permission.ClusterGroupRead, and the corresponding service still uses the same read permission before queuing the forced facial recognition job. The newer release therefore does not appear to contain a permission change addressing the GitHub report. Updating from 3.3.0 to 3.3.1 should not currently be interpreted as a fix for this specific behavior.
That does not mean Immich has formally accepted the report as a security vulnerability. The issue is extremely recent, remains open, and currently contains no maintainer response establishing whether the permission is accidental or intentional. The implementation does establish the underlying behavior with considerably more certainty than the issue report alone. Any member of a cluster group who passes the ordinary membership access check can currently reach the group wide regeneration operation.
Is this an Immich security vulnerability?
Calling the issue a remote security vulnerability would overstate what has been found. An unknown Internet user cannot use this behavior simply by discovering an Immich server, since the person needs an authenticated account with access to the relevant cluster group. There is no evidence here of remote code execution, authentication bypass, or access to an unrelated Immich installation. The trust boundary exists between authenticated members of the same People cluster group.
Within that boundary, the permission model deserves attention. One group member can apparently initiate an operation that Immich itself says removes every person's recognition data across the group and discards names and birth dates. That is a destructive privilege affecting other accounts, yet the server currently authorizes it using the same permission associated with reading the cluster group. Whether Immich eventually labels the behavior a security issue, authorization bug, or intentional design choice will depend on the maintainers' response.
The fix would likely require a permission decision, not a facial recognition rewrite
Nothing in the current evidence suggests that Immich's facial recognition engine itself is malfunctioning. The reset operation appears to be doing exactly what the application tells the user it will do. The questionable part is authorization before that operation begins. A narrower permission check could potentially separate ordinary group membership from authority to regenerate recognition data for everyone.
Immich could reserve the reset for server administrators, introduce a cluster group management role, require approval from other members, or redesign the operation so each user controls only their own derived data. Those are product decisions rather than evidence of one uniquely correct implementation. The present model simply takes the broadest approach by giving every qualifying group member the ability to initiate the shared reset. For groups containing several independent users, that creates a considerable amount of destructive authority behind one confirmation dialog.
What Immich users should know
Anyone using the new People cluster group feature should understand that membership currently appears to confer more control than simply sharing facial recognition information. Another group member can reach the reset operation that affects recognition data across the entire group. Administrators who assumed only the server administrator could perform such a reset should not rely on that assumption in Immich 3.3.1. The risk grows with larger groups and libraries containing substantial manually named face data.
The bug is unusually clear because the three relevant pieces line up. A user reported successfully performing the reset from a nonadministrator account, Immich's interface explicitly says the action deletes recognition data for everyone in the group, and the server protects the operation with an ordinary group read permission. The maintainers have not yet said whether this was intentional. Until they do, the safest description is a confirmed permission structure with a newly reported destructive consequence.
Download Immich 3.3.1 Server
Immich 3.3.1 is distributed primarily as a self hosted server rather than a conventional Windows or Mac desktop application. The official Docker Compose configuration for the current release can be downloaded directly from the Immich GitHub release. The project also provides a rootless Docker Compose configuration for installations using that deployment model.
Official Immich 3.3.1 Docker Compose download:
Official Immich 3.3.1 rootless Docker Compose download:
Download Immich 3.3.1 for Android
Immich publishes official Android APK files directly through GitHub. The general release APK contains the current Immich 3.3.1 mobile application and can be installed manually on supported Android devices. Architecture specific packages are also provided on the same GitHub release page for users who prefer a smaller build.
Official Immich 3.3.1 Android APK:
Immich 3.3.1 GitHub release:
Immich GitHub Bug Report
The original report was filed as Immich issue #32250 on October 8, 2026. It remains open at the time of writing, so the project's eventual classification and response may change as maintainers review the behavior. The issue can be followed directly on GitHub along with any future discussion or fix.
Immich issue #32250:
Immich GitHub:
Tighten the opening and state the user riskRemove repeated permission analysis
Comments