Please note this program does not provide monetary rewards for bug submissions, and it is for responsible disclosure purposes only.

Here at Meredith we are committed to ensuring the safety and security of our consumers. We value the input of individuals acting in good faith to help us maintain a high standard for the security and privacy for our users. If you believe you have discovered a potential security vulnerability with any of Meredith’s products or services, we welcome working with you to resolve the issue promptly and appreciate your help in disclosing the issue to us responsibly.

Assets in scope are only accessible from US IP addresses

Response Targets

Meredith will make a best effort to meet the following SLAs for hackers participating in our program:

| Type of Response | SLA in business days |

| ------------- | ------------- |

| First Response | 2 days |

| Time to Triage | 2 days |

| Time to Resolution | depends on severity and complexity |

We’ll try to keep you informed about our progress throughout the process.

Disclosure Policy

• Our customers' privacy, data confidentiality and integrity is crucial at Meredith. You agree that you will not disclose vulnerability information reported to Meredith to any other third party. Public disclosure may be allowed upon request, and only after granted written permission to do so from Meredith, through this program. In such cases, we endeavor to grant such permission within four weeks from the release of the fix that addresses the discovered vulnerability.

• Follow HackerOne's disclosure guidelines.

Testing

Automated Scanning Prohibited

• Where possible, register accounts using your <username>@wearehackerone.com addresses.

• Provide your IP address in the bug report. We will keep this data private and only use it to review logs related to your testing activity.

• Include a custom HTTP header in all your traffic. Burp and other proxies allow the easy automatic addition of headers to all outbound requests. Report to us what header you set so we can identify it easily. For example:

  • A header that includes your username: X-Bug-Bounty:HackerOne-<username>

  • A header that includes a unique or identifiable flag X-Bug-Bounty:ID-<sha256-flag>

When testing for a bug, please also keep in mind:

• Minimize the mayhem. Adhere to program rules at all times. Do not use automated scanners/tools - these tools include payloads that could trigger state changes or damage production systems and/or data.

• Before causing damage or potential damage: Stop, report what you've found and request additional testing permission.

Program Rules

• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue may not be marked as triaged.

• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.

• When duplicates occur, we only triage the first report that was received (provided that it can be fully reproduced).

• Multiple vulnerabilities caused by one underlying issue will be treated as one valid report.

• Social engineering (e.g. phishing, vishing, smishing) is prohibited.

• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.

Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:

• Clickjacking on pages with no sensitive actions

• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions

• Missing best practices which do not lead directly to a vulnerability

  • Missing best practices in SSL/TLS configuration.

  • Missing best practices in Content Security Policy.

  • Missing HttpOnly or Secure flags on cookies

  • Missing X-Frame-Options

• Any activity that could lead to the disruption of our service (DoS).

• Rate limiting or bruteforce issues on non-authentication endpoints

• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS

• Issues relating to HSTS

• Previously known vulnerable libraries without a working Proof of Concept.

• Password and account recovery policies, such as reset link expiration or password complexity

• Self-XSS (we require evidence on how the XSS can be used to attack another Meredith user)

• Outdated DNS record pointing to system which does not belong to Meredith

• Comma Separated Values (CSV) injection without demonstrating a vulnerability.

• Attacks requiring MITM or physical access to a user's device.

• Compromising of browser/device (ex. computer sharing, physical access to a user's device, ...)

• Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]

• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).

• Spamming

• Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)

• Tabnabbing

• Open redirect - unless an additional security impact can be demonstrated

• Issues that require unlikely user interaction

  • Social engineering (including phishing) of Meredith staff, contractors or customers

  • Any physical attempts against Meredith property, data centers or computers

  • Miss of rate limits

  • Report from automated tools and scans

  • Vulnerabilities sending spam or unauthorized messages

  • Bugs in 3rd party software

  • Meredith Customer sites

  • Theoretical attacks

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Legal

You must comply with security industry best practices, and all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program. You agree that any and all information acquired or accessed as part of this exercise is confidential to Meredith and you shall hold all such information in strict confidence and shall not copy, reproduce, sell, assign, license, market, transfer or otherwise dispose of, give, or disclose such information to third parties or use such information for any purposes other than for the performance of your work or expressly authorized in writing by Meredith.

Meredith does not authorize, permit, or otherwise allow (expressly or impliedly) any person, including any individual, group of individuals, consortium, partnership, or any other business or legal entity to engage in any security research or vulnerability or threat disclosure activity that is inconsistent with this policy or the law. If you engage in any activities that are inconsistent with this policy or the law, you may be subject to criminal and/or civil liabilities.

To the extent that any security research or vulnerability disclosure activity involves the networks, systems, information, applications, products, or services of a non-Meredith entity, that non-Meredith third party may independently determine whether to pursue legal action or remedies related to such activities.

By submitting a report to Meredith, you grant to Meredith, its subsidiaries and its affiliates, a perpetual, irrevocable, no charge license to all intellectual property rights licensable by you in or related to the use of information or material submitted. You must notify us if any part of your report is not your own work or is the intellectual property of a third-party.

Meredith may modify the terms of this policy or terminate the program at any time.

Thank you for helping keep Meredith and our users safe!