immich is a high performance self-hosted photo and video management solution. Prior to 1.132.0, immich is vulnerable to account hijacking through oauth2, because the state parameter is not being checked. The oauth2 state parameter is similar to a csrf token, so when the user starts the login flow this unpredictable token is generated and somehow saved in the browser session and passed to the identity provider, which will return the state parameter when redirecting the user back to immich. Before the user is logged in that parameter needs to be verified to make sure the login was actively initiated by the user in this browser session. On it's own, this wouldn't be too bad, but when immich uses the /user-settings page as a redirect_uri, it will automatically link the accounts if the user was already logged in. This means that if someone has an immich instance with a public oauth provider (like google), an attacker can - for example - embed a hidden iframe in a webpage or even just send the victim a forged oauth login url with a code that logs the victim into the attackers oauth account and redirects back to immich and links the accounts. After this, the attacker can log into the victims account using their own oauth credentials. This vulnerability is fixed in 1.132.0.
Metrics
Affected Vendors & Products
References
History
Sat, 12 Jul 2025 13:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Metrics |
epss
|
Fri, 11 Jul 2025 19:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Metrics |
ssvc
|
Fri, 11 Jul 2025 17:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | immich is a high performance self-hosted photo and video management solution. Prior to 1.132.0, immich is vulnerable to account hijacking through oauth2, because the state parameter is not being checked. The oauth2 state parameter is similar to a csrf token, so when the user starts the login flow this unpredictable token is generated and somehow saved in the browser session and passed to the identity provider, which will return the state parameter when redirecting the user back to immich. Before the user is logged in that parameter needs to be verified to make sure the login was actively initiated by the user in this browser session. On it's own, this wouldn't be too bad, but when immich uses the /user-settings page as a redirect_uri, it will automatically link the accounts if the user was already logged in. This means that if someone has an immich instance with a public oauth provider (like google), an attacker can - for example - embed a hidden iframe in a webpage or even just send the victim a forged oauth login url with a code that logs the victim into the attackers oauth account and redirects back to immich and links the accounts. After this, the attacker can log into the victims account using their own oauth credentials. This vulnerability is fixed in 1.132.0. | |
Title | immich allows account hijacking through oauth2 | |
Weaknesses | CWE-303 | |
References |
| |
Metrics |
cvssV4_0
|

Status: PUBLISHED
Assigner: GitHub_M
Published: 2025-07-11T17:10:52.423Z
Updated: 2025-07-11T18:13:00.477Z
Reserved: 2025-04-17T20:07:08.555Z
Link: CVE-2025-43856

Updated: 2025-07-11T18:12:53.047Z

Status : Awaiting Analysis
Published: 2025-07-11T17:15:36.877
Modified: 2025-07-15T13:14:49.980
Link: CVE-2025-43856

No data.