CVE-2025-43856 (GCVE-0-2025-43856)
Vulnerability from cvelistv5
Published
2025-07-11 17:10
Modified
2025-07-11 18:13
Severity ?
7.3 (High) - 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
CWE
  • CWE-303 - Incorrect Implementation of Authentication Algorithm
Summary
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
security-advisories@github.comhttps://github.com/immich-app/immich/security/advisories/GHSA-3832-6r8h-9cfm
Impacted products
Vendor Product Version
immich-app immich Version: < 1.132.0
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-43856",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-07-11T18:12:48.333486Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-07-11T18:13:00.477Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "immich",
          "vendor": "immich-app",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.132.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s own, this wouldn\u0027t 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": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7.3,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "ACTIVE",
            "vectorString": "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-303",
              "description": "CWE-303: Incorrect Implementation of Authentication Algorithm",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-07-11T17:10:52.423Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/immich-app/immich/security/advisories/GHSA-3832-6r8h-9cfm",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/immich-app/immich/security/advisories/GHSA-3832-6r8h-9cfm"
        }
      ],
      "source": {
        "advisory": "GHSA-3832-6r8h-9cfm",
        "discovery": "UNKNOWN"
      },
      "title": "immich allows account hijacking through oauth2"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-43856",
    "datePublished": "2025-07-11T17:10:52.423Z",
    "dateReserved": "2025-04-17T20:07:08.555Z",
    "dateUpdated": "2025-07-11T18:13:00.477Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-43856\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2025-07-11T17:15:36.877\",\"lastModified\":\"2025-07-15T13:14:49.980\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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\u0027s own, this wouldn\u0027t 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.\"},{\"lang\":\"es\",\"value\":\"immich es una soluci\u00f3n de gesti\u00f3n de fotos y v\u00eddeos autoalojada de alto rendimiento. En versiones anteriores a la versi\u00f3n 1.132.0, immich era vulnerable al secuestro de cuentas mediante OAuth2, ya que no se verificaba el par\u00e1metro de estado. Este par\u00e1metro de estado de OAuth2 es similar a un token CSRF; por lo tanto, cuando el usuario inicia el flujo de inicio de sesi\u00f3n, se genera este token impredecible, que se guarda de alguna manera en la sesi\u00f3n del navegador y se transmite al proveedor de identidad, que devolver\u00e1 el par\u00e1metro de estado al redirigir al usuario de vuelta a immich. Antes de que el usuario inicie sesi\u00f3n, es necesario verificar dicho par\u00e1metro para garantizar que el usuario inici\u00f3 el inicio de sesi\u00f3n activamente en esta sesi\u00f3n del navegador. Por s\u00ed solo, esto no ser\u00eda tan grave, pero cuando immich usa la p\u00e1gina /user-settings como redirect_uri, vincular\u00e1 autom\u00e1ticamente las cuentas si el usuario ya ha iniciado sesi\u00f3n. Esto significa que si alguien tiene una instancia de immich con un proveedor p\u00fablico de OAuth (como Google), un atacante puede, por ejemplo, incrustar un iframe oculto en una p\u00e1gina web o incluso enviar a la v\u00edctima una URL de inicio de sesi\u00f3n de OAuth falsificada con un c\u00f3digo que inicia sesi\u00f3n en la cuenta de OAuth del atacante, redirige a immich y vincula las cuentas. Despu\u00e9s, el atacante puede iniciar sesi\u00f3n en la cuenta de la v\u00edctima con sus propias credenciales de OAuth. Esta vulnerabilidad est\u00e1 corregida en la versi\u00f3n 1.132.0.\"}],\"metrics\":{\"cvssMetricV40\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"4.0\",\"vectorString\":\"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X\",\"baseScore\":7.3,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"attackRequirements\":\"PRESENT\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"ACTIVE\",\"vulnConfidentialityImpact\":\"HIGH\",\"vulnIntegrityImpact\":\"HIGH\",\"vulnAvailabilityImpact\":\"HIGH\",\"subConfidentialityImpact\":\"NONE\",\"subIntegrityImpact\":\"NONE\",\"subAvailabilityImpact\":\"NONE\",\"exploitMaturity\":\"NOT_DEFINED\",\"confidentialityRequirement\":\"NOT_DEFINED\",\"integrityRequirement\":\"NOT_DEFINED\",\"availabilityRequirement\":\"NOT_DEFINED\",\"modifiedAttackVector\":\"NOT_DEFINED\",\"modifiedAttackComplexity\":\"NOT_DEFINED\",\"modifiedAttackRequirements\":\"NOT_DEFINED\",\"modifiedPrivilegesRequired\":\"NOT_DEFINED\",\"modifiedUserInteraction\":\"NOT_DEFINED\",\"modifiedVulnConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedVulnIntegrityImpact\":\"NOT_DEFINED\",\"modifiedVulnAvailabilityImpact\":\"NOT_DEFINED\",\"modifiedSubConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedSubIntegrityImpact\":\"NOT_DEFINED\",\"modifiedSubAvailabilityImpact\":\"NOT_DEFINED\",\"Safety\":\"NOT_DEFINED\",\"Automatable\":\"NOT_DEFINED\",\"Recovery\":\"NOT_DEFINED\",\"valueDensity\":\"NOT_DEFINED\",\"vulnerabilityResponseEffort\":\"NOT_DEFINED\",\"providerUrgency\":\"NOT_DEFINED\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-303\"}]}],\"references\":[{\"url\":\"https://github.com/immich-app/immich/security/advisories/GHSA-3832-6r8h-9cfm\",\"source\":\"security-advisories@github.com\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2025-43856\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-07-11T18:12:48.333486Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-07-11T18:12:53.047Z\"}}], \"cna\": {\"title\": \"immich allows account hijacking through oauth2\", \"source\": {\"advisory\": \"GHSA-3832-6r8h-9cfm\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV4_0\": {\"version\": \"4.0\", \"baseScore\": 7.3, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"HIGH\", \"vectorString\": \"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\", \"userInteraction\": \"ACTIVE\", \"attackComplexity\": \"LOW\", \"attackRequirements\": \"PRESENT\", \"privilegesRequired\": \"LOW\", \"subIntegrityImpact\": \"NONE\", \"vulnIntegrityImpact\": \"HIGH\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"HIGH\", \"subConfidentialityImpact\": \"NONE\", \"vulnConfidentialityImpact\": \"HIGH\"}}], \"affected\": [{\"vendor\": \"immich-app\", \"product\": \"immich\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 1.132.0\"}]}], \"references\": [{\"url\": \"https://github.com/immich-app/immich/security/advisories/GHSA-3832-6r8h-9cfm\", \"name\": \"https://github.com/immich-app/immich/security/advisories/GHSA-3832-6r8h-9cfm\", \"tags\": [\"x_refsource_CONFIRM\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"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\u0027s own, this wouldn\u0027t 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.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-303\", \"description\": \"CWE-303: Incorrect Implementation of Authentication Algorithm\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2025-07-11T17:10:52.423Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2025-43856\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-07-11T18:13:00.477Z\", \"dateReserved\": \"2025-04-17T20:07:08.555Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2025-07-11T17:10:52.423Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.