CVE-2026-47363

In versions of the Datadog Android application prior to v541-5.9.2, the exported launcher activity AppActivity accepts an attacker-supplied session (including OAuth tokens) from Intent extras with no permission guard, and signs the app into that session without validating it against the backend. This requires a malicious application co-installed on a device with the Datadog app installed, and an OAuth token the attacker is willing to load into the victim's app. Impact: A co-installed application can switch the victim's Datadog app to a session the attacker controls. This is an account-confusion issue; it does not by itself expose the victim's existing session or data.

In versions of the Datadog Android application prior to v541-5.9.2, the exported launcher activity AppActivity accepts an attacker-supplied session (including OAuth tokens) from Intent extras with no permission guard, and signs the app into that session without validating it against the backend. This requires a malicious application co-installed on a device with the Datadog app installed, and an OAuth token the attacker is willing to load into the victim's app. Impact: A co-installed application can switch the victim's Datadog app to a session the attacker controls. This is an account-confusion issue; it does not by itself expose the victim's existing session or data.

The launcher activity AppActivity in the Datadog Android application is declared android:exported="true" with launchMode="singleTask" and no permission guard. On every onCreate and onNewIntent, it invokes Intent.getUserSession(), an extension that deserializes a full UserSession — user identity, OAuth access and refresh tokens, host, organization, datacenter, and permissions — from Bundle extras keyed under the com.datadog.app.* namespace. This extension lives in the main sourceset, not a test-only sourceset, despite a misleading comment referencing internal test fixtures. Any application installed on the device can invoke the launcher with arbitrary session extras. The startup pipeline accepts the injected session, persists it to user storage, optionally rotates persisted token storage when an OAUTH_OVERRIDE_TOKEN extra is set, and performs an automatic login under the attacker-chosen identity. The session preparer returns Ready without contacting the backend whenever the injected access token is not flagged as expired-or-expiring-soon, so no server-side token introspection takes place before auto-login. Preconditions: the Datadog application installed on the victim device, and a zero-permission co-installed malicious application. The attacker must possess any OAuth access token they are willing to have the victim use, including the attacker's own Datadog tokens.

In versions of the Datadog Android application prior to v541-5.9.2, the exported launcher activity AppActivity accepts an attacker-supplied session (including OAuth tokens) from Intent extras with no permission guard, and signs the app into that session without validating it against the backend. This requires a malicious application co-installed on a device with the Datadog app installed, and an OAuth token the attacker is willing to load into the victim's app. Impact: A co-installed application can switch the victim's Datadog app to a session the attacker controls. This is an account-confusion issue; it does not by itself expose the victim's existing session or data.