See how datadog compares to other vendors in security performance
Datadog, Inc Vector v0.54.0 was discovered to contain a SQL injection vulnerability in the seturiquery parameter in the KeyPartitioner::partition function. This vulnerability allows attackers to access sensitive database information via crafted SQL statements.
dd-trace-java is a Datadog APM client for Java. In versions of dd-trace-java 0.40.0 through prior to 1.60.2, the RMI instrumentation registered a custom endpoint that deserialized incoming data without applying serialization filters. On JDK version 16 and earlier, an attacker with network access to a JMX or RMI port on an instrumented JVM could exploit this to potentially achieve remote code execution. All three of the following conditions must be true to exploit this vulnerability: First, dd-trace-java is attached as a Java agent (-javaagent) on Java 16 or earlier. Second, a JMX/RMI port has been explicitly configured via -Dcom.sun.management.jmxremote.port and is network-reachable, Third, a gadget-chain-compatible library is present on the classpath. For JDK >= 17, no action is required, but upgrading is strongly encouraged. For JDK >= 8u121 < JDK 17, upgrade to dd-trace-java version 1.60.3 or later. For JDK < 8u121 and earlier where serialization filters are not available, apply the workaround. The workaround is to set the following environment variable to disable the RMI integration: DDINTEGRATIONRMIENABLED=false.
dd-trace-cpp is the Datadog distributed tracing for C++. When the library fails to extract trace context due to malformed unicode, it logs the list of audited headers and their values using the nlohmann JSON library. However, due to the way the JSON library is invoked, it throws an uncaught exception, which results in a crash. This vulnerability has been patched in version 0.2.2.
The Datadog PHP Tracer provides application performance monitoring and distributed tracing for PHP. Prior to 1.19.2, ddtracedeserializebaggage in ext/distributedtracingheaders.c parses incoming W3C baggage HTTP headers without enforcing DDTRACEBAGGAGEMAXITEMS or DDTRACEBAGGAGEMAXBYTES. A remote unauthenticated client can send an arbitrarily large number of comma-separated key-value pairs or a single oversized value, causing the tracer to allocate hash-map entries and consume unbounded CPU and memory on each request. Baggage extraction is enabled by default in most affected deployments unless baggage is removed from DDTRACEPROPAGATIONSTYLE or DDTRACEPROPAGATIONSTYLEEXTRACT. This issue is fixed in version 1.19.2.
dd-trace-cpp is the Datadog distributed tracing library for C++. Prior to 2.1.0, dd-trace-cpp parses incoming W3C baggage headers without enforcing DDTRACEBAGGAGEMAXITEMS or DDTRACEBAGGAGEMAXBYTES on the extraction path, even though those limits are enforced during injection. A remote unauthenticated attacker can send a header containing many comma-separated key-value pairs or one very large value, causing per-request hash-map allocation and unbounded CPU and memory consumption. Baggage extraction is enabled by default in most affected tracers unless baggage is removed from DDTRACEPROPAGATIONSTYLE or DDTRACEPROPAGATIONSTYLEEXTRACT, so affected internet-facing services can be denied service. This issue is fixed in version 2.1.0.
The Datadog Agent collects events and metrics from hosts and sends them to Datadog. A vulnerability within the Datadog Linux Host Agent versions 7.65.0 through 7.70.2 exists due to insufficient permissions being set on the opt/datadog-agent/python-scripts/pycache directory during installation. Code in this directory is only run by the Agent during Agent install/upgrades. This could allow an attacker with local access to modify files in this directory, which would then subsequently be run when the Agent is upgraded, resulting in local privilege escalation. This issue requires local access to the host and a valid low privilege account to be vulnerable. Note that this vulnerability only impacts the Linux Host Agent. Other variations of the Agent including the container, kubernetes, windows host and other agents are not impacted. Version 7.71.0 contains a patch for the issue.
An issue in the /util/http/prelude.rs endpoint of Datadog, Inc Vector v0.54.0 allows attackers to cause a Denial of Service (DoS) via a crafted request or payload.
In versions of the Datadog Android application prior to v545-5.9.2, OnCallNotificationActivity is declared exported with no permission guard. A co-installed application can launch it with attacker-controlled Intent extras, including a full-screen lock-screen message, an arbitrary on-call page ID, and an arbitrary Intent to run inside the Datadog process. This requires: A malicious application co-installed on the victim's device. An active Datadog session in the Android app. Impact: After a single tap on the Acknowledge button, the app sends a forged on-call acknowledgement to the backend under the victim's session, launches the attacker-supplied Intent from within the Datadog process (reaching otherwise non-exported components), and turns on the screen while dismissing the keyguard.
In versions of the Datadog Android application prior to v545-5.9.2, the app tags Crashlytics data with the user's Datadog UUID, with no user-facing opt-out. Impact: The Datadog user UUID and crash data are visible within Firebase Crashlytics. This UUID is not identifying outside Datadog's own systems.
In versions of the Datadog Android application prior to v541-5.9.2, BubbleChatActivity is exported with no permission guard and accepts a SEND intent with a caller-supplied conversationid. When the activity closes and no in-process session matches that ID, it unconditionally cancels notification ID 9201 (the Bits AI chat notification), with no check on the caller's identity or ownership of the conversation. This requires a malicious application co-installed on the victim's device. Impact: A co-installed application can silently dismiss the victim's Bits AI chat notification. No chat content is exposed; conversation data remains server-authentication gated and is never returned to the caller.
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 v545-5.9.2, six App Widget configuration activities (IncidentWidgetActivity, MonitorSavedViewWidgetActivity, OnCallShiftsWidgetActivity, OnCallPagesWidgetActivity, SloWidgetActivity, DashboardWidgetActivity) are exported with no permission guard. Each accepts a caller-supplied AppWidgetManager.EXTRAAPPWIDGETID and, when no deep-link destination is resolved, uses it to load the matching widget's stored session and automatically log in as that user. Because Android widget IDs are small sequential integers, a co-installed application can brute-force this value to find one that matches a widget configured on the victim's device. This requires: A malicious application co-installed on the victim's device. At least one of the six widgets configured on the victim's home screen. An active Datadog session cached locally. Impact: The matching configuration activity opens in the foreground under the victim's session and renders live infrastructure data. Exposure is limited to a visual side channel (e.g., screen recording or accessibility services); the calling application cannot programmatically read the rendered data.
In versions of the Datadog Android application prior to v554-5.9.4, two Room-backed SQLite databases store sensitive content in plaintext: LocalNotificationDatabase (notification title, message, recipient, service, tags, and on-call/incident deep links) and SearchRecentDatabase (the user's full in-app search history). Impact: Any actor able to bypass the app sandbox can read these databases in plaintext.