Vulnerability-Lookup

GHSA-4MHX-38G6-R4WQ

Vulnerability from github – Published: 2026-08-20 18:30 – Updated: 2026-08-20 18:30

Details

Insufficient Verification of Data Authenticity vulnerability in dropbox samly allows an attacker to establish an authenticated session using a SAML response the service provider never requested.

Samly.SPHandler.validate_authresp/3 in lib/samly/sp_handler.ex validates a SAML response for the SP-initiated flow by comparing only the RelayState value, the IdP identifier, and the presence of a target URL held in the session. It never compares SubjectConfirmationData/@InResponseTo against the ID of the AuthnRequest the service provider issued, and that request ID is never persisted, so no comparison is possible. SAML 2.0 Core section 4.1.4.3 requires a service provider to reject a response whose InResponseTo does not match a request it made. The underlying esaml library checks status, signature, recipient, audience, and staleness, but likewise never inspects InResponseTo, so nothing else closes the gap. Exploitation requires a validly signed assertion from the trusted IdP, which an attacker can obtain for their own account, and a RelayState matching the victim's session; the assertion signature itself remains intact, so this is not a signature-forgery issue.

This issue affects samly: from v0.3.0 onward.

Severity

7.6 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-53425"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-20T18:16:27Z",
    "severity": "HIGH"
  },
  "details": "Insufficient Verification of Data Authenticity vulnerability in dropbox samly allows an attacker to establish an authenticated session using a SAML response the service provider never requested.\n\nSamly.SPHandler.validate_authresp/3 in lib/samly/sp_handler.ex validates a SAML response for the SP-initiated flow by comparing only the RelayState value, the IdP identifier, and the presence of a target URL held in the session. It never compares SubjectConfirmationData/@InResponseTo against the ID of the AuthnRequest the service provider issued, and that request ID is never persisted, so no comparison is possible. SAML 2.0 Core section 4.1.4.3 requires a service provider to reject a response whose InResponseTo does not match a request it made. The underlying esaml library checks status, signature, recipient, audience, and staleness, but likewise never inspects InResponseTo, so nothing else closes the gap. Exploitation requires a validly signed assertion from the trusted IdP, which an attacker can obtain for their own account, and a RelayState matching the victim\u0027s session; the assertion signature itself remains intact, so this is not a signature-forgery issue.\n\nThis issue affects samly: from v0.3.0 onward.",
  "id": "GHSA-4mhx-38g6-r4wq",
  "modified": "2026-08-20T18:30:59Z",
  "published": "2026-08-20T18:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53425"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-53425.html"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-53425"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/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",
      "type": "CVSS_V4"
    }
  ]
}

CVE-2026-53425 (GCVE-0-2026-53425)

Vulnerability from cvelistv5 – Published: 2026-08-20 17:26 – Updated: 2026-08-20 18:38

Title

Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses

Summary

Insufficient Verification of Data Authenticity vulnerability in dropbox samly allows an attacker to establish an authenticated session using a SAML response the service provider never requested. Samly.SPHandler.validate_authresp/3 in lib/samly/sp_handler.ex validates a SAML response for the SP-initiated flow by comparing only the RelayState value, the IdP identifier, and the presence of a target URL held in the session. It never compares SubjectConfirmationData/@InResponseTo against the ID of the AuthnRequest the service provider issued, and that request ID is never persisted, so no comparison is possible. SAML 2.0 Core section 4.1.4.3 requires a service provider to reject a response whose InResponseTo does not match a request it made. The underlying esaml library checks status, signature, recipient, audience, and staleness, but likewise never inspects InResponseTo, so nothing else closes the gap. Exploitation requires a validly signed assertion from the trusted IdP, which an attacker can obtain for their own account, and a RelayState matching the victim's session; the assertion signature itself remains intact, so this is not a signature-forgery issue. This issue affects samly: from 0.3.0 onward.

Severity

7.6 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

CWE

CWE-345 - Insufficient Verification of Data Authenticity

Assigner

