esaml

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.

Summary

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.

esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints read the request body and pass the SAMLResponse form field to esaml_binding:decode_response/2. The attacker's SAMLEncoding field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries zlib:unzip/1 inside a catch whenever the body is not plain XML.

2. Unbounded inflate. decode_response/2 evaluates binary_to_list(zlib:unzip(base64:decode(SAMLResponse))). zlib:unzip/1 inflates the whole stream in one call with no cap on output size, and binary_to_list/1 then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM.

3. Exhaustion before any check. All of this happens before xmerl_scan parses the document and before esaml_sp verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node.

Proof of concept

1. Build a SAMLResponse as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire.
2. Post it to the service provider's SAML consume (ACS) endpoint as the SAMLResponse form field, with SAMLEncoding set to the DEFLATE URI, or omitted to take the default clause.
3. esaml_binding:decode_response/2 inflates the stream and converts it to a charlist before any signature check. A single request spikes the Erlang VM by several gigabytes. Repeat to exhaust memory and crash the node.

Impact

An unauthenticated attacker reaches a SAML consume or single-logout endpoint and posts a small compressed SAMLResponse that inflates to gigabytes, exhausting memory. A few requests crash the Erlang VM and deny service to every user of the service provider.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.

esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The single-logout endpoint in esaml_cowboy:validate_logout/2 reads the request body, decodes the SAMLResponse form field with esaml_binding:decode_response/2, and passes a samlp:LogoutResponse document to esaml_sp:validate_logout_response/2.

2. No signature required. validate_logout_response/2 looks for a ds:Signature element and verifies it only when one is present. An unsigned document passes through unchanged to esaml:decode_logout_response/1, which requires only the Version and IssueInstant attributes before mapping the StatusCode value.

3. Interning. esaml:status_code_map/1 matches six known SAML status URNs to fixed atoms. Any other value starting with urn: falls through to a clause that interns the last colon-separated segment with list_to_atom/1. The attacker chooses that segment, so each request with a fresh value mints one permanent atom. The VM aborts when the atom table reaches its limit of about one million entries.

Proof of concept

1. Build an unsigned samlp:LogoutResponse document with Version="2.0", any IssueInstant, and a samlp:Status/samlp:StatusCode whose Value is a fresh URN such as urn:x:<unique token>.
2. Deflate and base64-encode it, and post it to the service provider's single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI.
3. esaml_sp:validate_logout_response/2 skips signature verification because none is present, esaml:decode_logout_response/1 maps the status through status_code_map/1, and the atom table grows by one entry per distinct token. The endpoint answers with an error, but the atom is never reclaimed. Repeat with fresh tokens until the VM aborts.

Impact

An unauthenticated attacker posts unsigned LogoutResponse messages with distinct status code URNs to a service provider's single-logout endpoint. Each message permanently consumes one atom table entry, and about one million of them abort the Erlang VM, denying service to every user of the service provider.

Configurations

Reachable only where the service provider exposes a single-logout endpoint that hands incoming LogoutResponse messages to esaml_sp:validate_logout_response/2, directly or through esaml_cowboy:validate_logout/2. The consume (ACS) path verifies signatures before decoding and does not reach the status code mapping.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.

esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node.

This issue affects esaml: from 0.1.0 onward.

Details

1. Input. The SAML consume (ACS) and single-logout endpoints in esaml_cowboy read the request body, capped at 128 KB, and pass the SAMLResponse form field to esaml_binding:decode_response/2. Both the DEFLATE clause and the default clause end in xmerl_scan:string/2 with namespace_conformant set.

2. Interning. xmerl_scan converts every element name, attribute name, and namespace prefix it tokenizes into an atom with list_to_atom/1, and the same happens for each namespace local name in expanded_name/4. A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire.

3. Exhaustion before any check. Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down.

Proof of concept

1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example <p0 a0="x"/> through <p4999 a4999="x"/>.
2. Deflate and base64-encode it, and post it to the service provider's SAML consume (ACS) or single-logout endpoint as the SAMLResponse form field with SAMLEncoding set to the DEFLATE URI. A document with 5,000 elements and 5,000 attributes encodes to about 33 KB.
3. esaml_binding:decode_response/2 parses it with xmerl_scan:string/2 before any signature check, and the atom table grows by 10,000 entries that are never reclaimed. Repeat with fresh names until the VM aborts.

Impact

An unauthenticated attacker posts a small SAML document with thousands of distinct element and attribute names to a service provider's consume or single-logout endpoint. Each request permanently consumes thousands of atom table entries, and a few dozen requests abort the Erlang VM, denying service to every user of the service provider.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.