New Relic security bulletins

Security Bulletin NR17-01

Wed, 09 Dec 2020 00:00:00 +0000

Summary

A security update for New Relic's Node.js agent eliminates a vulnerability that allows potential sensitive information disclosure via query parameters from the referer header.

Release date:

January 12, 2017

Vulnerability identifier:

NR17-01

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Node.js agent

1.25.4

1.36.1

Node.js agent

2.0

2.3.1-beta

Vulnerability information [#vuln-info]

New Relic's Node.js agent collects the request headers during an error trace to help determine the root cause of problems. The referer header is the URI that identifies the address of the webpage that linked to the resource being requested. It is possible that the referer URI may contain sensitive information in the request query parameters. New Relic has found that the query parameters are not properly stripped during the error trace. This update fixes this by stripping the query parameters from the referer in the request header before sending this data to New Relic.

Mitigating factors [#factors]

Best practices recommend not using query parameters to pass sensitive data.

Workarounds

New Relic has not identified any workarounds for this vulnerability.

Report security vulnerabilities to New Relic [#report]

New Relic is committed to the security of our customers and their data. If you believe you have found a security vulnerability in one of our products or websites, we welcome and greatly appreciate you reporting it to New Relic's coordinated disclosure program. For more information, see Reporting security vulnerabilities.

For more help [#more_help]

Additional documentation resources include:.

Notification of Apollo.io security incident

Thu, 10 Dec 2020 00:00:00 +0000

October 9, 2018

This is a summary of the 2018 security breach of the systems of Apollo.io and New Relic's response.

Security officer statement [#statement]

Over the weekend, New Relic was alerted by a sales productivity tool vendor, Apollo.io, about a security breach of their systems, which contained business-card-like customer contact information such as name, email address, phone number, company name, and job title. We are actively investigating this issue, and at this time we believe that a subset of our customers’ and prospects’ contact info may have been included.

New Relic did not sell the data to Apollo.io, but shared it solely as part of using the vendor service, which means that New Relic was the “data controller” of the impacted information and Apollo our “data processor” as defined by the General Data Protection Regulation 2016/679 (“GDPR”). No customer data from the New Relic product platform (for which New Relic acts as “data processor”) was ever linked with Apollo.io’s services or was impacted.

At New Relic, the security and privacy of our customers’ data is paramount, and we practice strict information security policies for engaging any third-party vendor. We are continuously evaluating our policies and processes across all vendors.

Please follow discuss.newrelic.com/c/security-notifications for additional information on this incident.

- Shaun Gordon, VP, Chief Security Officer, New Relic

Summary of incident [#nr-action]

Who is affected?

We are currently investigating who is impacted, but we believe that the vendor’s breach was limited to business contact information.

What happened?

New Relic was recently notified by Apollo.io that personal data that we shared with them in accordance with our Privacy Policy was exposed by a breach. We then started our investigation to learn more about the scope of the data involved. Our privacy policy is described further at: newrelic.com/termsandconditions/privacy. New Relic did not sell the data to Apollo, but shared it solely to assist in providing services to New Relic.

What data was compromised?

We are continuing our investigation, but we believe that customer or potential customer email addresses, company names, business contact information, and the names of the customers to whom those emails relate were potentially exposed.

We believe that no financial account information (such as credit card numbers, bank account numbers, etc.), government issued identification numbers (such as social security numbers or passport numbers) or sensitive categories of personal data as defined under GDPR (such as medical information, religious preference, etc.) was exposed.

What action did New Relic take?

We have reached out to Apollo.io requesting additional information and are continuing to investigate internally.

What further actions will New Relic take?

Based on our continuing investigation, we will provide further information as appropriate.

Do you need to notify EU data protection authorities of this incident?

No. As explained above, New Relic is the “data controller” of the contact information that was exposed as a result of this incident. Accordingly, and in keeping with our responsibilities as a “data controller” under the GDPR, we will submit a notice to our lead data protection authority. We will not disclose any customer information as part of this notice.

Update and resolution [#update-resolution]

November 5, 2018

Apollo.io, a sales intelligence vendor, was notified about a security breach of their systems by an external security researcher. The data involved contained business-card-like contact information such as name, email address, phone number, company name, and job title. After investigation of this issue, we determined that a specific set of New Relic customer and prospect contact info had been included but we have found no evidence of misuse. Per our request, all data from New Relic obtained by Apollo.io has been purged from their systems.

New Relic did not sell the data to Apollo.io, but shared it solely as part of using the vendor service, which means that New Relic was the “data controller” of the impacted information and Apollo.io our “data processor” as defined by the General Data Protection Regulation 2016/679 (“GDPR”). No customer data from the New Relic product platform (for which New Relic acts as “data processor”) was ever linked with Apollo.io 30’s services or was impacted.

Our commitment to our customers [#commitment]

At New Relic, the security and privacy of our customers is paramount, and we practice strict information security policies for engaging any third-party vendor.

We value our relationship with you. If you have any additional questions, we encourage customers to contact us at support.newrelic.com. For more information about our privacy policy, visit newrelic.com/termsandconditions/privacy.

Security Bulletin NR17-02

Wed, 09 Dec 2020 00:00:00 +0000

Summary

A security update for New Relic's .NET agent fixes a vulnerability that made it possible for the agent to send sensitive information to New Relic during an error trace by capturing query parameters from the referer header.

Release date:

January 12, 2017

Vulnerability identifier:

NR17-02

Priority:

Medium

Affected software [#h2_code]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

.NET agent

5.11 - 5.23

Only when Async is enabled

6.6

.NET agent

6.0 - 6.5

6.6

Vulnerability information [#vuln-info]

New Relic's .NET agent collects the request headers during an error trace to help determine the root cause of problems. The referer header is the URI that identifies the address of the webpage that linked to the resource being requested. It is possible that the referer URI may contain sensitive information in the request query parameters. New Relic has found that the query parameters are not properly stripped during the error trace. This update fixes this by stripping the query parameters from the referer in the request header before sending this data to New Relic.

Mitigating factors

Async is disabled by default in .NET agent versions 5.11.0 - 5.23.0.
Best practices recommend not using query parameters to pass sensitive data.

Workarounds

New Relic has not identified any workarounds for this vulnerability.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:

Security Bulletin NR17-04

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for New Relic's .NET agent fixes a vulnerability where the agent could unintentionally capture service request parameters from WCF applications.

Release date:

May 4, 2017

Vulnerability identifier:

NR17-04

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

.NET agent

6.8.172.0 (and greater)

With WCF

6.11.613.0

Vulnerability information [#vuln-info]

New Relic’s .NET Agent version

6.8.172.0

added visibility into Error Analytics. By default the agent will capture error events, and with WCF applications this is captured as event type

TransactionError

. New Relic has found that the

**service.request.**

* attributes may contain sensitive information that should not be sent to New Relic. A fix has been made to disable the collection of these parameters during the error collection. Customers are encouraged to upgrade to the latest version of the .NET agent.

Mitigating factors [#factors]

Only .NET agents with Error Analytics and WCF applications are affected.
All service request attributes are disabled in High-security mode.

Workarounds

Users who are affected and unable to upgrade may choose to manually configure the .NET agent to not capture service request parameters. Users can exclude

**service.request.**

* attributes from the

errorCollector

stanza in their newrelic.config file.

<attributes enabled="true">
     <exclude > service.request.*</exclude>
 </attributes>

For details please refer to our .NET agent Error Collector configuration

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR17-03

Wed, 09 Dec 2020 00:00:00 +0000

Summary

A security update for New Relic's Ruby agent fixes a vulnerability where the agent could unintentionally capture raw aggregate queries with MongoDB. New Relic recommends updating to the latest remediated version.

Release date:

February 9, 2017

Vulnerability identifier:

NR17-03

Priority:

Low

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Ruby agent

3.13.1 (and greater)

With MongoDB driver 2.1 (and greater)

3.18.1

Vulnerability information [#vuln-info]

New Relic’s Ruby agent version 3.13.1 added visibility to MongoDB queries with version 2.1 and greater of the MongoDB driver for Ruby. The agent's default setting for

mongo.obfuscate_queries

is true. This should cause the agent to obfuscate the values in Mongo queries before sending this information to New Relic. However, when using the aggregate pipeline with this version of the driver, the aggregate queries were not properly obfuscated.

Mitigating factors [#factors]

Only customers who use version 2.1 and greater of the Ruby Driver for MongoDB are affected
Aggregate queries generally do not contain sensitive information

Workarounds

Users who are affected and are unable to upgrade may choose to configure the Ruby agent to not capture mongoDB queries. Users can set

mongo.capture_queries

to false to prevent the agent from sending any information about the query.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR17-06

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for New Relic's .NET agent fixes a vulnerability where the agent could unintentionally capture query parameters from external HTTP requests during a transaction trace.

Release date:

Dec 18, 2017

Vulnerability identifier:

NR17-06

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

.NET agent

5.11.0 - 6.19.330

Transaction Trace

6.20.166.0

Vulnerability information [#vuln-info]

New Relic’s .NET agent captures a transaction trace to get detailed information about a single transaction including function calls, database calls, and external calls. By default, the agent should not collect the details of external calls (HTTP requests). Previous versions of the agent will collect the external http request parameters which may contain sensitive information. This release fixes the default behavior of the .NET agent to not collect the request parameters of external HTTP requests.

Mitigating factors [#factors]

Query parameters used in external HTTP requests made using HttpClient, WebRequest, or other library that uses these calls.
Transaction Trace enabled (default setting)

Workarounds

Disable transaction trace in the .NET agent configuration.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR17-05

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for New Relic's Java agent fixes a vulnerability where the agent could unintentionally capture full SQL queries when SQL obfuscation is enabled.

Release date:

May 30, 2017

Vulnerability identifier:

NR17-05

Priority:

High

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Java agent

3.0.0-3.39.0

With SQL obfuscation

3.39.1

Vulnerability information [#vuln-info]

New Relic’s Java agent can be configured to obfuscate SQL query information. This setting is forced when high-security mode is enabled. New Relic has found that, when an exception is thrown during the query, full SQL query information may still be captured as part of the error trace when SQL obfuscation is enabled. A fix has been made to disable the collection of this information during error collection. Customers are encouraged to upgrade to the latest version of the Java agent.

Mitigating factors [#factors]

Only Java agents using SQL obfuscation are affected.

Workarounds

New Relic has not identified any workarounds for this vulnerability.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR18-02

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the Python agent to to improve SQL obfuscation with SQLite.

Release date:

Jan 9, 2018

Vulnerability identifier:

NR18-02

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Python agent

SQLite Obfuscation

2.100.0.84

Vulnerability information [#vuln-info]

The New Relic Python agent should obfuscate SQL query parameters. This fixes an issue in SQLite transaction tracing. If the query parameters were passed with double quoted strings, the agent was not properly obfuscating these parameters.

Mitigating factors [#factors]

Generally, all SQL query parameter strings should be string literals and passed in single quotes. However, the Python SQLite API allows developers to use double quoted strings in some cases.

Workarounds

If you are unable to upgrade the agent, you may be able to take the following actions to ensure you do not send any SQLite query parameters.

Use single quote string literals with SQLite.
Disable SQL collection by configuring transaction_tracer.record_sql to off.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR18-01

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the Python agent to prevent a developer from accidentally capturing custom API parameters in High-security mode.

Release date:

Jan 9, 2018

Vulnerability identifier:

NR18-01

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Python agent

High-security mode

2.100.0.84

Vulnerability information [#vuln-info]

An internal audit of the Python High-security mode revealed that the agent could send additional data to New Relic by customizing message params with the tracing APIs. Custom parameters may be sent to New Relic if a developer is passing additional parameters using either the function trace API or the message trace API. These should be disabled when High-security mode is enabled.

Mitigating factors [#factors]

This only affects customers that have enabled High-security mode with the Python agent and a developer is adding additional information to the tracing API.

Workarounds

If you are unable to upgrade the agent, you may be able to take the following action to ensure you do not send any additional data in High-security mode.

Remove any custom params to the function trace API or the message trace API.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR18-03

Thu, 10 Dec 2020 00:00:00 +0000

Summary

Patch Kernel for Meltdown CPU Vulnerability

Release date:

Jan 12, 2018

Vulnerability identifier:

NR18-03

Priority:

High

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Synthetics Private Location

Version 1.5.2 or lower

1.5.3

Vulnerability information [#vuln-info]

Private location images with synthetic monitoring have been updated with patches to protect against the Meltdown CPU vulnerability. Patches to address Spectre have yet to be released by Ubuntu.

Additionally, customers can run in-place upgrades by accessing their private location and running:

sudo apt-get update
sudo apt-get dist-upgrade

and subsequently rebooting their machine.

Additional Information: Ubuntu Advisory

Mitigating factors [#factors]

Private locations run inside a customer’s data center and will be monitoring internal, trusted web applications.

Workarounds

No known workarounds exist.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

COVID-19

Thu, 14 Jan 2021 00:00:00 +0000

This document describes New Relic’s current operating plan and our commitment to keeping our products and services running for our customers.

New Relic COVID-19 Business Continuity Response and Actions [#statement]

In light of the current events related to COVID-19, we would like to update you regarding actions taken both to preserve the health and well-being of our staff and to address potential impact to the delivery of the software and services New Relic provides. We would also like to inform you of our approach to keeping ahead of any impact to both our own and our customer’s business. We greatly appreciate the trust you give to us for enabling the performance of your own applications and services.

As a company with SaaS based roots, our people are well accustomed to the technology and practices that underlie the operation of a cloud native platform. Our services are delivered over the internet and in many cases rely on environments or systems under customer control. New Relic’s Site-Engineering teams have taken steps to enhance and refine monitoring for both uptime and a smooth customer experience. We do this with real-time data and deep visibility to make sure our products stay up and can be supported.

Helping our community [#community]

Businesses are suddenly having to scale more quickly than ever: grocery stores, medical websites, video conferencing tools, online education apps, media outlets, streaming video platforms, exercise apps, and more. Many companies are experiencing unforeseen pressure on their online services and systems, and some with only a portion of their usual staff. New Relic’s applications and services have been critical to helping companies go through their “biggest days ever.” That's why New Relic exists.

So we are stepping up to help in a variety of ways. For example, we’ve announced the expansion of our existing nonprofit product donation program to allow any organization engaged in COVID-19 relief to use New Relic’s platform free of charge for 90 days, which can be extended based on the crisis duration.

Taking care of our people and our business [#business]

In order to mitigate and maintain minimal impact on employees, the New Relic Crisis Management team has implemented various policies and actions. Among the actions taken, we have suspended travel for all employees until we determine risk has significantly been reduced. We've also moved all meetings and planned internal conferences to completely virtual formats. We’ve temporarily closed our offices globally and have implemented a “work-from-home policy”, in line with our business continuity plans to ensure the continued operation of all aspects of our business including business support and product delivery.

Given our global presence, New Relic has a robust program in place to enable our workforce to work remotely with security and access to the services necessary to support our business and our customers. We’ve enhanced the capability for our engineers, already on-call and comfortable working remotely, by ramping up VPN capacity so they can continue on a fully remote basis.

We reaffirm our commitment to the continued delivery of the capabilities our customers rely on for keeping their own systems performing. We’re making sure that customers can get support they need when they need it. We are partnering closely with customers to ensure they are prepared for managing their performance during these times.

COVID-19 resources [#resources]

We will continue to post relevant updates on this page. You can also read more at:

Read more about New Relic’s COVID-19 relief program for non-profits.
You can also read Lew Cirne's recent blog post about the proactive steps we're taking to support you and your business during this time.
If you have additional questions, contact us through your account executive or through New Relic Support.

Security Bulletin NR18-06

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the Node.js agent corrects an issues where the agent may capture all transaction attributes.

Release date:

Mar 5, 2018

Vulnerability identifier:

NR18-06

Priority:

High

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Node.js agent

2.8.0, 2.9.0

2.9.1

Vulnerability information [#vuln-info]

The agent may capture all transaction attributes, even with High-security mode enabled on the account. This may include sensitive data attached to that transaction.

Workarounds

New Relic has not identified any workarounds for this vulnerability.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR18-04

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the .NET agent to prevent the capture of error messages during an error trace or error event when high-security mode is enabled.

Release date:

Jan 22, 2018

Vulnerability identifier:

NR18-04

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

.NET agent

Error Trace

7.0.2.0

Vulnerability information [#vuln-info]

New Relic’s .NET error collection captures information about uncaught exceptions and sends them to New Relic. If High-security mode is enabled, the agent should not capture details of the error messages. This release fixes the agent for error traces and error events so that the error message is not sent to New Relic when High-security mode is enabled.

Mitigating factors [#factors]

This is a special feature of High-security mode.

Workarounds

Disable error collection in the agent configuration or ignore specific exceptions in the configuration.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR18-05

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the Infrastructure agent to prevent capturing command line parameters.

Release date:

Feb 8, 2018

Vulnerability identifier:

NR18-05

Priority:

High

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Infrastructure agent

1.0.822 - 1.0.872

Error trace

1.0.888

Vulnerability information [#vuln-info]

New Relic’s Infrastructure agent collects information about running processes, including process command lines. The default configuration setting strip_command_line: true should prevent additional command line parameters from being sent to New Relic. With some command line options, the agent will capture the additional command line parameters even with that setting enabled.

Mitigating factors [#factors]

Generally, sensitive data will not be part of the command line options.
On Linux systems, the command line parameters will only be collected if the command line arguments (flags) have paths with a path separator element (/).
On Windows systems, the command line parameters will only be collected if the command line has switches starting with / or - and contain path separator elements (\).

Workarounds

The only solution for this issue is to update the Infrastructure agent.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR18-07

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the Java, Python, and .NET agents corrects an issue where the agent may report DB query results to New Relic or re-issue an SQL statement.

Release date:

Mar 7, 2018

Vulnerability identifier:

NR18-07

Priority:

High

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Java agent

3.26.1 to 3.47.0

SQL query

3.47.1

Python agent

1.1.0.192 to 2.106.0.87

SQL query

2.106.1.88

.NET agent

2.5.112.0 to 6.21.0.0

7.0.2.0 to 7.1.229

SQL query with MySQL

8.0 or 6.22 (For .NET Framework 3.5)

Vulnerability information [#vuln-info]

New Relic agents run explain plans for Slow Transaction Traces and Slow SQL Queries. Previous versions of the agents would run an explain plan on the SQL query by prepending the query with explain. This may cause an issue when there are multiple statements separated by semicolons in a single query. The first statement in the string returns its explain plan, but any subsequent statement after that may execute as a general SQL statement. Depending on the language, library, and database, the agent may return the results of the additional statements to New Relic. It is also possible that the additional statements could execute an additional INSERT or UPDATE command. With this security update, New Relic agents will no longer run explain plans on any query that contains a semicolon as a statement separator.

Mitigating factors [#factors]

Many SQL libraries and language frameworks prevent various forms of executing multiple statements with explain.
Explain plans are off for newer versions of the .NET agent.

Workarounds

Disable explain plans with transaction tracer in the agent configuration:

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR18-08

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the Node.js agent fixes a vulnerability in the https-proxy-agent module.

Release date:

Apr 12, 2018

Vulnerability identifier:

NR18-08

Priority:

Low

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Node.js agent

All

4.0.0

Vulnerability information [#vuln-info]

The New Relic Node.js agent uses https-proxy-agent as an option to send data to the New Relic collector via an HTTP or HTTPS proxy server. The Node.js agent used a version of this module which was vulnerable to Uninitialized Memory Exposure and Denial of Service. This fix updates the module to a version that is not vulnerable.

Mitigating Circumstances [#workarounds]

Triggering this security vulnerability requires control of the agent proxy authentication configuration.

Workarounds

New Relic has not identified any workarounds for this vulnerability.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR18-10

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the Windows Infrastructure agent corrects an issue where a hard-coded file path may allow a malicious user to override the agent configuration.

Release date:

June 18, 2018

Vulnerability identifier:

NR18-10

Priority:

High

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Windows Infrastructure agent

From 1.0.682 to 1.0.912

1.0.934

Vulnerability information [#vuln-info]

The New Relic Windows Infrastructure agent looks in specific locations for configuration files. A Unix-only file path was included in the Windows agent which could allow a malicious user to override the configuration file. With this security update, the Windows Infrastructure agent will no longer look in a Unix-specific location.

Mitigating factors [#factors]

This vulnerability only exists on Windows systems.
This vulnerability requires existing access to the system.

Workarounds

N/A

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR18-09

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the Java agent corrects an issue where the agent may not properly obfuscate all SQL query information when record_sql is set to off.

Release date:

May 2, 2018

Vulnerability identifier:

NR18-09

Priority:

Low

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected versions

Remediated Version

Java agent

All

4.1.0

Vulnerability information [#vuln-info]

The New Relic Java agent runs explain plans for slow transaction traces and slow SQL queries. When a customer has set record_sql to off, is running PostgreSQL, and has an explain plan run, the agent may not properly obfuscate all information in the query.

Workarounds

Disable explain plans with transaction_tracer in the Java agent configuration.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:.

Security Bulletin NR18-11

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the Windows Infrastructure agent corrects an issue where the agent may execute privileged binaries in the system path.

Release date:

October 8, 2018

Vulnerability identifier:

NR18-11

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Windows Infrastructure agent

From 1.0.829 to 1.0.1002

1.0.1015

Vulnerability information [#vuln-info]

The New Relic Windows Infrastructure agent may execute system commands as part of its normal operation. In affected versions of the Windows Infrastructure agent, a malicious user with permission to change the system PATH could potentially abuse this functionality to run arbitrary binaries with elevated privileges.

Mitigating factors [#factors]

This vulnerability only exists on Windows systems.
This vulnerability requires existing access to the system and permission to modify the system PATH.

Workarounds

Upgrade to the latest New Relic Windows Infrastructure agent.

Report security vulnerabilities to New Relic [#report]

For more help [#more_help]

Additional documentation resources include:

Security Bulletin NR18-12

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the New Relic Infrastructure agent for Windows corrects an issue where the agent may follow unprivileged hard links or junction folders.

Release date:

November 28, 2018

Vulnerability identifier:

NR18-12

Priority:

Low

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Windows Infrastructure agent

<1.0.1052

1.0.1052

Vulnerability information [#vuln-info]

The New Relic Windows Infrastructure agent writes to various files as part of its normal operation. An unprivileged user may be able to use Windows hard link or folder junction policies to point to files in privileged locations. This could cause the agent to create or append data to privileged files.

Mitigating factors [#factors]

This vulnerability only exists on Windows systems.

Workarounds

Update to the latest New Relic Infrastructure agent for Windows.

Report security vulnerabilities to New Relic [#report]

Security Bulletin NR19-01

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the .NET agent corrects an issue where query strings may be captured when using OpenRasta instrumentation.

Release date:

January 9, 2019

Vulnerability identifier:

NR19-01

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

.NET agent

<8.12.216.0

8.12.216.0

Vulnerability information [#vuln-info]

When using OpenRasta instrumentation, the full URL may be captured on instrumented requests. This may result in query strings being collected which can contain sensitive information

Mitigating factors [#factors]

This vulnerability only exists when using OpenRasta instrumentation.

Workarounds

Update to the latest New Relic .NET agent.
Disable OpenRasta instrumentation.

Report security vulnerabilities to New Relic [#report]

Security Bulletin NR19-02

Thu, 10 Dec 2020 00:00:00 +0000

Summary

Request parameters are added as segment attributes, even when the agent is configured with High-security mode or Configurable Security Policies. This may result in unexpected data being collected.

Release date:

April 1, 2019

Vulnerability identifier:

NR19-02

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

Node.js agent

3.0.0-5.6.2

5.6.3

Vulnerability information [#vuln-info]

By design, request parameters are added as segment attributes. Request parameters should be ignored when the agent is configured with High-security mode or the attributes_include Configurable Security Policy.

Mitigating factors [#factors]

Only affects agents configured with High-security mode or the attributes_include Configurable Security Policy.

Workarounds

Set attributed.enabled to false to prevent all attributes from being collected.
Update to the latest New Relic Node.js agent.

Report security vulnerabilities to New Relic [#report]

Security Bulletin NR19-05

Thu, 14 Jan 2021 00:00:00 +0000

Summary

A security update for the .NET agent corrects an issue where metric names are not properly identified for SQL queries with parameters that have been manually constructed.

Release date:

August 26, 2019

Vulnerability identifier:

NR19-05

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

.NET agent

< 8.18.241.0

8.18.241.0

.NET agent

< 6.24.0.0

6.24.0.0

Vulnerability information [#vuln-info]

When manually constructing SQL queries that execute stored procedures with parameters, a missing space before the first value may cause the agent to incorrectly identify the metric name. This may result in sensitive data being included in metric names.

Mitigating factors [#factors]

This vulnerability only affects applications that manually assemble SQL queries with parameters, without using parameterized queries. It’s recommended that applications use parameterized queries to help avoid introducing SQL injection vulnerabilities.

Workarounds

Utilize parameterized queries, this also helps to prevent SQL injection vulnerabilities.
Update to the latest New Relic .NET agent.

Report security vulnerabilities to New Relic [#report]

Security Bulletin NR19-03

Thu, 10 Dec 2020 00:00:00 +0000

Summary

A security update for the .NET agent corrects an issue where certain character combinations may prevent query obfuscation when instrumenting Microsoft SQL Server.

Release date:

April 22, 2019

Vulnerability identifier:

NR19-03

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Notes

Remediated version

.NET agent

< 8.15.455.0

8.15.455.0

.NET agent

< 6.23.0.0

6.23.0.0

Vulnerability information [#vuln-info]

When configured to obfuscate SQL queries, the .NET agent will pass all queries through an obfuscation function. Due to the way Microsoft SQL Server sanitizes queries, certain character combinations may be generated that could cause this obfuscation to fail.

Mitigating factors [#factors]

This vulnerability only exists when instrumenting Microsoft SQL Server and query obfuscation is enabled.

Workarounds

Disable database instrumentation.
Update to the latest New Relic .NET agent.

Report security vulnerabilities to New Relic [#report]

Security Bulletin NR20-01

Thu, 14 Jan 2021 00:00:00 +0000

Summary

A security update for the .NET agent corrects an issue where full SQL queries may be sent to the agent log.

Release date:

January 16, 2020

Vulnerability identifier:

NR20-01

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Remediated version

.NET Core agent

5.16.71.0 - 8.21.34.0

8.23.107.0

.NET Framework agent

5.16.71.0 - 8.21.34.0

6.25.0.0

Vulnerability information [#vuln-info]

In order to generate explain plans, a copy of the SQL query is created and the query is reissued with a request for the execution plan. If the explain plan fails, the agent may log the full SQL statement which could include the parameter values.

Mitigating factors [#factors]

The agent will only log this information when set to the DEBUG or FINEST logging levels.

Workarounds

Ensure that logging level is not set to DEBUG or FINEST.
Disable capturing of explain plans.
Ensure that file location of log files is secured.
Update to the latest New Relic .NET agent.

Report security vulnerabilities to New Relic [#report]

New Relic is committed to the security of our customers and your data. If you believe you have found a security vulnerability in one of our products or websites, we welcome and greatly appreciate you reporting it to New Relic's coordinated disclosure program. For more information, see our documentation about reporting security vulnerabilities.

Security Bulletin NR19-04

Thu, 14 Jan 2021 00:00:00 +0000

Summary

A security update for private minions corrects an issue where the minion may generate local log files containing sensitive data.

Release date:

July 22, 2019

Vulnerability identifier:

NR19-04

Rating:

Medium

Affected software [#affected]

The following minion versions are affected:

Name

Affected version

Notes

Remediated version

Containerized private minions

< 2.2.6

2.2.6

VM private minions (legacy)

All

Containerized private minions 2.2.6

Vulnerability information [#vuln-info]

Synthetic monitoring's private minions create logs automatically to aid in debugging. In earlier minion versions, these logs could contain sensitive data such as secure credentials being used in synthetic scripts. These logs are stored locally on the minion, but this information is now filtered out.

Workarounds

Update to the latest containerized private minions.

Report security vulnerabilities to New Relic [#report]

Security Bulletin NR21-02

Mon, 26 Apr 2021 00:00:00 +0000

Summary

A security update to the Java agent reconfigured the YAML parser to include a SafeConstructor, which removes the ability to have limited user controlled code executed.

Release date:

April 26th, 2021

Vulnerability identifier:

NR21-02

Priority:

Low

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Remediated version

Java agent

< 6.4.2

6.5.0

Vulnerability information [#vuln-info]

A specified notation, when parsed through an unsafe Yaml.load() call, will create a new Java object and invoke its constructor, potentially leading to code execution. An attacker would have to have access to the agent’s host to edit the newrelic.yml file to include a crafted payload that would execute arbitrary code once the agent starts up.

Mitigating factors [#factors]

This vulnerability requires an attacker already having access to the host in order to modify the newrelic.yml config file on a victim’s machine, which in itself is a mitigating factor. However, there are additional steps that you can take to either completely patch this issue or harden your systems against it:

Update your Java agent to patch this vulnerability
Revoke write privileges to your newrelic.yml file

Workarounds

Update to the latest New Relic Java agent.

Report security vulnerabilities to New Relic [#report]

Security Bulletin NR20-02

Thu, 14 Jan 2021 00:00:00 +0000

Summary

If the Node.js agent is configured to exclude the request.uri attribute, it will still capture the URI in transaction traces. This can be problematic for certain customers in environments where sensitive information is included in the URI.

Release date:

August 20, 2020

Vulnerability identifier:

NR20-02

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Remediated version

Node.js agent

< 6.12.1

6.12.1

Vulnerability information [#vuln-info]

Even when users configure the Node.js agent to exclude the request.uri attribute, the agent will still capture the URI in transaction traces. This allows authenticated account users to view the URI anywhere transaction trace details can be viewed via New Relic One or queries. This includes (but is not limited to) the

Transaction traces

section of the

Transactions

page, the

Transaction trace details

, and the query builder in the UI.

Mitigating factors [#factors]

This will only affect Node.js agents configured to exclude the request.uri attribute.

Workarounds

Update to the latest New Relic Node.js agent.

Report security vulnerabilities to New Relic [#report]

Security Bulletin NR21-01

Mon, 22 Mar 2021 00:00:00 +0000

Summary

A security update to the browser agent will detect file:// URI schemes and stop any further execution and data collection if found.

Release date:

March 9th, 2021

Vulnerability identifier:

NR21-01

Priority:

Medium

Affected software [#affected]

The following New Relic agent versions are affected:

Name

Affected version

Remediated version

Browser agent

< v1205

v1208

Vulnerability information [#vuln-info]

Browsers can render local files on a host machine by using the file:// URI scheme outlined in RFC 8089. During the agent's harvest cycle , this file:// URI will be recorded as the pageURL datapoint. This may result in the collection of potentially sensitive data included in the local file path, such as directory path for the saved webpage and any name or company information in the directory path. More information regarding the file:// URI can be found in the RFC 8089

Mitigating factors [#factors]

A person must both download a webpage with the browser agent configured and open the file in a browser. HTML files loaded without the file:// URI scheme are not affected.

Workarounds

Update to the latest
agent.

Report security vulnerabilities to New Relic [#report]

Apache Log4j Critical Vulnerability CVE-2021-44228 - Java

Fri, 10 Dec 2021 00:00:00 +0000

Versions affected:

All agent versions between (a) 4.12.0 and 6.5.1; and (b) 7.0.0 and 7.4.1

Fix versions:

6.5.2, 6.5.3, 6.5.4, 7.4.2, 7.4.3 and 7.5.0

Vulnerability identifier:

NR21-03

We have determined that the new vulnerability identified (CVE-2021-44832) does NOT affect New Relic's Java agent, unless an additional attack vector would allow write permissions to the host system. Nonetheless, newer versions of the New Relic Java agent will use the latest Apache versions of log4j (currently versions 2.17.1 (Java 8) and 2.12.4 (Java 7), which patches CVE-2021-44832).

We have also determined that New Relic's Java agent is NOT vulnerable to either CVE-2021-45046 or CVE-2021-45105. This is because the agent's use of log4j sits behind a wrapper interface that does not use or support Thread Context Map input data, a required aspect of the vulnerability. However, we recommend updating to at least the 6.5.2 or 7.4.2 release to ensure comprehensive protection against CVE-2021-44228.

As new versions of log4j become available, we will continue to release new versions of the agent.

New Relic Java agent version

Apache log4j version

6.5.1

2.15.0

6.5.2

2.12.2

6.5.3

2.12.3

6.5.4

2.12.4

7.4.1

2.15.0

7.4.2

2.16.0

7.4.3

2.17.0

7.5.0+

2.17.1

Summary

New Relic has released new versions of the Java agent to address critical vulnerabilities in the open source log4j framework that could allow a malicious actor to exfiltrate data or execute arbitrary code using log messages or log message parameters.

New Relic will update this Security Bulletin and our customer guidance as new information becomes available.

Action items [#action]

To remediate CVE 2021-44228 in the New Relic Java agent, we recommend customers upgrade to agent release 6.5.2 or higher (requires Java 7 or higher) or 7.4.2 or higher (requires Java 8 or higher) as soon as possible.

If you have already upgraded to agent versions 6.5.2 or 7.4.2, you are protected against CVE 2021-44228 and do not have to upgrade again at this time. We have determined that New Relic's Java agent is NOT susceptible to either CVE-2021-45046 or CVE-2021-45105, as the agents use of log4j sits behind a wrapper interface that does not use or support Thread Context Map input data, a required aspect of the vulnerability. We recommend updating to at least the 6.5.2 or 7.4.2 release to ensure comprehensive protection against CVE-2021-44228.

If you are on a version of the agent earlier than 6.5.2 or 7.4.2, or cannot upgrade your agent version, we strongly recommend you disable agent logging.

How to disable the Java agent logging [#disable]

You can set your Java agent logging level to OFF to remediate CVE-2021-44228. To do this, use any of the following options:

Modify your local agent configuration file (search for the log_level parameter) (no restart is required)
Define the newrelic.config.log_level=OFF system property (restart required)
Set the NEW_RELIC_LOG_LEVEL=OFF environment variable (restart required)

You can verify that agent logging has been disabled by checking the agent log file. You should not see any new messages being written.

Disabling the Java agent logging does not affect the functionality of the agent, and there will be no degradation in observability.

Note:

This workaround is recommended only as a temporary solution until you can update your agent version.

We will share more information, and additional steps for remediation, if the situation changes.

If you use log4j directly in your applications, be sure to carefully review the Apache Log4j Security Vulnerabilities. This page provides remediation details for you to consider.

Containerized private minions [#CPM]

The above step will remediate your New Relic Java agent only. You may also need to update your New Relic Containerized Private Minion. Please refer to NR21-04 for more information.

Technical vulnerability information [#technical-info]

Frequently asked questions [#faq]

Please implement the recommended workaround in this bulletin.

Agent version information is displayed within the

Environment

page within your New Relic One dashboard. See our docs page for more information.

Most of our customers are using agent versions 6.x or 7.x and we encourage customers to use newer versions of our agent to ensure they have the best experience. If you are not able to upgrade your agent version, please implement the workaround outlined above.

If you have already upgraded to agent versions 6.5.1 or 7.4.1, we recommend also disabling agent logging, as the fix for CVE-2021-44228 was incomplete in log4j v2.15.0. We recommend updating to at least the Java agent 6.5.2 or 7.4.2 release to ensure comprehensive protection against this critical vulnerability. While we have released a newer Java agent with log4j 2.17.1 (Java 8) and 2.12.4 (Java 7), we have determined that updating to 6.5.3+ or 7.4.3+ is not critical as New Relic's Java agent is not susceptible to either CVE-2021-45046 or CVE-2021-45105.

Publication history [#pub-history]

March 3, 2022: NR21-03 Revision:
- Updated references to Java agent versions 6.5.4 & 7.5.0
December 29, 2021: NR21-03 Revision:
- Updated to reflect agent findings on CVE-2021-44832
December 22, 2021: NR21-03 Major Revision:
- New fix versions 6.5.3 and 7.4.3 available to address CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105.
- Addition of exploitability risk assessments for each vulnerability, to aid customers in making remediation decisions.
- Addition of content regarding lack of functionality impact for customers that disable agent logging.
December 17, 2021: NR21-03 Revision:
- Change in severity and technical description of CVE-2021-45046
December 16, 2021: NR21-03 Major Revision:
- New fix version 6.5.2 available to address both CVE-2021-44228 and CVE-2021-45046.
- Change in guidance regarding sufficiency of log4j version 2.15.0 to protect against exploitation of CVE-2021-44228.
- Change in recommended workaround.
- Update of NIST technical description of CVE-2021-44228.
December 14, 2021: NR21-03 Major Revision:
- New fix version 7.4.2 available to address both CVE-2021-44228 and CVE-2021-45046.
- Updated to include an additional workaround option.
- Updated to provide clarity between New Relic Java agent updates and the best practices customers should take to secure their applications.
- Added technical vulnerability descriptions and CVSS scores from the National Institute of Standards and Technology (NIST).
December 13, 2021: NR21-03 updated to include more explicit workaround guidance and FAQs
December 10, 2021: NR21-03 published

Report security vulnerabilities to New Relic [#report]

Containerized Private Minion Removes Log4j Version 1.2.17 subdependency

Fri, 14 Jan 2022 00:00:00 +0000

Versions Affected:

3.0.59 and earlier

Fixed In:

3.0.60

Vulnerability Identifier:

NR22-01

Priority:

High

Summary [#summary]

New Relic released Containerized Private Minion (CPM) version 3.0.60 to specifically remove subdependencies on log4j version 1.2.17.

New Relic has determined that log4j version 1.2.17 was included in subdependencies of our build package for Containerized Private Minions prior to version 3.0.60. Log4j version 1.x has outstanding high and critical CVEs of CVE-2021-4104 and CVE-2019-17571 and no longer receives support from Apache Foundation to address these issues.

Action Items [#action]

We strongly recommend customers upgrade all their Containerized Private Minions to version 3.0.60 or later as soon as possible. This version has fully excluded all use of log4j version 1.x from dependencies. You may update your CPM through Helm Charts version 1.0.48.

This step will help remediate the log4j vulnerability in your New Relic Containerized Private Minion (CPM) only. For additional security guidance regarding log4j in other New Relic products, please review New Relic's Security Bulletins on our documentation page.

Customers using log4j directly in their applications should carefully review the Apache Log4j Security Vulnerabilities page for remediation details that should be considered.

Technical Links [#technical]

Frequently Asked Questions [#faq]

I've updated to Containerized Private Minion (CPM) version 3.0.58 already, do I need to update to version 3.0.60?

Yes, New Relic strongly recommends updating at this time to address critical vulnerabilities in log4j subdependencies identified in the Containerized Private Minion build package. Apache Foundation has issued a recommendation to deprecate all use of log4j version 1.x due to the project being out of support and having outstanding vulnerabilities. CPM 3.0.60 and later versions are the only CPM versions available without any use of log4j version 1.x.

Publication History [#history]

January 13, 2022 - NR22-01 Published

Apache Log4j Critical Vulnerability CVE-2021-44228 - CPM

Tue, 14 Dec 2021 00:00:00 +0000

Summary

New Relic released Containerized Private Minion (CPM) version 3.0.58 on 2021-12-21 to address critical vulnerabilities CVE-2021-44228,CVE-2021-45046, and CVE-2021-45105 in the open source Apache Log4j framework. A malicious actor may be able to execute arbitrary code using log messages or log message parameters.

New Relic also released Helm Charts version 1.0.46 on 2021-12-21 to address these vulnerabilities. Helm Charts version 1.0.46 contains the CPM version 3.0.58.

New Relic will update this Security Bulletin and our customer guidance as new information becomes available.

Vulnerability identifier:

NR21-04

Priority:

Critical

Affected software [#affected]

Versions affected: All supported containerized private minion (CPM) versions prior to 3.0.58

Fixed version: 3.0.58, also available through Helm Charts version 1.0.46

New Relic Containerized Private Minion (CPM) version

Apache log4j version

3.0.55

2.15.0

3.0.57

2.16.0

3.0.58

2.17.0

If you use Helm Charts to update your CPM configurations, you will want to implement New Relic Helm Charts version 1.0.46. This will update your CPM to version 3.0.58.

Action items [#action]

To remediate CVE 2021-44228, CVE 2021-45046, and CVE 2021-45105 in the New Relic Containerized Private Minion, we recommend customers upgrade to version 3.0.58 as soon as possible. This version has been updated to use the remediated 2.17.0 version of the Apache Log4j framework. You may update your CPM through Helm Charts version 1.0.46.

This step will remediate your New Relic Containerized Private Minion (CPM) only. You may also need to update your New Relic Java agent. Please refer to NR21-03 for more information.

Customers using log4j directly in their applications should carefully review the Apache Log4j Security Vulnerabilities page for remediation details that should be considered.

Vulnerability information [#vuln-info]

A high level vulnerability was publicly disclosed for the log4j framework on 2021-12-09. An attacker is able to execute arbitrary code using log messages or log message parameters.

Frequently asked questions [#faq]

Apache Foundation has disclosed additional vulnerabilities in log4j framework (CVE-2021-45046 and CVE-2021-45105) and advise that log4j v2.16.0 is not sufficient protection against exploitation. CPM 3.0.58 and later versions are the only CPM versions available with log4j 2.17.0.

Publication history [#history]

December 22, 2021: NR21-04 Major Revision:
- New fix version 3.0.58 available to address CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105.
- Addition of Helm Charts version 1.0.46 that contains the CPM 3.0.58 update.
December 17, 2021: NR21-04 Revision: Change in severity and technical description of CVE-2021-45046.
December 16, 2021: NR21-04 Major Revision:
- Change in guidance regarding sufficiency of CPM 3.0.55 containing log4j version 2.15.0 to protect against exploitation of CVE-2021-44228.
- Addition of Helm Charts version 1.0.45 that contains the CPM 3.0.57 update.
- Update of NIST technical description of CVE-2021-44228.
December 14, 2021: NR21-04 Major Revision:
- New fix version 3.0.57 released to address both CVE-2021-44228 and CVE-2021-45046.
- Updated to provide better clarity between New Relic CPM updates and the best practices customers should take to secure their applications.
- Added FAQ section.
December 13, 2021: NR21-04 published

Report security vulnerabilities to New Relic [#report]

NR24-01 - Fluent Bit

Sat, 08 Jun 2024 00:00:00 +0000

Vulnerability Identifier:

NR24-01

Priority:

High

Summary

New Relic advises all customers using log forwarding instrumentation to update the following solutions:

Linux Infrastructure Agent AND Fluent Bit
Kubernetes Plugin
Fluent Bit Output Plugin

New Relic has released new versions of these services to eliminate a recently announced vulnerable version of Fluent Bit. Each identified service has been updated to use Fluent Bit version 3.0.4, which was released to remediate the identified vulnerability.

Customers who are using the Infrastructure Agent but have disabled log forwarding are not impacted.

Action required

New Relic is recommending that customers who use the log forwarding instrumentation (as identified below) immediately take the following Actions:

Solution

Action Required

Windows Infrastructure Agent

On Windows, the embedded version of Fluent Bit within the Windows Infrastructure Agent has been determined to not be impacted by CVE-2024-4323.

Linux Infrastructure Agent

Upgrade the Infrastructure Agent to version 1.52.3 or later, AND update Fluent Bit to version 3.0.4 or later

Kubernetes Plugin

Upgrade using either newrelic-logging-1.22.0 or nri-bundle-5.0.80

Fluent Bit Output Plugin

Update to version 2.0.0

New Relic has provided the following resources to assist with these updates:

New Relic has not identified any workarounds at this time.

Frequently Asked Questions

I am using the Infrastructure Agent but have disabled log forwarding. Am I impacted?

No, if log forwarding is disabled, the Infrastructure Agent will not run Fluent Bit and will not be impacted. However, New Relic recommends that you upgrade the agent regularly and check for updates at a minimum of every 3 months to ensure you are using a current version.

Additionally, New Relic recommends that all customers identify any other uses of Fluent Bit in their environments and update them to at least version 3.0.4.
Once I update to the latest versions of the listed log forwarding services, do I have to do anything else?

Yes, but only if you are running Infrastructure Agents on Linux hosts. If you are running the Linux Infrastructure Agent, you will also need to update Fluent Bit within your environment to version 3.0.4 or later.

There are no further configuration changes required to the Kubernetes Plugin or the Fluent Bit Output Plugin after updating to the most recent versions, although New Relic recommends that you periodically check your set configurations to make sure they match your desired settings.

Supporting Release Notes

Infrastructure Agent Release Notes

Logs Release Notes

Kubernetes Integration Release Notes

Fluent Bit Output Plugin Release Notes

Technical vulnerability information

CVE-2024-4323

Fluent Bit's Statement on CVE-2024-4323

Research Synopsis of CVE-2024-4323

Publication History

June 7, 2024 - NR24-01 Published

NR24-02 - OpenSSH in New Relic Salesforce Exporter

Thu, 18 Jul 2024 00:00:00 +0000

Vulnerability Identifier:

NR24-02

Priority:

High

Summary

New Relic advises all customers using the New Relic Salesforce Exporter to update to version 2.2.0, which New Relic has released to eliminate a recently announced vulnerable version of OpenSSH.

Action required

New Relic is recommending that customers who use the New Relic Salesforce Exporter immediately update to version 2.2.0.

New Relic has provided the following resources to assist with these updates:

If customers are unable to upgrade their New Relic Salesforce Exporter, limit SSH access through network-based controls to minimize the attack risks.

Supporting Release Notes

Salesforce Exporter Release Notes

Technical vulnerability information

CVE-2024-6387

Publication History

July 18, 2024 - NR24-02 Published

Security Bulletin NR23-01 — Security Advisory

Wed, 22 Nov 2023 00:00:00 +0000

Investigation conclusion: January 31, 2024 [#conclusion]

This is our final update to this security bulletin describing our November 2023 security incident involving unauthorized access to our staging environment. New Relic, leading cyber experts, and forensic firms conducted an extensive investigation into the incident, and together have provided updates to this security bulletin as information became available. The investigation has concluded and we are sharing additional information about our findings.

Background [#background-details]

In November 2023, New Relic became aware of unauthorized access to our staging environment—an internal environment that provides visibility into, and information relating to, our customers’ use and operation of our services for troubleshooting purposes (“Staging Environment”). The Staging Environment maintains New Relic’s own observability data, including logs, events, traces and other diagnostic files, ensuring that we have visibility in the event of a failure in our customer facing Production environment. Notably, telemetry and application data sent to New Relic by our customers in their use of the New Relic platform does not reside in our Staging Environment.

Upon learning of the unauthorized access to the Staging Environment, we took immediate action to assess the integrity of internal applications, systems, and infrastructure. We activated our incident response plan and engaged several third-party cybersecurity experts to conduct a thorough investigation into the impact to our customers and our business.

During the course of the investigation, we learned the unauthorized actor used stolen credentials in connection with a single New Relic employee account to gain access to the Staging Environment. The unauthorized access occurred shortly before the completion of a planned migration of the remainder of our employees to our enhanced User management model for added security.

New Relic immediately revoked access to the compromised employee account. We also analyzed the potential impact to customers by searching the Staging Environment for passwords, API keys, user identifiers, including usernames and other customer data. Our investigation also confirmed there was no lateral movement from the Staging Environment to any customer accounts in separate environments or to New Relic’s Production environment.

Additional steps to harden environment [#additional-hardening]

We took additional steps to remediate the impact of the incident, including by redacting secrets out of our logging rules, and took steps to further harden our systems, such as implementing additional layers of technical controls, enhancing our network access controls, and accelerating the migration of our remaining employee users to our enhanced User management model. These additional steps were taken and completed.

Incident findings [#incident-findings]

Our investigation into the Staging Environment incident is complete and has revealed the following:

The unauthorized actor utilized a single New Relic employee account to gain access to New Relic’s Staging Environment.
All activity by the unauthorized actor within New Relic’s Staging Environment has been comprehensively identified and reviewed by New Relic and our industry-leading forensic firms.
Between October 24 and November 15, 2023, the unauthorized actor executed specific search queries and exfiltrated these query results from the Staging Environment.
The last observed unauthorized activity in the Staging Environment was on November 16, 2023. There is no indication of persistent access by the unauthorized actor in New Relic’s Staging Environment.
A very small percentage of our customers were impacted by the search queries executed by the unauthorized actor.
There is no indication of lateral movement from our Staging Environment to any customers’ New Relic accounts in the separate production environment or to New Relic’s production infrastructure.

Tactics, techniques, and procedures (TTPs) [#ttps]

In support of our industry and community as a whole, we are sharing the tactics, techniques, and procedures (TTPs) utilized by this unauthorized actor so that our community can leverage this information to identify potential risk to their environments. These TTPs were discovered and confirmed through the investigation performed by New Relic in partnership with forensic and cybersecurity experts.

The unauthorized actor used the following tactics, techniques, and procedures (TTPs):

Credential stuffing;
Use of Protonmail (proton.me) for communication;
Use of VPN services including NordVPN for access to public services; and
Programmatic Data Extraction using APIs.

Eradication and remediation efforts [#eradication-efforts]

We understand that the best defense starts right here at New Relic. New Relic took a number of actions to eradicate the unauthorized actor’s access during the incident, including:

Revoking access to the compromised employee account immediately;
Blocking indicators of compromise associated with the attack;
Further hardening access controls and credential theft defenses, leveraging an industry-leading security toolset; increasing our capacity to monitor security across our entire enterprise; and
Providing additional cyber education and awareness to our employees.

Customer recommendations [#customer-recommendations]

We have completed our proactive outreach to customers whose accounts were impacted from this incident in order to help them understand the impact and to communicate suggested remediation steps. If you have not received specific instructions regarding your systems, there is no action you need to take. Customers should review our Security bulletins and Security guides for best practices. There are no additional measures you need to take beyond what has already been communicated with you.

We regret any inconvenience this incident caused for our customers. Our CEO, CTO, and CISO are aligned on the future state of security at New Relic. They share the same commitment to making broad improvements to our security posture, and specifically to preventing the same type of incident from occurring in the future. We have talked to many customers, including those not impacted directly by this incident, and have shared both our commitment to do better and the significant enhancements we have made to our security posture. We will continue making long term investments to earn back the trust of our customers. We deeply appreciate the understanding and support that customers have shown.To all of our customers—we look forward to our continued work together.

Previous updates [#previous-updates]

Following considerable progress in our investigation, we are now in a more informed position to share with our customers additional details about the ongoing investigation and what we have learned.

What happened—initial attack on New Relic staging environment [#what-happened]

Two weeks ago, New Relic became aware of unauthorized access to our staging environment, an internal environment that provides visibility into how our customers are using New Relic and certain logs. Telemetry and application data sent to New Relic by our customers in their use of the New Relic platform does not reside in our staging environment.

We immediately launched an investigation and discovered that an unauthorized actor used stolen credentials and social engineering in connection with a New Relic employee account. The unauthorized actor used the stolen credentials to gain access to our staging environment, where they were able to view certain data pertaining to our customers’ use of New Relic.

Customers confirmed to have been impacted by this incident have been notified with recommended next steps.

There is no indication of lateral movement from our staging environment to any customers’ New Relic accounts in the separate production environment or to New Relic’s production infrastructure.

As a result of the steps we have taken, we can also confirm that the unauthorized access to our staging environment is contained, and we see no further signs of unauthorized access or activity in our staging environment. We will continue to proactively reach out to our customers if we identify further information that may be relevant to them over the course of our ongoing investigation.

Steps we have taken [#steps-taken]

Since learning of this incident, we took immediate action to assess the integrity of internal applications, systems, and infrastructure. We activated our incident response plan and engaged several third-party cybersecurity experts to conduct a thorough investigation into the impact to our customers and our business. Our continuity of operations and ability to serve our customers were not disrupted by this incident and continue as normal.

Our security team revoked access to the compromised employee account immediately. We have taken steps to implement additional layers of technical controls, enhance network access controls, and eliminate the attack method used to access New Relic’s staging environment. Leading cyber experts and forensics firms continue to be engaged to aid in our ongoing investigation.

We have taken this opportunity to further harden access controls and credential theft defenses, leveraging an industry-leading security toolset. We have also increased capacity to monitor security across our entire enterprise, all in order to ensure comprehensive visibility into our security posture.

Additional information concerning potential access to customer accounts discovered during our investigation [#additional-information]

Over the course of our investigation, we observed similar indicators of compromise (IOCs) accessing a small number of customers’ New Relic accounts. Out of an abundance of caution, we proactively responded by rotating passwords and removing user API keys for the suspected compromised user accounts. Based on our investigation to date,

there is no evidence to suggest the identified log-in credentials were acquired as a result of the attack on New Relic’s staging environment.

It appears the credentials were harvested in recent large-scale social engineering and credential compromise attacks, which may have put these New Relic user accounts at risk. In cases where we identify this suspected access, we are proactively reaching out to these customers.

Steps you can take to prevent credential-based compromises [#steps-you-can-take]

Although our investigation is ongoing, we aim to take a security forward posture by sharing our learnings to support the broader New Relic community. Our goal is to assist our customers in enhancing their own security posture and provide assistance where applicable to any investigations that may be necessary.

New Relic offers automatic controls over how users are added to New Relic, how they're managed, and how they log in. New Relic also makes available SAML, SSO, and SCIM provisioning, which is available here. Additionally, customers configured with SAML, SSO, and SCIM, are strongly encouraged to enable MFA. If you are not taking advantage of these features, avoid reusing passwords and ensure that you regularly rotate your passwords.

We also recommend that you remain vigilant and monitor your account for suspicious activity. For example, as an additional security measure, you should regularly audit the changes made in your New Relic environment - particularly when you suspect unusual activity. New Relic makes such functionality readily available for every customer. Customers should also use automatically generated meta-events, such as NrAuditEvent and NrdbQuery to understand what actions your users are taking and which telemetry they are querying. Additionally, we encourage you to review our Security bulletins and Security guides for best practices.

We understand that you may have additional questions as a result of this notice. Please open a support case under security or contact our Customer Support team at supportforum@newrelic.com if you have further questions. They will be able to assist you or connect you with the appropriate team.

As our investigation continues, we will continue to share information with appropriate parties and the larger New Relic customer community.

Trust and transparency are paramount in our business, and we know the security of our systems is an important part of earning and keeping your trust. We apologize to our customers that this happened, and we deeply appreciate the partnership that we have forged with you. We will continue to make security investments in our infrastructure and product offering to maintain a strong security posture for our New Relic community.

Release date:

November 22, 2023

Vulnerability identifier:

NR23-01

We value our New Relic community and want to make our customers aware of a recent cybersecurity incident that we are working diligently to investigate with the support of third-party cybersecurity experts.

Customers will be directly contacted if there are any specific actions required of you.

To be clear, if you do not hear from us, there is no action you need to take at this time.

As always, we recommend that you remain vigilant and monitor your account for suspicious activity. Additionally, we encourage you to review Security Guides for best practices as well as our Security Bulletins for updates.

We will continue to provide relevant updates as we have more information to share.

NR25-01- Fluent Bit Plugins (CVE-2024-50608 & CVE-2024-50609)

Thu, 27 Feb 2025 00:00:00 +0000

Vulnerability Identifier:

NR25-01

Priority:

High

Summary

By default New Relic does not include or enable the specific plugins that are affected by security vulnerabilities identified in certain versions of Fluent Bit. The specific plugins are:

OpenTelemetry input plugin - Affected by CVE-2024-50608
Prometheus Remote Write input plugin - Affected by CVE-2024-50609

However, to support customers that have enabled these optional plugins, we recommend customers to upgrade to the latest available versions of these package:

Infrastructure Agent - Windows
Infrastructure Agent - Linux
Kubernetes Plugin
New Relic Fluent Bit Output Plugin Docker Image

Action required

New Relic strongly advises our customers who are using the aforementioned log forwarding instrumentation to take immediate action as follows. If you are unable to upgrade to Fluent Bit v3.2.7, we recommend disabling the affected plugins specified above.

Solution

Action Required

Infrastructure agent - Windows

Upgrade the Infrastracture agent to version 1.62.0 or later

Infrastructure agent - Linux

Upgrade the Infrastracture agent to version 1.62.0 or later AND update Fluent Bit to version 3.2.7 or later

Kubernetes Plugin

Upgrade using either newrelic-logging-1.26.1 or nri-bundle-5.0.115

New Relic Fluent Bit Output Plugin Docker Image

Update to version 2.3.0

New Relic has provided the following resources to assist with these updates:

Frequently Asked Questions

How can I find out if I’m using the vulnerable plugins?

New Relic default Fluent Bit configuration does not include the vulnerable plugins by default. If you have amended your Fluent bit configuration post-installation and included the OpenTelemetry input plugin and/or Prometheus Remote Write input, any version of Fluent Bit installed in your environment is vulnerable. Follow the instructions to upgrade all your log forwarding instrumentation immediately.
I am using the Infrastructure Agent but have disabled log forwarding. Am I impacted?

If you previously used New Relic log forwarding instrumentation (listed above), and used the affected plugins, you might still be impacted. New Relic recommends that you upgrade your agents, or at minimum disable the affected plugins.

Additionally, New Relic recommends that all customers identify any other uses of Fluent Bit in their environments and update them to at least version 3.2.7.
Once I update to the latest versions of the listed log forwarding services, do I have to do anything else?

Yes, but only if you are running Infrastracture agents on Linux hosts. If you are running the Linux Infrastructure agent, you will also need to update Fluent Bit within your environment to a version 3.2.7 or later.
How can I find out which Fluent Bit version I’m using?

If you previously used New Relic log forwarding instrumentation (listed above), and used the affected plugins, you might still be impacted. New Relic recommends that you upgrade your agents, or at minimum disable the affected plugins.

Additionally, New Relic recommends that all customers identify any other uses of Fluent Bit in their environments and update them to at least version 3.2.7.

Agent

Steps

Infra agent and standalone Fluent bit

For your Infrastructure agents, navigate to the Infrastructure Inventory UI and search for Fluent Bit.

Then, Check which Fluent Bit version is installed for a particular host.

Kubernetes

For New Relic Logging Helm chart version 1.25.0 or higher, Navigate to the Installed tab and search for Fluent bit in the entities field
Otherwise, run the following NRQL query: FROM K8sContainerSample select latest(containerImage) Where podName like '%newrelic-logging%' FACET clusterName

Then, check which Fluent Bit version was installed with the output plugin.

Supporting Release Notes

Fluent Bit release notes

Infrastructure Release Notes

Fluent Bit Output Plugin Release Notes

Technical vulnerability information

CVE-2024-50608

CVE-2024-50609

Fluent Bit 3.2.7 Release Notes

Publication History

March 1, 2025 - NR25-01 Published

NR25-02- Fluent Bit Plugins (CVE-2025-12969, CVE-2025-12970, CVE-2025-12972, CVE-2025-12977, CVE-2025-12978)

Thu, 11 Dec 2025 00:00:00 +0000

Vulnerability Identifier:

NR25-02

Priority:

High

Summary

By default, New Relic does not include or enable the specific plugins that are affected by the security vulnerabilities identified in certain versions of Fluent Bit. The specific plugins and their associated vulnerabilities are:

Forward input plugin (in_forward) - Affected by CVE-2025-12969
Docker input plugin (in_docker) - Affected by CVE-2025-12970
File output plugin (out_file) - Affected by CVE-2025-12972
HTTP, Splunk, and Elasticsearch input plugins (in_http, in_splunk, in_elasticsearch) - Affected by CVE-2025-12978 & CVE-2025-12977

However, to support customers that have enabled these optional plugins, we recommend customers to upgrade to the latest available versions of these packages which bundle the patched version of Fluent Bit (v4.0.13, v4.1.1, v4.2.0 or higher):

Infrastructure Agent - Windows
Infrastructure Agent - Linux
Kubernetes Plugin
New Relic Fluent Bit Output Plugin Docker Image

Action required

New Relic strongly advises our customers who are using the aforementioned log forwarding instrumentation to take immediate action as follows. If you are unable to upgrade to the latest agent versions containing Fluent Bit v4.0.13, v4.1.1, or v4.2.0, we recommend disabling the affected plugins specified above to mitigate the risk.

Solution

Action Required

Infrastructure agent - Windows

Upgrade the Infrastructure agent to version v1.71.2 or later

Infrastructure agent - Linux

Upgrade the Infrastructure agent to version v1.71.2 or later AND update Fluent Bit to version v4.2.0 or later

Kubernetes plugin

Upgrade using either newrelic-logging-1.33.0 or nri-bundle-6.0.28

New Relic Fluent Bit Output Plugin Docker Image

Update to version 3.2.1

New Relic has provided the following resources to assist with these updates:

Frequently Asked Questions

How can I find out if I'm using the vulnerable plugins?
- Check your Fluent Bit configuration file(s) for use of the tag_key parameter in input plugins e.g. HTTP, Splunk, or Elasticsearch which may leave your installation vulnerable to the attacks described in CVE-2025-12978 and CVE-2025-12977
- Check your Fluent Bit configuration file(s) for use of the File output plugin, especially where the File configuration parameter has not been set, which may leave your installation vulnerable to the attacks described in CVE-2025-12972
- Check your Fluent Bit configuration file(s) for use of the Docker metrics input plugin, which may leave your installation vulnerable to the attacks described in CVE-2025-12970
- Check your Fluent Bit configuration file(s) for use of the Forward input plugin, which may leave your installation vulnerable to the attacks described in CVE-2025-12969
I am using the Infrastructure Agent but have disabled log forwarding. Am I impacted?

If you previously used New Relic log forwarding instrumentation (listed above), and used the affected plugins, you might still be impacted. New Relic recommends that you upgrade your agents, or at minimum disable the affected plugins. Additionally, New Relic recommends that all customers identify any other uses of Fluent Bit in their environments and update them to at least version v4.0.13, v4.1.1, or v4.2.0.
How can I find out which Fluent Bit version I'm using?

Agent

Steps

Infrastructure agent and standalone Fluent Bit

For your Infrastructure agents, navigate to the Infrastructure Inventory UI and search for Fluent Bit. Then, check the Fluent Bit version installed on a given host

Kubernetes

For New Relic Logging Helm chart version 1.25.0 or higher, Navigate to the Installed tab and search for Fluent bit in the entities field
Otherwise, run the following NRQL query: FROM K8sContainerSample select latest(containerImage) Where podName like '%newrelic-logging%' FACET clusterName

Then, check which Fluent Bit version was installed with the output plugin.

What should I do if there are no patched artifacts available for my OS?
- There is no patched FluentBit upstream package available for Ubuntu 16, 18, and 20. If you are running on any of these distributions, we recommend you remove the affected input plugins to protect from vulnerabilities.
- We are working to provide patched packages for SLES 12.5 and 15.4 as soon as possible. Until we roll out the updated packages for these distributions, we recommend removing the affected plugins to protect from vulnerabilities.
- We are working to provide a patched package for Debian 13 as soon as possible. Until we roll out a patched package for this distribution, we recommend removing the affected plugins to protect from vulnerabilities.

Supporting Release Notes

Fluent Bit release notes

Infrastructure Release Notes

Fluent Bit Output Plugin Release Notes

Technical vulnerability information

Publication History

December 11, 2025 - NR25-02 Published

Update the .NET agent if you use Microsoft Extensions Logging with log forwarding

Sat, 03 Dec 2022 00:00:00 +0000

Summary [#summary]

New Relic is recommending that customers who deploy the .NET agent in a configuration employing Microsoft Extensions Logging (MEL) should update to version 10.1.0 or later to address an issue where New Relic .NET agents (v9.7.0 to 10.0.0) would forward any level of MEL logging level, regardless of configuration.

This guidance applies to users of the .NET agent versions 9.7.0 through 10.0.0 that use the MEL logging framework. .NET agents that use Log4net, Serilog, and NLog logging frameworks are not affected.

Affected software [#affected-software]

.NET agent version

Logging framework

Required conditions

Affected/not affected

.NET agent 9.7.0 through 10.0.0

Microsoft Extensions Logging (MEL)

Log forwarding enabled and log level set

Affected

.NET agent all versions

Log4Net, Serilog, or NLog logging

Not affected

.NET agent 9.7.0

Microsoft Extensions Logging (MEL)

Default configuration (Log forwarding not enabled)

Not affected

.NET agent 9.8.0 through 10.0.0

Microsoft Extensions Logging (MEL)

Log forwarding disabled

Not affected

.NET agent 9.7.0 through 10.0.0

Microsoft Extensions Logging (MEL)

Configured to forward all Microsoft Extension Logging levels

Not affected

.NET agent before 9.7.0

n/a

Not affected

.NET agent 10.1.0 and later

Microsoft Extensions Logging (MEL)

Not affected

.NET agent all versions

n/a

Deployed in Linux

Not affected

Fixed in:

New Relic .NET agent versions 10.1.0 and later

Recommended action: [#recommended]

Customers who use Microsoft Extension Logging should upgrade to version 10.1.0 or later
Technical Links
: Updating the .NET agent
Workarounds
: Affected customers who cannot update their .NET agents to 10.1.0 or later at this time can disable log forwarding.

Technical details: [#technical-details]

Version 10.1.0 remediates an error in the timing of the instrumentation point for Microsoft Extensions Logging to correctly send MEL data after the built-in log level filtering occurs.

Timeline details [#timeline]

This issue was introduced when New Relic added support for the log forwarding feature with Microsoft Extensions Logging (MEL) framework in .NET Core applications in .NET agent v 9.7.0 (April 4, 2022) and in .NET Framework applications in v 10.0.0 (July 19, 2022). In version 9.7.0, the log forwarding feature was disabled by default, so customers using version 9.7.0.0 may only be affected by this issue if they have manually configured log forwarding.

In version 9.8.0 (May 5th, 2022), the log forwarding feature was enabled by default.

The issue was fixed with the release of .NET agent version 10.1.0, released on September 12, 2022.

Frequently asked questions [#faq]

What is a Security Guidance document? New Relic has issued this Security Guidance document to notify customers of the need to update their software to address a software bug that, while it cannot be exploited by a third party to gain access to customer data, still has actionable security or privacy recommendations for customers.
Is it possible for a third-party to exploit this issue to access log data that is forwarded to New Relic? No, the issue does not allow for exposure of data to a third party. We use a comprehensive set of technical controls to support security for data we receive. For more information, see our documentation about data security and data encryption.
Once I deploy version 10.1.0 of the New Relic .NET agent, do I have to do anything else? No, there are no further configuration changes required after updating. We recommend that you check your set configurations to make sure that they match your desired settings.
I am using the .NET agent but not using Microsoft Extensions Logging for log forwarding. Am I impacted? No, this issue only impacts .NET applications using MEL for their logging. MEL logging was introduced in version 9.7.0 for .NET Core applications and 10.0.0 for .NET Framework applications.
I am using the .NET agent but have disabled the log forwarding feature. Am I impacted? No, this issue only impacts .NET applications using the log forwarding feature and the MEL framework.

Security for Heartbleed vulnerability

Thu, 08 Oct 2020 00:00:00 +0000

On April 7, 2014 the OpenSSL Project released an update to address a critical vulnerability known as Heartbleed (CVE-2014-0160). This vulnerability, which affects multiple sites across the Internet, could be remotely exploited to leak sensitive information.

Action by New Relic [#nr-action]

New Relic has reviewed all of our sites and applications, and we have determined that the majority of our sites, including

www.newrelic.com

rpm.newrelic.com

, and

insights.newrelic.com

are not vulnerable to this issue. New Relic did discover that the Documentation site (

docs.newrelic.com

) was vulnerable. This has now been patched, and the SSL certificate has been replaced.

Change your password [#password]

New Relic has no evidence that any customer data (including user names and passwords) was exposed. However, if you have any concerns about your account's protection, you should change your password.

This procedure is for users who sign in directly to APM and do not have partner accounts or SAML SSO enabled accounts:

Go to
rpm.newrelic.com > (user menu) > User preferences
.
Type your
Current password
.
Type your new
Password
(meeting minimum requirements), and then re-type the new password in
Password confirmation
.
Select
Save user preferences
.
Regenerate
your API key.

rpm.newrelic.com > (user menu) > User preferences:

Anyone can change their own New Relic user name, account email, password, and other settings.

SolarWinds Orion

Fri, 05 Feb 2021 00:00:00 +0000

We understand that our customers are evaluating the impact of the SolarWinds Security Advisory to their business. To address the immediate concern: New Relic is not a customer of the SolarWinds Orion product and therefore New Relic and customers using New Relic are not impacted by the compromised SolarWinds product.

New Relic and SolarWinds Orion [#statement]

New Relic Security is closely monitoring for updated information about the SolarWinds incident as it is released.

As a proactive measure, New Relic security has conducted a review of our processes related to code integrity and software delivery. New Relic will take appropriate steps to implement improvements where needed. New Relic will also continue to evaluate our systems for indicators related to the SolarWinds incident.

In accordance with our own vendor risk management program, New Relic has initiated communication with critical vendors to determine whether they use the SolarWinds product in any of the services they provide to us. Based on their response, New Relic will identify and take appropriate steps to mitigate the risk to our company and our customers.

The security and privacy of our customers is our top priority, and we are continuing to follow the SolarWinds situation closely. We encourage customers with questions to contact us at support.newrelic.com/.