Skip to main content
VulnerabilityPublished

CVE-2025-43856: immich · Incorrect Implementation of Authentication Algorithm

Affects immichSource CVE Database V5

0

Not known to be exploited · CVSS 7.3 High : upgrade to 1.132.0 soon.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 4.0 base score
7.3High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 37% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 1.132.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 11 Jul 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade immich-app/immich to 1.132.0.

Affected software

ProductAffectedFixed in
GitHubimmich-app/immichpkg:github/immich-app/immichOther threatsAffected
  • <1.132.0
Fixed in
  • 1.132.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

  1. Upgrade immich instances to version 1.132.0 or later, where the vulnerability is fixed by proper validation of the OAuth2 state parameter.
  2. If immediate upgrade is not possible, implement additional access controls on the OAuth redirect URI endpoints to restrict requests to trusted origins and enforce strict session management.
  3. Disable or restrict public OAuth providers if not necessary, or configure OAuth providers to require explicit user consent on each login to reduce automatic linking risks.
  4. Monitor OAuth login flows and user account linking events for anomalies, such as unexpected OAuth account associations or login attempts from unusual IP addresses.
  5. Educate users about phishing risks and suspicious links that could trigger unauthorized OAuth login flows.
  6. Implement web application firewall (WAF) rules to detect and block suspicious OAuth login requests or iframe embedding attempts targeting immich endpoints.
  7. Regularly audit and review OAuth configurations and session management policies to ensure compliance with best practices.

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.

References

Community reviews

Loading reviews…