EEF mitre root

References

2 references

URL	Tags
https://cna.erlef.org/cves/CVE-2026-53425.html	relatedthird-party-advisory
https://osv.dev/vulnerability/EEF-CVE-2026-53425	related

Impacted products

3 products

Vendor	Product	Version
dropbox	samly	Affected: 0.3.0 , < * (semver) cpe:2.3:a:dropbox:samly::::::::
dropbox	samly	Affected: 8a5bb1b4a4753d05470da2036323477f63cfdf4c , < * (git) cpe:2.3:a:dropbox:samly::::::::
handnot2	samly	Affected: 8a5bb1b4a4753d05470da2036323477f63cfdf4c , < * (git) cpe:2.3:a:handnot2:samly::::::::

Credits

Mark Madsen Jonatan Männchen / EEF

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.hex.pm",
          "cpes": [
            "cpe:2.3:a:dropbox:samly:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.Samly.SPHandler\u0027"
          ],
          "packageName": "samly",
          "packageURL": "pkg:hex/samly",
          "product": "samly",
          "programFiles": [
            "lib/samly/sp_handler.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.Samly.SPHandler\u0027:consume_signin_response/1"
            }
          ],
          "repo": "https://github.com/dropbox/samly",
          "vendor": "dropbox",
          "versions": [
            {
              "lessThan": "*",
              "status": "affected",
              "version": "0.3.0",
              "versionType": "semver"
            }
          ]
        },
        {
          "collectionURL": "https://github.com",
          "cpes": [
            "cpe:2.3:a:dropbox:samly:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.Samly.SPHandler\u0027"
          ],
          "packageName": "dropbox/samly",
          "packageURL": "pkg:github/dropbox/samly",
          "product": "samly",
          "programFiles": [
            "lib/samly/sp_handler.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.Samly.SPHandler\u0027:consume_signin_response/1"
            }
          ],
          "repo": "https://github.com/dropbox/samly",
          "vendor": "dropbox",
          "versions": [
            {
              "lessThan": "*",
              "status": "affected",
              "version": "8a5bb1b4a4753d05470da2036323477f63cfdf4c",
              "versionType": "git"
            }
          ]
        },
        {
          "collectionURL": "https://github.com",
          "cpes": [
            "cpe:2.3:a:handnot2:samly:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.Samly.SPHandler\u0027"
          ],
          "packageName": "handnot2/samly",
          "packageURL": "pkg:github/handnot2/samly",
          "product": "samly",
          "programFiles": [
            "lib/samly/sp_handler.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.Samly.SPHandler\u0027:consume_signin_response/1"
            }
          ],
          "repo": "https://github.com/handnot2/samly",
          "vendor": "handnot2",
          "versions": [
            {
              "lessThan": "*",
              "status": "affected",
              "version": "8a5bb1b4a4753d05470da2036323477f63cfdf4c",
              "versionType": "git"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:dropbox:samly:*:*:*:*:*:*:*:*",
                  "versionStartIncluding": "0.3.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:a:handnot2:samly:*:*:*:*:*:*:*:*",
                  "versionStartIncluding": "0.3.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ],
          "operator": "AND"
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Mark Madsen"
        },
        {
          "lang": "en",
          "type": "coordinator",
          "value": "Jonatan M\u00e4nnchen / EEF"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eInsufficient Verification of Data Authenticity vulnerability in dropbox samly allows an attacker to establish an authenticated session using a SAML response the service provider never requested.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eSamly.SPHandler.validate_authresp/3\u003c/code\u003e in \u003ccode\u003elib/samly/sp_handler.ex\u003c/code\u003e validates a SAML response for the SP-initiated flow by comparing only the \u003ccode\u003eRelayState\u003c/code\u003e value, the IdP identifier, and the presence of a target URL held in the session. It never compares \u003ccode\u003eSubjectConfirmationData/@InResponseTo\u003c/code\u003e against the ID of the \u003ccode\u003eAuthnRequest\u003c/code\u003e the service provider issued, and that request ID is never persisted, so no comparison is possible. SAML 2.0 Core section 4.1.4.3 requires a service provider to reject a response whose \u003ccode\u003eInResponseTo\u003c/code\u003e does not match a request it made. The underlying \u003ccode\u003eesaml\u003c/code\u003e library checks status, signature, recipient, audience, and staleness, but likewise never inspects \u003ccode\u003eInResponseTo\u003c/code\u003e, so nothing else closes the gap. Exploitation requires a validly signed assertion from the trusted IdP, which an attacker can obtain for their own account, and a \u003ccode\u003eRelayState\u003c/code\u003e matching the victim\u0027s session; the assertion signature itself remains intact, so this is not a signature-forgery issue.\u003c/p\u003e\n\u003cp\u003eThis issue affects samly: from 0.3.0 onward.\u003c/p\u003e"
            },
            {
              "base64": false,
              "type": "text/markdown",
              "value": "Insufficient Verification of Data Authenticity vulnerability in dropbox samly allows an attacker to establish an authenticated session using a SAML response the service provider never requested.\n\n`Samly.SPHandler.validate_authresp/3` in `lib/samly/sp_handler.ex` validates a SAML response for the SP-initiated flow by comparing only the `RelayState` value, the IdP identifier, and the presence of a target URL held in the session. It never compares `SubjectConfirmationData/@InResponseTo` against the ID of the `AuthnRequest` the service provider issued, and that request ID is never persisted, so no comparison is possible. SAML 2.0 Core section 4.1.4.3 requires a service provider to reject a response whose `InResponseTo` does not match a request it made. The underlying `esaml` library checks status, signature, recipient, audience, and staleness, but likewise never inspects `InResponseTo`, so nothing else closes the gap. Exploitation requires a validly signed assertion from the trusted IdP, which an attacker can obtain for their own account, and a `RelayState` matching the victim\u0027s session; the assertion signature itself remains intact, so this is not a signature-forgery issue.\n\nThis issue affects samly: from 0.3.0 onward."
            }
          ],
          "value": "Insufficient Verification of Data Authenticity vulnerability in dropbox samly allows an attacker to establish an authenticated session using a SAML response the service provider never requested.\n\nSamly.SPHandler.validate_authresp/3 in lib/samly/sp_handler.ex validates a SAML response for the SP-initiated flow by comparing only the RelayState value, the IdP identifier, and the presence of a target URL held in the session. It never compares SubjectConfirmationData/@InResponseTo against the ID of the AuthnRequest the service provider issued, and that request ID is never persisted, so no comparison is possible. SAML 2.0 Core section 4.1.4.3 requires a service provider to reject a response whose InResponseTo does not match a request it made. The underlying esaml library checks status, signature, recipient, audience, and staleness, but likewise never inspects InResponseTo, so nothing else closes the gap. Exploitation requires a validly signed assertion from the trusted IdP, which an attacker can obtain for their own account, and a RelayState matching the victim\u0027s session; the assertion signature itself remains intact, so this is not a signature-forgery issue.\n\nThis issue affects samly: from 0.3.0 onward."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-62",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-62 Cross Site Request Forgery"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7.6,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "PASSIVE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345 Insufficient Verification of Data Authenticity",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-20T18:38:13.727Z",
        "orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
        "shortName": "EEF"
      },
      "references": [
        {
          "tags": [
            "related",
            "third-party-advisory"
          ],
          "url": "https://cna.erlef.org/cves/CVE-2026-53425.html"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://osv.dev/vulnerability/EEF-CVE-2026-53425"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
    "assignerShortName": "EEF",
    "cveId": "CVE-2026-53425",
    "datePublished": "2026-08-20T17:26:35.537Z",
    "dateReserved": "2026-06-09T11:01:47.529Z",
    "dateUpdated": "2026-08-20T18:38:13.727Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

GHSA-4MHX-38G6-R4WQ

CVE-2026-53425 (GCVE-0-2026-53425)

Tags

Sightings

Nomenclature