Unbounded SAML message decompression in esaml allows memory exhaustion

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.

Unbounded atom creation from unsigned LogoutResponse status codes in esaml allows atom table exhaustion

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.

Unbounded atom creation while parsing SAML messages in esaml allows atom table exhaustion

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.

Dropbox Dash MCP Server DNS Rebinding via Missing Host Header Validation

The Dash MCP server bound its listener to the loopback address but never checked the host a request named. src/mcp_server_dash.py constructed the server for its network mode with the interface restricted to loopback and no transport-security settings, so a name that had been pointed at the loopback address still reached the listener while carrying the attacker's host name. A page in a visitor's browser could therefore drive the local server and invoke its company-search and file-detail tools under the Dropbox credential the server holds. Only the network mode was reachable this way; the standard input mode was not. The fix supplies transport-security settings that enable host checking and allow only the loopback name and port, rejecting other hosts before a tool runs. The repository publishes no versions, so the affected boundary is the commit preceding the fix.

Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses

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

Missing one-time-use enforcement in Samly allows replay of SAML bearer assertions

Authentication Bypass by Capture-replay vulnerability in dropbox samly allows an attacker to authenticate as the subject of a captured SAML assertion by resubmitting it. Samly.Helper.decode_idp_auth_resp/3 in lib/samly/helper.ex calls esaml_sp:validate_assertion/2, whose default duplicate detector is a no-op. The /3 arity accepting a DuplicateFun exists in esaml and implements the check, but Samly never calls it and offers no configuration to supply one, so the SAML 2.0 Web Browser SSO Profile requirement that a bearer assertion be used once is unenforced. An attacker holding a valid SAMLResponse obtained from the network, from browser history, or from logs can submit the identical bytes repeatedly until the assertion's NotOnOrAfter passes, each time establishing a session as the assertion's subject. This issue affects samly: from 0.3.0 onward.

XXE in esaml SAML library allows local file read and potential SSRF

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.

In the Samly package before 1.4.0 for Elixir, Samly.State.Store.get_assertion/3 can return an expired session, which interferes with access control because Samly.AuthHandler uses a cached session and does not replace it, even after expiry.

Dropbox SDK for Android before 1.6.2 might allow remote attackers to obtain sensitive information via crafted malware or via a drive-by download attack.

The allocate_channel_framebuffer function in uncompressed_components.hh in Dropbox Lepton 1.2.1 allows remote attackers to cause a denial of service (divide-by-zero error and application crash) via a malformed JPEG image.

Dropbox Lepton 1.2.1 allows DoS (SEGV and application crash) via a malformed lepton file because the code does not ensure setup of a correct number of threads.

dropboxd in Dropbox 0.7.110 places a zero-length directory name in the LD_LIBRARY_PATH, which allows local users to gain privileges via a Trojan horse shared library in the current working directory.

Dropbox Desktop Folder Sharing Mark-of-the-Web Bypass Vulnerability

Dropbox Desktop Folder Sharing Mark-of-the-Web Bypass Vulnerability. This vulnerability allows remote attackers to bypass the Mark-of-the-Web protection mechanism on affected installations of Dropbox Desktop. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of shared folders. When syncing files from a shared folder belonging to an untrusted account, the Dropbox desktop application does not apply the Mark-of-the-Web to the local files. An attacker can leverage this vulnerability to execute arbitrary code in the context of the current user. Was ZDI-CAN-23991.

Dropbox merou SSH Public Key public_key.py add_public_key injection

A vulnerability was found in Dropbox merou. It has been classified as critical. Affected is the function add_public_key of the file grouper/public_key.py of the component SSH Public Key Handler. The manipulation of the argument public_key_str leads to injection. It is possible to launch the attack remotely. The name of the patch is d93087973afa26bc0a2d0a5eb5c0fde748bdd107. It is recommended to apply a patch to fix this issue. VDB-216906 is the identifier assigned to this vulnerability.

Dropbox Lepton v1.2.1-185-g2a08b77 was discovered to contain a heap-buffer-overflow in the function aligned_dealloc():src/lepton/bitops.cc:108.

Dropbox.exe (and QtWebEngineProcess.exe in the Web Helper) in the Dropbox desktop application 71.4.108.0 store cleartext credentials in memory upon successful login or new account creation. These are not securely freed in the running process.

read_ujpg in jpgcoder.cc in Dropbox Lepton 1.2.1 allows attackers to cause a denial-of-service (application runtime crash because of an integer overflow) via a crafted file.

io/ZlibCompression.cc in the decompression component in Dropbox Lepton 1.2.1 allows attackers to cause a denial of service (heap-based buffer overflow and application crash) or possibly have unspecified other impact by crafting a jpg image file. The root cause is a missing check of header payloads that may be (incorrectly) larger than the maximum file size.

An issue was discovered in the com.dropbox.android application 98.2.2 for Android. The Passcode feature allows authentication bypass via runtime manipulation that forces a certain method's return value to true. In other words, an attacker could authenticate with an arbitrary passcode. NOTE: the vendor indicates that this is not an attack of interest within the context of their threat model, which excludes Android devices on which rooting has occurred

An issue was discovered in the com.dropbox.android application 98.2.2 for Android. The FingerprintManager class for Biometric validation allows authentication bypass through the callback method from onAuthenticationFailed to onAuthenticationSucceeded with null, because the fingerprint API in conjunction with the Android keyGenerator class is not implemented. In other words, an attacker could authenticate with an arbitrary fingerprint. NOTE: the vendor indicates that this is not an attack of interest within the context of their threat model, which excludes Android devices on which rooting has occurred