New Relic is committed to the security of our customers and their data. We
believe that coordinated disclosure by security researchers and engaging with
the security community is an important means of achieving our security goals.
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 , as long as it falls in scope and is not one of the types of
vulnerabilities listed as out of scope below.
If you are a customer and have a password or account issue, please contact
New Relic support via https://support.newrelic.com
To get the most out of our program, you should familiarize yourself with New
Relic and our products. You can sign up for a free trial
__, install our agents within your servers or
applications, and read over our extensive documentation
You can also read our disclosed HackerOne
or see examples of issues previously identified within our agents on our
Security Bulletins __page.
Please submit your security issue to New Relic via our coordinated
disclosure program on HackerOne. Please
provide as much detail as you can (URLs, etc.) and the steps to reproduce the
issue. The more information you can provide, the easier it will be for us to
reproduce and confirm the report. We commit to responding to your report as
soon as possible!
Some New Relic assets are in scope for paid bounty rewards. The remainder
are eligible for HackerOne reputation. Please refer to the assets list at the
bottom of the page to see what is or is not eligible for a paid bounty reward.
Rewards are awarded based on the merit of reported vulnerabilities. Only the
first verified report will be eligible for a reward.
Coordinated Disclosure Policy
To encourage coordinated disclosure, New Relic does not intend to initiate
any legal action or law enforcement investigation against security researchers
as long as they adhere to the following guidelines:
- Researchers will report details of a discovered security issue to New Relic without making any information or details of the vulnerability public.
- Researchers will allow New Relic reasonable time to resolve the issue before publishing any information or details about the vulnerability or other making such information generally known. New Relic will follow the HackerOne disclosure guidelines, which commit to open communication, providing an initial response to the researcher within 30 days, and providing a disclosure timeline to the researcher to be mutually agreed upon.
- Researchers will provide as much detail as possible to New Relic via a secure means in order to help New Relic ’s security team and engineers reproduce the issue. If the report is not detailed enough to reproduce the issue, it will not be eligible for a reward.
- When duplicates occur, we award the first report that we can completely reproduce.
- Multiple reports related to the same root cause will be awarded one bounty.
- Paid bounty amounts below are the minimum we will pay per category. We aim to be fair; all reward amounts are at our discretion.
- Only access or modify data that belongs to you. To test, please sign up for a free trial __.
- Researchers will make all reasonable attempts in good faith to avoid destroying, stealing, modifying, damaging, violating or otherwise jeopardizing the privacy of any New Relic customer or New Relic data. This includes disrupting or degrading New Relic ’s products and service to its customers.
- Be aware that information submitted to a report is made visible to other researchers who have been added as collaborators from duplicate reports
- When submitting a duplicate report, adding researchers as collaborators is at New Relic 's discretion
The following are expressly prohibited (and void reward eligibility):
- Physical attacks against New Relic employees, offices, and data centers.
- Automated security testing against New Relic applications or servers; scanning tools such as
nmap or Burp Suite are perfectly acceptable for research, but we do not want reports generated by automated tools (we already run them in-house).
- Social engineering of New Relic employees, contractors, vendors, or service providers (e.g. phishing, vishing, smishing, et al.).
- Pursuing vulnerabilities which send unsolicited bulk messages (spam).
- Pursuing vulnerabilities through the compromise of a New Relic customer or employee account (e.g. do not attempt to gain access to another user’s account or data).
- Knowingly posting, transmitting, uploading, linking to, or sending any malware to New Relic or its employees.
- Mass account creation for testing against New Relic applications and services.
- "Brute force" testing to determine whether rate limiting is in place for particular APIs or pieces of functionality.
- Disclosing information to the public before the issue has been resolved.
Below are some examples of the types of vulnerabilities we're interested in
Critical severity bugs:
- Remote code execution (RCE) on New Relic backend services
- RCE on hosts via installed New Relic agents __
- RCE on host via Synthetics minion container escape
High severity bugs:
- Authentication bypass
- Cross account access
- SQL injection
- Stored cross-site scripting (XSS) that can affect other users
- Flaws that could be used to exploit 3rd-party integration services
- Unauthorized configuration changes to installed New Relic agents __
- Access to privileged functionality or data via Node sandbox escape to the Synthetics minion container
- Takeover of
Medium severity bugs:
- Cross-site scripting (XSS)
- Cross-site request forgery (CSRF/XSRF) of a non-idempotent (AKA state-changing) request
- Authorization flaws/Access Control Bypasses (e.g. being able to perform security-sensitive actions as a Restricted User)
- Clickjacking on authenticated pages with sensitive state changes
- Default New Relic agents __collecting and sending undocumented confidential data to New Relic
- Confidential data disclosure
Low severity bugs:
- Mixed content scripts (scripts loaded over HTTP on an HTTPS page)
- Open redirect (to a site other than localhost)
- Information disclosure
- Enumeration of data (Other than account or user ID)
- Host header spoofing
- Security issues resulting from New Relic agent __configuration
- License (insert) key available to Restricted User
Out of scope issues (not eligible for a reward):
- CSRF/XSRF on unauthenticated pages (Login Page) or logout
- Lack of rate limiting on a particular API or other 'load testing' types of issues
- Non-sensitive (ie. non-session) cookies missing the Secure or HttpOnly flags
- Denial-of-service vulnerabilities
- Stack traces
- Application or server error messages
- Use of out-of-date 3rd-party libraries without proof of exploitability
- Vulnerabilities in 3rd-party scripts used on New Relic websites
- Leaking information via the Referer header
- Missing X-Frame-Options, Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, or X-XSS-Protection HTTP headers
- SPF, DMARC or other email configuration related issues
- Password or account recovery policies, such as reset link expiration or password complexity
- HTTP 404 codes/pages or other HTTP non-200 codes/pages
- Version number/banner disclosure on public facing websites
- Disclosure of known public files or directories, (e.g. robots.txt)
- Lack of DNSSEC
- SSL configuration issues (cipher suites, SHA-1 certificates, BEAST/CRIME, lack of PFS)
- HTTP TRACE or OPTIONS methods enabled
- Clickjacking on pages without authentication and/or sensitive state changes
- Vulnerabilities only affecting end of life browsers or platforms
- Self-XSS and issues exploitable only through Self-XSS
- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality
- Content spoofing/text injection
- Information disclosure via
/status URLs (this is a known issue)
- Bugs requiring exceedingly unlikely user interaction
- Exploits that require physical access to a user's machine
- Vulnerabilities resulting from Synthetics private minions that have out-of-date or vulnerable packages
- Reports concerning agents with outdated packages with security vulnerabilities should be accompanied by an example showing how they'd be leveraged within the agent
- Attacks requiring a Man-in-the-Middle, with no other possible exploitation
- WordPress username enumeration
- Node sandbox escape to the Synthetics minion container (barring privileged access, see High above)
Thank you for helping keep New Relic and our users secure!