Details

Welcome to Mercado Libre's Responsible Disclosure Page.

Mercado Libre 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.

Our vulnerability disclosure program encourages security researchers to responsibly report any discovered vulnerabilities. We greatly value the contributions made by researchers to improve our security posture. However, It’s important to clarify that this program does not have a bounty table or officially offer rewards. If you believe you have found a security vulnerability in one of our websites, we welcome and greatly appreciate you reporting it to Mercado Libre, as long as it falls in scope and is not one of the types of vulnerability listed as out of scope below.

#Table of Contents

Response Times
Restrictions
Eligibility and Responsible Disclosure
Vulnerabilities

a. Qualifying Vulnerabilities b. Non-Qualifying Vulnerabilities

Considerations
Testing

** 1. Response Times ** Our commitment to the security research community is to adhere to the highest standards in response times set forth by HackerOne. While we strive to meet the response time targets we set, please note that our ability to achieve these times may vary based on the complexity and volume of submissions. We will, however, make every effort to promptly acknowledge and triage all valid vulnerability reports. We appreciate your patience and understanding as we work diligently to maintain a secure environment

2. Restrictions

Massive automatic scanning is not allowed. Please do creative testing.
If you use test users improperly or out of scope, you risk a program ban.
If you significantly degrade our service, you risk a program ban.
No DoS - Our cloud providers prohibit this activity.
Participation in this program is prohibited for internal employees
Former employees are eligible to participate in the program only after a period of one year from their date of employment termination.
Participation from our company's providers, including any individuals or entities directly affiliated with our organization, is strictly prohibited

3. Eligibility and Responsible Disclosure To encourage coordinated disclosure, MercadoLibre 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 Mercadolibre without making any information or details of the vulnerability public until mutual agreement is made or with the explicit authorization of MercadoLibre.
Researchers will allow Mercado Libre reasonable time to resolve the issue before publishing any information or details about the vulnerability or other making such information generally known. Mercado Libre will do their our best to follow the HackerOne disclosure guidelines which committing 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 make all reasonable attempts in good faith to avoid destroying, stealing, modifying, damaging, violating or otherwise jeopardizing the personal data or privacy of any Mercadolibre's customer or Mercadolibre's data. This includes disrupting or degrading Mercadolibre’s products and service to its customers.

The following are expressly prohibited and are not covered under the above Coordinated Disclosure Policy:

Physical attacks against Mercado Libre employees, offices, and data centers .
Social engineering of Mercado Libre employees, contractors, vendors, or service providers, including phishing.
Pursuing vulnerabilities which send unsolicited bulk messages (spam).
Pursuing vulnerabilities through the compromise of a Mercadolibre 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 Mercado Libre or its employees.
Mass account creation for testing against Mercado Libre applications and services.
"Brute force" testing to determine if rate limiting is in place for APIs or other functionality.

4. Vulnerabilities a. Qualifying Vulnerabilities Examples of vulnerabilities MercadoLibre is interested in receiving:

Authentication flaws
Cross-site scripting (Stored, Reflected, DOM)
Any type of Injection (SQL, NOSQL, LDAP, NOSQL, OS, XML, Eval)
Cross-site request forgery on sensitive controllers (CSRF/XSRF)
Mixed content scripts (scripts loaded over HTTP on an HTTPS page)
Server side code execution (Ej. Exposed consoles or server-side template injection)
Privilege Escalation (lateral and vertical)
Business logic abuse with clear impact.
IDOR (Insecure Direct Object Reference)
XML External Entity injection
Security misconfigurations with clear impact.
Server Side Request Forgery.
Remote File Inclusion.
Unvalidated Redirects and Forwards

b. Non-Qualifying Vulnerabilities Out-of-scope issues that should not be tested or reported:

Lack of rate limiting on a particular API or other 'load testing' types of issues
Wordpress services exposed are out of scope.
OAuth related vulnerabilities.
Non-sensitive (ie. non-session) cookies missing the Secure or HttpOnly flags
Denial-of-service attacks
Information disclosure based on Stack traces or any type of banners (Server error, ftp banners, language, etc )
Use of out-of-date 3rd party libraries without proof of exploitability
Vulnerabilities in 3rd party scripts used on Mercadolibre's websites
Non-sensitive cross-site request forgery (Ej. Logout)
Leaking information via the Referer header
Missing Security Headers (Ej. X-Frame-Options, Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, CORS, CSP, Referer Policy HKPK)
SPF, DKIM, DMARC or other email configuration related issues
Password or account recovery policies, such as reset link expiration or password complexity
Reports from automated web security scanners
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,readme.html on WordPress, etc)
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 the 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
Bugs requiring exceedingly unlikely user interaction
Exploits that require physical access to a user's machine
Certificate Pinning and SSL/TLS best Practices on native apps
Obfuscated Code on native apps
Use of Safety Net attestation API or similar tools to protect against Anti-Dynamic Instrumentation, Debugging, Emulation, Tampering, or Root detection on native apps
Exported components with no real security impact on native apps
Issues related to credentials/info disclosure in public sources such as Trello, GitHub, Wayback, etc, will be analyzed in each case and may not be eligible for bounty.
Vulnerabilities related to loading arbitrary domains on the following deeplinks: mercadopago://in-app-browser/?url=$URL meli://in-app-browser/?url=$URL The In-App Browser feature is designed to open external web pages through deeplink directly from the app without breaking its flow. Therefore, any external website that may be opened in the in-app browser is treated as an untrusted domain.
Dependency confusion vectors are out of scope temporarily

5. Considerations Considerations on issues related to hardcoded credential on public sources:

It’s a must give a working PoC with proven impact, at least demonstrating its a working credential
As it is already specified in safe harbor/DataPrivacy, it’s not allowed to dump sensitive information. Please investigate the purpose of hardcoded credentials you find in order to demonstrate the vulnerability impact with the least damage possible. Considerations on Issues related to vulnerabilities find in code review exercise or SAST:
Please avoid upload of automatic scanning tool results
Vulnerabilities related to vulnerable dependencies detected, CVEs, 0day & working exploits need to be exploitable through internet with a proper PoC. Considerations on Issues related to vulnerabilities find in third parties applications use by MercadoLibre:
If the vulnerability is found in a third-party application used by MercadoLibre, it must be exploitable on MercadoLibre's infrastructure to be considered valid. Otherwise, it will be marked as informative.

6. Testing

Users

Hackers can create users in order to launch testing probes. To do so, follow the steps detailed at: https://developers.mercadolibre.com/en_us/start-testing#Create-a-test-user Testing with test users is limited exclusively to our scope. Please check the restrictions section.

Credit cards

You can use test credit cards from local payment methods in each country and simulate different payment responses, with no real credit cards needed. To do that, pick up any of the cards we provide in the link below, according to the country your user is registered in: https://www.mercadopago.com.ar/developers/es/guides/localization/local-cards

Thank you for helping keep MercadoLibre and our customers Safe!