[{"id":3770493,"new_policy":"#==**Most Valuable Hacker (MVH) Recognition Program**==\n\nThe Most Valuable Hacker (MVH) program recognizes security researchers who consistently demonstrate exceptional contributions to our security posture through high-impact, high-quality vulnerability reports and collaborative engagement throughout the remediation process.\n\n**Annual Recognition:** Three researchers are honored annually for sustained excellence throughout the year. The top-ranked researcher is awarded a $2000 monetary bonus, the second-ranked researcher receives $1000, and the third-ranked researcher receives $500.\n\n**Quarterly Recognition:** Three researchers are honored each quarter. The top-ranked researcher receives a $500 monetary bonus. The second and third-ranked researchers receive public recognition.\n\n##**Recognition Criteria:**\nResearchers are evaluated based on:\n**Impact**: Severity and business criticality of identified vulnerabilities\n**Quality**: Thoroughness of reports, including detailed reproduction steps and remediation guidance\n**Consistency**: Regular submission of valid, actionable findings\n**Collaboration**: Professional communication and support during the vulnerability triage/Resolution process\n**Volume**: Number of valid and actionable security reports submitted through HackerOne\n\n\u003e**2025 Annual Recognition**:\n\u003e1. @m0chan\n\u003e2. @godiego \n\u003e3. @medusa_, @sw33tlie, @bsysop\n\n_____ \n\nMaintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released (Zero Day) may not be eligible for\nreward. For additional insight, please refer to the Platform standards deviations.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n- For Subdomain Takeovers (SDTO) you must demonstrate that you have taken over the domain and that it is still in your possession to avoid false positives and claim-jumping. A valid Proof of Concept html file hosted by you on the site with your HackerOne username is required, preferably in a sub-directory. SDTO reports without a working proof of concept confirming you have control over the subdomain in question will be closed as N/A.\n- The program does not explicitly forbid researchers from using AI/Large-Language-Model (LLM) assisted tooling in their reports. However, researchers should be careful to manually ensure all of their report's content is complete and contains sufficient evidence for our triagers to reproduce and validate. If researchers fail to provide informative content, the program may classify their reports as Spam.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \n- Request Smuggling / Desync type of issues are generally rewarded a standard $1,000 \n\nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and is usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n- HTML Injection - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $125\n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Notes:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n\n- Subdomain Takeover (SDTO) reports are evaluated based on severity, considering cookie scoping, historical significance, and potential traffic volume. The standard reward for such issues is $750. Valid SDTO reports on *.gs.com, *.marcus.com, *. goldman.com, *.gsam.com might be eligible for a reward up to $1,500 (note again that the actual reward may differ from these standards based on the impact of the finding)\n\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues that arise from misconfiguration or improper implementation of third-party SDK/framework/libraries/plugins may be considered as in scope under this program. Goldman Sachs is extremely interested in customer-controlled configuration and implementation choices we made that expose a vulnerability while vulnerabilities in the third-party components' source code itself or third-party external endpoints are not in scope.\n\u003eExamples:\nIN SCOPE: Misconfigured security settings in a third-party authentication plugin\nOUT OF SCOPE: A vulnerability in the third-party plugin's core code\nOUT OF SCOPE: Vulnerabilities in external API endpoints operated by the third-party vendor\n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- Archived documents and files accessible via services like web.archive.org are temporarily out of scope for the program\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"PAYING_FOR_NEW_ZERO_DAYS\",\"justification\":\"Reports for vulnerabilities that were either recently disclosed to the public or\\nwhere a patch was just recently released may not be eligible for reward. This is\\nbecause Goldman Sachs already tracks many of these announcements, and\\nneeds an appropriate amount of time to test and implement patches and\\nsafeguards before a report with the same information can provide value.\\nHowever, each submission is evaluated on a case-by-case basis and the ones\\nproviding significant value may still be eligible for reward. We find more value in a\\nreport that provides accurate information to the extent of how a vulnerability can\\nbe exploited, along with a reproducible proof-of-concept where one was not\\npreviously available, than a report that restates information shared in a recent\\nblog or news article.\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-03T15:22:29.433Z"},{"id":3770470,"new_policy":"#==**Most Valuable Hacker (MVH) Recognition Program**==\n\nThe Most Valuable Hacker (MVH) program recognizes security researchers who consistently demonstrate exceptional contributions to our security posture through high-impact, high-quality vulnerability reports and collaborative engagement throughout the remediation process.\n\n**Annual Recognition:** Three researchers are honored annually for sustained excellence throughout the year. The #1 ranked researcher is awarded a $2000 monetary bonus, the #2 ranked researcher receives $1000, and the #3 ranked researcher receives $500.\n\n**Quarterly Recognition:** Three researchers are honored each quarter. The #1 ranked researcher receives a $500 monetary bonus. Researchers ranked #2 and #3 receive public recognition.\n\n##**Recognition Criteria:**\nResearchers are evaluated based on:\n**Impact**: Severity and business criticality of identified vulnerabilities\n**Quality**: Thoroughness of reports, including detailed reproduction steps and remediation guidance\n**Consistency**: Regular submission of valid, actionable findings\n**Collaboration**: Professional communication and support during the vulnerability triage/Resolution process\n**Volume**: Number of valid and actionable security reports submitted through HackerOne\n\n2025 Annual Recognition:\n1. @m0chan\n2. @godiego \n3. @medusa_, @sw33tlie, @bsysop\n_____ \n\nMaintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released (Zero Day) may not be eligible for\nreward. For additional insight, please refer to the Platform standards deviations.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n- For Subdomain Takeovers (SDTO) you must demonstrate that you have taken over the domain and that it is still in your possession to avoid false positives and claim-jumping. A valid Proof of Concept html file hosted by you on the site with your HackerOne username is required, preferably in a sub-directory. SDTO reports without a working proof of concept confirming you have control over the subdomain in question will be closed as N/A.\n- The program does not explicitly forbid researchers from using AI/Large-Language-Model (LLM) assisted tooling in their reports. However, researchers should be careful to manually ensure all of their report's content is complete and contains sufficient evidence for our triagers to reproduce and validate. If researchers fail to provide informative content, the program may classify their reports as Spam.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \n- Request Smuggling / Desync type of issues are generally rewarded a standard $1,000 \n\nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and is usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n- HTML Injection - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $125\n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Notes:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n\n- Subdomain Takeover (SDTO) reports are evaluated based on severity, considering cookie scoping, historical significance, and potential traffic volume. The standard reward for such issues is $750. Valid SDTO reports on *.gs.com, *.marcus.com, *. goldman.com, *.gsam.com might be eligible for a reward up to $1,500 (note again that the actual reward may differ from these standards based on the impact of the finding)\n\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues that arise from misconfiguration or improper implementation of third-party SDK/framework/libraries/plugins may be considered as in scope under this program. Goldman Sachs is extremely interested in customer-controlled configuration and implementation choices we made that expose a vulnerability while vulnerabilities in the third-party components' source code itself or third-party external endpoints are not in scope.\n\u003eExamples:\nIN SCOPE: Misconfigured security settings in a third-party authentication plugin\nOUT OF SCOPE: A vulnerability in the third-party plugin's core code\nOUT OF SCOPE: Vulnerabilities in external API endpoints operated by the third-party vendor\n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- Archived documents and files accessible via services like web.archive.org are temporarily out of scope for the program\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"PAYING_FOR_NEW_ZERO_DAYS\",\"justification\":\"Reports for vulnerabilities that were either recently disclosed to the public or\\nwhere a patch was just recently released may not be eligible for reward. This is\\nbecause Goldman Sachs already tracks many of these announcements, and\\nneeds an appropriate amount of time to test and implement patches and\\nsafeguards before a report with the same information can provide value.\\nHowever, each submission is evaluated on a case-by-case basis and the ones\\nproviding significant value may still be eligible for reward. We find more value in a\\nreport that provides accurate information to the extent of how a vulnerability can\\nbe exploited, along with a reproducible proof-of-concept where one was not\\npreviously available, than a report that restates information shared in a recent\\nblog or news article.\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2026-03-03T13:15:58.204Z"},{"id":3766415,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released (Zero Day) may not be eligible for\nreward. For additional insight, please refer to the Platform standards deviations.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n- For Subdomain Takeovers (SDTO) you must demonstrate that you have taken over the domain and that it is still in your possession to avoid false positives and claim-jumping. A valid Proof of Concept html file hosted by you on the site with your HackerOne username is required, preferably in a sub-directory. SDTO reports without a working proof of concept confirming you have control over the subdomain in question will be closed as N/A.\n- The program does not explicitly forbid researchers from using AI/Large-Language-Model (LLM) assisted tooling in their reports. However, researchers should be careful to manually ensure all of their report's content is complete and contains sufficient evidence for our triagers to reproduce and validate. If researchers fail to provide informative content, the program may classify their reports as Spam.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \n- Request Smuggling / Desync type of issues are generally rewarded a standard $1,000 \n\nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and is usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n- HTML Injection - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $125\n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Notes:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n\n- Subdomain Takeover (SDTO) reports are evaluated based on severity, considering cookie scoping, historical significance, and potential traffic volume. The standard reward for such issues is $750. Valid SDTO reports on *.gs.com, *.marcus.com, *. goldman.com, *.gsam.com might be eligible for a reward up to $1,500 (note again that the actual reward may differ from these standards based on the impact of the finding)\n\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues that arise from misconfiguration or improper implementation of third-party SDK/framework/libraries/plugins may be considered as in scope under this program. Goldman Sachs is extremely interested in customer-controlled configuration and implementation choices we made that expose a vulnerability while vulnerabilities in the third-party components' source code itself or third-party external endpoints are not in scope.\n\u003eExamples:\nIN SCOPE: Misconfigured security settings in a third-party authentication plugin\nOUT OF SCOPE: A vulnerability in the third-party plugin's core code\nOUT OF SCOPE: Vulnerabilities in external API endpoints operated by the third-party vendor\n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- Archived documents and files accessible via services like web.archive.org are temporarily out of scope for the program\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"PAYING_FOR_NEW_ZERO_DAYS\",\"justification\":\"Reports for vulnerabilities that were either recently disclosed to the public or\\nwhere a patch was just recently released may not be eligible for reward. This is\\nbecause Goldman Sachs already tracks many of these announcements, and\\nneeds an appropriate amount of time to test and implement patches and\\nsafeguards before a report with the same information can provide value.\\nHowever, each submission is evaluated on a case-by-case basis and the ones\\nproviding significant value may still be eligible for reward. We find more value in a\\nreport that provides accurate information to the extent of how a vulnerability can\\nbe exploited, along with a reproducible proof-of-concept where one was not\\npreviously available, than a report that restates information shared in a recent\\nblog or news article.\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-11-20T21:32:04.751Z"},{"id":3757031,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released (Zero Day) may not be eligible for\nreward. For additional insight, please refer to the Platform standards deviations.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n- For Subdomain Takeovers (SDTO) you must demonstrate that you have taken over the domain and that it is still in your possession to avoid false positives and claim-jumping. A valid Proof of Concept html file hosted by you on the site with your HackerOne username is required, preferably in a sub-directory. SDTO reports without a working proof of concept confirming you have control over the subdomain in question will be closed as N/A.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \n- Request Smuggling / Desync type of issues are generally rewarded a standard $1,000 \n\nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and is usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n- HTML Injection - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $125\n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Notes:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n\n- Subdomain Takeover (SDTO) reports are evaluated based on severity, considering cookie scoping, historical significance, and potential traffic volume. The standard reward for such issues is $750. Valid SDTO reports on *.gs.com, *.marcus.com, *. goldman.com, *.gsam.com might be eligible for a reward up to $1,500 (note again that the actual reward may differ from these standards based on the impact of the finding)\n\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues that arise from misconfiguration or improper implementation of third-party SDK/framework/libraries/plugins may be considered as in scope under this program. Goldman Sachs is extremely interested in customer-controlled configuration and implementation choices we made that expose a vulnerability while vulnerabilities in the third-party components' source code itself or third-party external endpoints are not in scope.\n\u003eExamples:\nIN SCOPE: Misconfigured security settings in a third-party authentication plugin\nOUT OF SCOPE: A vulnerability in the third-party plugin's core code\nOUT OF SCOPE: Vulnerabilities in external API endpoints operated by the third-party vendor\n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- Archived documents and files accessible via services like web.archive.org are temporarily out of scope for the program\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"PAYING_FOR_NEW_ZERO_DAYS\",\"justification\":\"Reports for vulnerabilities that were either recently disclosed to the public or\\nwhere a patch was just recently released may not be eligible for reward. This is\\nbecause Goldman Sachs already tracks many of these announcements, and\\nneeds an appropriate amount of time to test and implement patches and\\nsafeguards before a report with the same information can provide value.\\nHowever, each submission is evaluated on a case-by-case basis and the ones\\nproviding significant value may still be eligible for reward. We find more value in a\\nreport that provides accurate information to the extent of how a vulnerability can\\nbe exploited, along with a reproducible proof-of-concept where one was not\\npreviously available, than a report that restates information shared in a recent\\nblog or news article.\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-06-06T18:20:31.750Z"},{"id":3749462,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released (Zero Day) may not be eligible for\nreward. For additional insight, please refer to the Platform standards deviations.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n- For Subdomain Takeovers (SDTO) you must demonstrate that you have taken over the domain and that it is still in your possession to avoid false positives and claim-jumping. A valid Proof of Concept html file hosted by you on the site with your HackerOne username is required, preferably in a sub-directory. SDTO reports without a working proof of concept confirming you have control over the subdomain in question will be closed as N/A.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \n\nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and is usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n- HTML Injection - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $125\n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Notes:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n\n- Subdomain Takeover (SDTO) reports are evaluated based on severity, considering cookie scoping, historical significance, and potential traffic volume. The standard reward for such issues is $750. Valid SDTO reports on *.gs.com, *.marcus.com, *. goldman.com, *.gsam.com might be eligible for a reward up to $1,500 (note again that the actual reward may differ from these standards based on the impact of the finding)\n\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues that arise from misconfiguration or improper implementation of third-party SDK/framework/libraries/plugins may be considered as in scope under this program. Goldman Sachs is extremely interested in customer-controlled configuration and implementation choices we made that expose a vulnerability while vulnerabilities in the third-party components' source code itself or third-party external endpoints are not in scope.\n\u003eExamples:\nIN SCOPE: Misconfigured security settings in a third-party authentication plugin\nOUT OF SCOPE: A vulnerability in the third-party plugin's core code\nOUT OF SCOPE: Vulnerabilities in external API endpoints operated by the third-party vendor\n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- Archived documents and files accessible via services like web.archive.org are temporarily out of scope for the program\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"PAYING_FOR_NEW_ZERO_DAYS\",\"justification\":\"Reports for vulnerabilities that were either recently disclosed to the public or\\nwhere a patch was just recently released may not be eligible for reward. This is\\nbecause Goldman Sachs already tracks many of these announcements, and\\nneeds an appropriate amount of time to test and implement patches and\\nsafeguards before a report with the same information can provide value.\\nHowever, each submission is evaluated on a case-by-case basis and the ones\\nproviding significant value may still be eligible for reward. We find more value in a\\nreport that provides accurate information to the extent of how a vulnerability can\\nbe exploited, along with a reproducible proof-of-concept where one was not\\npreviously available, than a report that restates information shared in a recent\\nblog or news article.\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-02-04T17:47:26.471Z"},{"id":3743637,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released (Zero Day) may not be eligible for\nreward. For additional insight, please refer to the Platform standards deviations.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n- For Subdomain Takeovers (SDTO) you must demonstrate that you have taken over the domain and that it is still in your possession to avoid false positives and claim-jumping. A valid Proof of Concept html file hosted by you on the site with your HackerOne username is required, preferably in a sub-directory. SDTO reports without a working proof of concept confirming you have control over the subdomain in question will be closed as N/A.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \n\nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and is usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n- HTML Injection - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $125\n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Notes:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n\n- Subdomain Takeover (SDTO) reports are evaluated based on severity, considering cookie scoping, historical significance, and potential traffic volume. The standard reward for such issues is $750. Valid SDTO reports on *.gs.com, *.marcus.com, *. goldman.com, *.gsam.com might be eligible for a reward up to $1,500 (note again that the actual reward may differ from these standards based on the impact of the finding)\n\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues that arise from misconfiguration or improper implementation of third-party SDK/framework/libraries/plugins may be considered as in scope under this program. Goldman Sachs is extremely interested in customer-controlled configuration and implementation choices we made that expose a vulnerability while vulnerabilities in the third-party components' source code itself or third-party external endpoints are not in scope.\n\u003eExamples:\nIN SCOPE: Misconfigured security settings in a third-party authentication plugin\nOUT OF SCOPE: A vulnerability in the third-party plugin's core code\nOUT OF SCOPE: Vulnerabilities in external API endpoints operated by the third-party vendor\n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"PAYING_FOR_NEW_ZERO_DAYS\",\"justification\":\"Reports for vulnerabilities that were either recently disclosed to the public or\\nwhere a patch was just recently released may not be eligible for reward. This is\\nbecause Goldman Sachs already tracks many of these announcements, and\\nneeds an appropriate amount of time to test and implement patches and\\nsafeguards before a report with the same information can provide value.\\nHowever, each submission is evaluated on a case-by-case basis and the ones\\nproviding significant value may still be eligible for reward. We find more value in a\\nreport that provides accurate information to the extent of how a vulnerability can\\nbe exploited, along with a reproducible proof-of-concept where one was not\\npreviously available, than a report that restates information shared in a recent\\nblog or news article.\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-11-04T22:31:09.594Z"},{"id":3743634,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released may not be eligible for reward. This is because Goldman Sachs already tracks many of these announcements, and needs an appropriate amount of time to test and implement patches and safeguards before a report with the same information can provide value. However, each submission is evaluated on a case-by-case basis and the ones providing significant value may still be eligible for reward. We find more value in a report that provides a accurate information to the extent of how a vulnerability can be exploited along with a reproducible proof-of-concept where one was not previously available, than a report that restates information shared in a recent blog or news article.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n- For Subdomain Takeovers (SDTO) you must demonstrate that you have taken over the domain and that it is still in your possession to avoid false positives and claim-jumping. A valid Proof of Concept html file hosted by you on the site with your HackerOne username is required, preferably in a sub-directory. SDTO reports without a working proof of concept confirming you have control over the subdomain in question will be closed as N/A.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \n\nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and is usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n- HTML Injection - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $125\n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Notes:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n\n- Subdomain Takeover (SDTO) reports are evaluated based on severity, considering cookie scoping, historical significance, and potential traffic volume. The standard reward for such issues is $750. Valid SDTO reports on *.gs.com, *.marcus.com, *. goldman.com, *.gsam.com might be eligible for a reward up to $1,500 (note again that the actual reward may differ from these standards based on the impact of the finding)\n\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues that arise from misconfiguration or improper implementation of third-party SDK/framework/libraries/plugins may be considered as in scope under this program. Goldman Sachs is extremely interested in customer-controlled configuration and implementation choices we made that expose a vulnerability while vulnerabilities in the third-party components' source code itself or third-party external endpoints are not in scope.\n\u003eExamples:\nIN SCOPE: Misconfigured security settings in a third-party authentication plugin\nOUT OF SCOPE: A vulnerability in the third-party plugin's core code\nOUT OF SCOPE: Vulnerabilities in external API endpoints operated by the third-party vendor\n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"PAYING_FOR_NEW_ZERO_DAYS\",\"justification\":\"Reports for vulnerabilities that were either recently disclosed to the public or\\nwhere a patch was just recently released may not be eligible for reward. This is\\nbecause Goldman Sachs already tracks many of these announcements, and\\nneeds an appropriate amount of time to test and implement patches and\\nsafeguards before a report with the same information can provide value.\\nHowever, each submission is evaluated on a case-by-case basis and the ones\\nproviding significant value may still be eligible for reward. We find more value in a\\nreport that provides accurate information to the extent of how a vulnerability can\\nbe exploited, along with a reproducible proof-of-concept where one was not\\npreviously available, than a report that restates information shared in a recent\\nblog or news article.\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-11-04T22:28:26.248Z"},{"id":3743633,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released may not be eligible for reward. This is because Goldman Sachs already tracks many of these announcements, and needs an appropriate amount of time to test and implement patches and safeguards before a report with the same information can provide value. However, each submission is evaluated on a case-by-case basis and the ones providing significant value may still be eligible for reward. We find more value in a report that provides a accurate information to the extent of how a vulnerability can be exploited along with a reproducible proof-of-concept where one was not previously available, than a report that restates information shared in a recent blog or news article.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n- Subdomain Takeovers\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and is usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n- HTML Injection - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $125\n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Note:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues related to the implementation of third-party SDK/framework/libraries/plugins that integrate with GS apps. However, third-party end-points are not in-scope. \n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["{\"platform_standard\":\"PAYING_FOR_NEW_ZERO_DAYS\",\"justification\":\"Reports for vulnerabilities that were either recently disclosed to the public or\\nwhere a patch was just recently released may not be eligible for reward. This is\\nbecause Goldman Sachs already tracks many of these announcements, and\\nneeds an appropriate amount of time to test and implement patches and\\nsafeguards before a report with the same information can provide value.\\nHowever, each submission is evaluated on a case-by-case basis and the ones\\nproviding significant value may still be eligible for reward. We find more value in a\\nreport that provides accurate information to the extent of how a vulnerability can\\nbe exploited, along with a reproducible proof-of-concept where one was not\\npreviously available, than a report that restates information shared in a recent\\nblog or news article.\"}"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-11-04T21:33:58.990Z"},{"id":3734908,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released may not be eligible for reward. This is because Goldman Sachs already tracks many of these announcements, and needs an appropriate amount of time to test and implement patches and safeguards before a report with the same information can provide value. However, each submission is evaluated on a case-by-case basis and the ones providing significant value may still be eligible for reward. We find more value in a report that provides a accurate information to the extent of how a vulnerability can be exploited along with a reproducible proof-of-concept where one was not previously available, than a report that restates information shared in a recent blog or news article.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n- Subdomain Takeovers\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and is usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n- HTML Injection - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $125\n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Note:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues related to the implementation of third-party SDK/framework/libraries/plugins that integrate with GS apps. However, third-party end-points are not in-scope. \n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["PAYING_FOR_NEW_ZERO_DAYS"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-08-01T18:05:21.018Z"},{"id":3733047,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released may not be eligible for reward. This is because Goldman Sachs already tracks many of these announcements, and needs an appropriate amount of time to test and implement patches and safeguards before a report with the same information can provide value. However, each submission is evaluated on a case-by-case basis and the ones providing significant value may still be eligible for reward. We find more value in a report that provides a accurate information to the extent of how a vulnerability can be exploited along with a reproducible proof-of-concept where one was not previously available, than a report that restates information shared in a recent blog or news article.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n- Subdomain Takeovers\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and is usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n- HTML Injection - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $125\n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Note:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues related to the implementation of third-party SDK/framework/libraries/plugins that integrate with GS apps. However, third-party end-points are not in-scope. \n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":["PAYING_FOR_NEW_ZERO_DAYS"],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-07-19T16:25:33.368Z"},{"id":3730414,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Only interact with accounts you own or with explicit permission of the account holder AND Goldman Sachs. Please reach out to bugbounty@gs.com with any questions. \n-\tIf you inadvertently gain access to an account you do not own, please cease testing immediately and submit a report for Goldman Sachs to validate further. Do not attempt to prove higher impact by downloading data or by modifying any settings\n- By default,  the report should clearly reference your @wearehackerone.com email alias address where possible.\n\u003e Register accounts using your \u003cusername\u003e@wearehackerone.com addresses.\n\u003e To create additional accounts please use '+N' with your email address: \u003cusername\u003e+1@wearehackerone.com, \u003cusername\u003e+2@wearehackerone.com etc.\n-\t**Per our Rewards section below, the addition of the following custom headers along with your public IP is required to qualify you for a bonus on valid triaged reports**(Burp and other proxies allow the easy automatic addition of headers to all outbound requests):\n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released may not be eligible for reward. This is because Goldman Sachs already tracks many of these announcements, and needs an appropriate amount of time to test and implement patches and safeguards before a report with the same information can provide value. However, each submission is evaluated on a case-by-case basis and the ones providing significant value may still be eligible for reward. We find more value in a report that provides a accurate information to the extent of how a vulnerability can be exploited along with a reproducible proof-of-concept where one was not previously available, than a report that restates information shared in a recent blog or news article.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure.\n\n#**Eligibility Guidelines**\nTo be eligible to participate in the Goldman Sachs Bug Bounty Program, you must:\n- Be at least 18 years old.\n-\tAgree and adhere to the Program Rules and Legal terms as stated in this policy.\n-\tBe the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n-\tAssist the Goldman Sachs team in reproducing and triaging the issue, and to provide additional information as needed. \n-\tNot be employed by Goldman Sachs or be employed by 3rd parties managing digital assets in use by Goldman Sachs.\n-\tNot be a resident of, or make submissions from, a country against which the United States has issued export sanctions or other trade restrictions.\n-\tNot be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to the Bug Bounty Program.\n-\tNot be using duplicate HackerOne accounts.\n-\tOut-of-scope vulnerability reports that pose a valid security impact may be addressed as a form of vulnerability disclosure but will generally not be considered eligible for a bounty.\n\nFailure to meet the eligibility requirements above, any breach of the Golman Sachs Bug Bounty policy, or actions taken that adversely impact Goldman Sachs, our affiliates, or any of our users, employees, or agents, may lead to Goldman Sachs in our sole discretion, removing you from this program.\n\n \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \nNote again that a finding falling under these examples doesn't automatically qualify for a high bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \n- Subdomain Takeovers\nNote again that a finding falling under these examples doesn't automatically qualify for a medium bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Note:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n\n| Identifier | Format |\n| ----------- | ----------- |\n| Your Username | X-Bug-Bounty: HackerOne-\u003cusername\\\u003e |\n| Tool Identifier | X-Bug-Bounty: \u003ctoolname\\\u003e |\n\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues related to the implementation of third-party SDK/framework/libraries/plugins that integrate with GS apps. However, third-party end-points are not in-scope. \n_____ \n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope. We monitor a lot of different sources like intelx.io, phonebook.cz etc. for leaked credentials, PII, financial information etc. As such, reports sharing a dump of leaked information from darkweb data aggregators like these do not provide value. \n\u003e If you would still like to responsibly disclose any leaked passwords or sensitive information, please make sure to provide  sufficient identifying information, but obfuscate all other sensitive information. eg: For leaked credentials, please share the username (abc@xyz.com) but obfuscate the password (abc****)\n- Any vulnerabilities for assets not owned, hosted or managed by Goldman Sachs are out of scope. Goldman Sachs does not authorize testing on any applications that are hosted by 3rd parties. Please reach out to the Goldman Sachs Bug Bounty team  at bugbounty@gs.com when in doubt about whether an asset is in scope. \n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-06-21T17:44:26.363Z"},{"id":3714674,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released may not be eligible for reward. This is because Goldman Sachs already tracks many of these announcements, and needs an appropriate amount of time to test and implement patches and safeguards before a report with the same information can provide value. However, each submission is evaluated on a case-by-case basis and the ones providing significant value may still be eligible for reward. We find more value in a report that provides a accurate information to the extent of how a vulnerability can be exploited along with a reproducible proof-of-concept where one was not previously available, than a report that restates information shared in a recent blog or news article.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure. \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Note:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n**X-HackerOne-Research: \u003cYOUR-USERNAME\u003e **\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets on mobile apps which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues related to the implementation of third-party SDK/framework/libraries/plugins that integrate with GS apps. However, third-party end-points are not in-scope. \n_____ \n\n# **Open Source guidance** \n\nGoldman Sachs recognizes that part of keeping our clients safe is making sure that we find and fix any security issues in our open source projects. If you find vulnerabilities in any of our **participating** open source projects, send us a report here. Feel free to even recommend a fix! \n\n**Note that while currently only CatchIT is in scope, we do intend to bring in more GS owned/managed projects into scope in the near future** \n\nMake sure to include the following in your report for a finding on one of our open source projects: \n- Specific source code references from our Github \n- Repository, release version, branch and any other pertinent information \n- Like any other submission on our program, please describe the perceived impact. How could the bug potentially be exploited? \n- If you'd like to send us a fix, attach a patch file to the finding. DO NOT open a pull request or Github ticket to fix an issue you're reporting. This might unintentionally publicly disclose potential vulnerabilities \n\n**Out of Scope:** \n\n- Issues on any open source projects not explicitly listed as in scope below \n- Issues related to software not under our control (such as external dependencies) \n- Most of our open source development is publicly visible. Reports related to an issue being fixed in a branch or being tracked in a public way will therefore not be eligible for a bounty. \n_____ \n\n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- All Github/Gitlab/darkweb based credential leakage/information disclosure issues are temporarily out of scope\n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-15T22:44:03.886Z"},{"id":3702288,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released may not be eligible for reward. This is because Goldman Sachs already tracks many of these announcements, and needs an appropriate amount of time to test and implement patches and safeguards before a report with the same information can provide value. However, each submission is evaluated on a case-by-case basis and the ones providing significant value may still be eligible for reward. We find more value in a report that provides a accurate information to the extent of how a vulnerability can be exploited along with a reproducible proof-of-concept where one was not previously available, than a report that restates information shared in a recent blog or news article.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure. \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Note:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n**X-HackerOne-Research: \u003cYOUR-USERNAME\u003e **\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues related to the implementation of third-party SDK/framework/libraries/plugins that integrate with GS apps. However, third-party end-points are not in-scope. \n_____ \n\n# **Open Source guidance** \n\nGoldman Sachs recognizes that part of keeping our clients safe is making sure that we find and fix any security issues in our open source projects. If you find vulnerabilities in any of our **participating** open source projects, send us a report here. Feel free to even recommend a fix! \n\n**Note that while currently only CatchIT is in scope, we do intend to bring in more GS owned/managed projects into scope in the near future** \n\nMake sure to include the following in your report for a finding on one of our open source projects: \n- Specific source code references from our Github \n- Repository, release version, branch and any other pertinent information \n- Like any other submission on our program, please describe the perceived impact. How could the bug potentially be exploited? \n- If you'd like to send us a fix, attach a patch file to the finding. DO NOT open a pull request or Github ticket to fix an issue you're reporting. This might unintentionally publicly disclose potential vulnerabilities \n\n**Out of Scope:** \n\n- Issues on any open source projects not explicitly listed as in scope below \n- Issues related to software not under our control (such as external dependencies) \n- Most of our open source development is publicly visible. Reports related to an issue being fixed in a branch or being tracked in a public way will therefore not be eligible for a bounty. \n_____ \n\n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Brute Forcing Login and/or Registration\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-09-15T20:36:16.470Z"},{"id":3700625,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Reports for vulnerabilities that were either recently disclosed to the public or where a patch was just recently released may not be eligible for reward. This is because Goldman Sachs already tracks many of these announcements, and needs an appropriate amount of time to test and implement patches and safeguards before a report with the same information can provide value. However, each submission is evaluated on a case-by-case basis and the ones providing significant value may still be eligible for reward. We find more value in a report that provides a accurate information to the extent of how a vulnerability can be exploited along with a reproducible proof-of-concept where one was not previously available, than a report that restates information shared in a recent blog or news article.\n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure. \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Note:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n**X-HackerOne-Research: \u003cYOUR-USERNAME\u003e **\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues related to the implementation of third-party SDK/framework/libraries/plugins that integrate with GS apps. However, third-party end-points are not in-scope. \n_____ \n\n# **Open Source guidance** \n\nGoldman Sachs recognizes that part of keeping our clients safe is making sure that we find and fix any security issues in our open source projects. If you find vulnerabilities in any of our **participating** open source projects, send us a report here. Feel free to even recommend a fix! \n\n**Note that while currently only CatchIT is in scope, we do intend to bring in more GS owned/managed projects into scope in the near future** \n\nMake sure to include the following in your report for a finding on one of our open source projects: \n- Specific source code references from our Github \n- Repository, release version, branch and any other pertinent information \n- Like any other submission on our program, please describe the perceived impact. How could the bug potentially be exploited? \n- If you'd like to send us a fix, attach a patch file to the finding. DO NOT open a pull request or Github ticket to fix an issue you're reporting. This might unintentionally publicly disclose potential vulnerabilities \n\n**Out of Scope:** \n\n- Issues on any open source projects not explicitly listed as in scope below \n- Issues related to software not under our control (such as external dependencies) \n- Most of our open source development is publicly visible. Reports related to an issue being fixed in a branch or being tracked in a public way will therefore not be eligible for a bounty. \n_____ \n\n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Vulnerabilities that require extensive user interaction or social engineering\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**On top of the above, the following items also are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n- Enumerating and/or Brute Forcing Login and/or Registration.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-29T18:48:26.954Z"},{"id":3686443,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below.  \nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below. \n\n\u003e Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access and immediately purge any local information, if applicable. \n   \n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n\nThank you for helping keep Goldman Sachs and our users safe! \n_____ \n\n# **Program Rules** \n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n- The URL and any affected parameters \n- The browser, OS, and/or app version \n- The perceived impact. How could the bug potentially be exploited? \n- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced). \n- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. \n- Social engineering (e.g. phishing, vishing, smishing) is prohibited. \n- 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. \n- Do not try to further pivot into the network by using a vulnerability. The rules around RCE, SQLi, vulnerabilities allowing you to access file/folder structure, defacement and file-uploads are listed below. \n- Do not try to exploit service providers we use (hosting, domain registrar, email, marketing, etc.).  The Firm does not authorize you to perform any actions against non-GS owned property/system/service/data. If you are unsure if a system you discovered belongs to Goldman Sachs or not, ask first before testing further. \n- Please note that zero-day vulnerabilities (vulnerabilities that were not previously known to the security community) are not eligible for standard rewards unless you identify a zero-day vulnerability on an in-scope system more than 90 days after the zero-day vulnerability was disclosed to the security community. Also, vulnerabilities already known and tracked by our internal team at the time of your report will not be eligible for an award. Each such submission is evaluated on a case-by-case basis and ones providing us with significant value might be eligible for a small reward. \n- If you encounter Personally Identifiable Information (PII) contact us at [bugbounty@gs.com](mailto:bugbounty@gs.com) immediately. Do not proceed with access, do not upload PII, and immediately purge any local information, if applicable. \n- Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program. \n- For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you to read underlying file/ folder structure, it is prohibited to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure. \n_____ \n\n#**Rewards **\n\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. As a general concept the vulnerabilities identified will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected. \nSeverity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score does not always qualify for a higher or lower reward amount. On the table above, you will find listed our reward structure and further below what usually falls under the 4 different impact classes. \n\n#### **Critical Impact** \nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include: \n- Server Side Injections (RCE, Command Injections) \n- SQLi \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **High Impact** \nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues: \n- SSRF \n- LFI \n- XXE \n- Significant Authentication Bypasses \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Medium Impact** \nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities: \n- RFI \n- Memory Leaks \n- IDORs \n- Stored XSS \nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue. \n\n#### **Low Impact** \nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues: \n- Reflected XSS - In our apps, it is usually considered a low impact issue and are usually rewarded a standard $250 \n- Open Redirects - Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps, it is usually considered a low impact issue and usually rewarded a standard $250 \n\n#### **Informational Issues** \nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n**Note:** \n- Some of our public applications share similar code bases and configurations, allowing a vulnerability found on one URL to exist on others.  When the same fix addresses the issue in multiple places, only the first report is eligible for reward. However, additional reported instances might affect the severity of the issue and be eligible for discretionary bonuses. So, if you identify numerous instances of the same issue on multiple in-scope domains, we request that you submit a single report that documents the finding. Additional instances that are discovered later should also be added to the original report.\n- All submissions will be evaluated on a case-by-case basis by the Firm's BugBounty Rewards Panel. Please remember that as an example, executing RCE (Remote Code Execution/OS Command Injection) does not necessarily mean the impact is Critical. The Bug Bounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the risk/impact of the vulnerability reported \n\n## **Monetary bonus for IP Address and/or header identification:** \nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a $50 bonus for every valid, accepted, non informational report when it is used during testing and it is mentioned in the report. **This can be done by adding the following header to your request:** \n**X-HackerOne-Research: \u003cYOUR-USERNAME\u003e **\n------ \n\n# **Mobile apps guidance** \n- Only use the latest official releases in the Play Store and App Store for testing. \n- Only test backend domains listed as in-scope for the program. \n- Applications developed and signed by Goldman Sachs must be up-to-date with the latest update. \n\n**Focus Areas:** \n- Unauthorized access to GS customer/user account \n- Application compromise via physical access \n- GS app attack via user installed legitimate/malicious application \n- Application Login/Authentication Bypass \n- Application Logic Bypass \n- Authorization Bypass \n- Insecure Access Controls \n- Application Requests permissions that are overly privileged causing both privacy \u0026 security issues \n- Sensitive user data / GS data extraction \n- Exposed credentials/secret/hard-coded secrets which lead to leakage of sensitive user/GS data \n- XSS, CSRF, directory traversal, Injection vulnerabilities that pose a valid risk \n- Security issues related to the implementation of third-party SDK/framework/libraries/plugins that integrate with GS apps. However, third-party end-points are not in-scope. \n_____ \n\n# **Open Source guidance** \n\nGoldman Sachs recognizes that part of keeping our clients safe is making sure that we find and fix any security issues in our open source projects. If you find vulnerabilities in any of our **participating** open source projects, send us a report here. Feel free to even recommend a fix! \n\n**Note that while currently only CatchIT is in scope, we do intend to bring in more GS owned/managed projects into scope in the near future** \n\nMake sure to include the following in your report for a finding on one of our open source projects: \n- Specific source code references from our Github \n- Repository, release version, branch and any other pertinent information \n- Like any other submission on our program, please describe the perceived impact. How could the bug potentially be exploited? \n- If you'd like to send us a fix, attach a patch file to the finding. DO NOT open a pull request or Github ticket to fix an issue you're reporting. This might unintentionally publicly disclose potential vulnerabilities \n\n**Out of Scope:** \n\n- Issues on any open source projects not explicitly listed as in scope below \n- Issues related to software not under our control (such as external dependencies) \n- Most of our open source development is publicly visible. Reports related to an issue being fixed in a branch or being tracked in a public way will therefore not be eligible for a bounty. \n_____ \n\n\n# **Specific Vulnerabilities Guidance** \n\n### **Remote Code Execution (RCE) Policy** \n\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy. \n\n#### Prohibited actions when conducting RCE attempts: \n\n- Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code) \n- Altering file permissions \n-  Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure) \n- Altering/Modifying/Deleting any files on the system. \n- Copying any files from the system and disclosing them to a non-GS site or entity \n- Interacting with underlying OS-level data and/or databases. \n- Interacting with other services running on the OS-level and/or any remote hosts residing on the network. \n- Interrupting the normal operation of the server. \n- Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited. \n\n#### Allowed actions when conducting RCE attempts - Unix: \n- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands \n- Reading content of the '/etc/passwd' file \n- Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation. \n\n#### Allowed actions when conducting RCE attempts - Windows: \n- Executing `ipconfig`, `hostname`, `whoami` or any metrics commands \n- Reading content of the `drive:/boot.ini`, `drive:/install.ini` or `drive:/Windows/System32/drivers/etc/networks` \n- Using `echo` to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation. \n\n### SQL Injection (SQLi) Policy** \n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy. Prohibited actions when conducting SQLi attempts: \n\n- Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`) \n- Reading specific sensitive database records \n- Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of `INTO OUTFILE` \n- Command Execution (`xp_cmdshell`, uploading .so or any action that leads to command execution) \n- Creating/Deleting Users \n- Reading/Altering Username and Password information (includes password hashes) \n- Interrupting the normal operation of the server and the database. \n\n#### Allowed actions when conducting SQLi attempts: \n\n- Executing SELECT queries such as: `@@version;` `@@SERVERNAME;` `user();` `system_user();` or `database();` \n- Listing Databases names from schema, listing Columns, Table names \n- Using Logic and time in Server Responses \n- Using output responses \n- Executing Mathematical, conversion or logical queries, such as: \n\n1. ASCII Value -\u003e Char `SELECT char(65); # returns A` \n2. Char -\u003e ASCII Value `SELECT ascii('A'); # returns 65` \n3. String Concatenation `SELECT CONCAT('A','B','C'); # returns ABC` \n4. Case Statement `SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A`) \n5. Character Decoding `SELECT 0x414243; # returns ABC`) \n6. Time Delay `SELECT BENCHMARK(1000000,MD5('A')); SELECT SLEEP(5);` ) \n\n### **File-Upload Policy** \n\nVulnerabilities which allow upload of files through any means (e.g. PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules \n\nProhibited actions when conducting File-upload attempts: \n- Altering/Modifying/Deleting/Replacing any files on the system. (e.g. defacement) \n- Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data e.g.) \n- Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) \n- Uploading files which can cause Denial of Service (e.g. over-sized files or unlimited number of files resulting in running out of Disk Quota) \n\n#### Allowed actions when conducting File-upload attempts: \n- Chained exploitation vectors allowing you to jump out from the upload folder using e.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. \n- Upload of a file (any extension) with no content, simple string, integer or a special character. \n _____\n\n\n# **Out of scope vulnerabilities**\n\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n- All Flash based vulnerabilities out of scope\n- Reports from automated tools or scans\n- Reports affecting outdated browsers\n- Denial of Service Attacks\n- Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n- Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure - without clear and working exploit)\n- Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n- Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n- Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n- Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n- Lack of HTTPS\n- Reports about insecure SSL / TLS configuration\n- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n- Presence/Lack of autocomplete attribute on web forms/password managers.\n- Server Banner Disclosure/Technology used Disclosure\n- Full Path Disclosure\n- IP Address Disclosure\n- CSRF on logout or insignificant functionalities\n- Publicly accessible login panels\n- Clickjacking\n- CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information)\n- Tabnabbing\n- Host Header Injection (Unless it gives you access to interim proxies)\n- Cache Poisoning\n- Reflective File Download\n- Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n- PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n- OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped\n- Private IP/Hostname disclosures or real IP disclosures for services using CDN\n- Open ports which do not lead directly to a vulnerability\n- Our policies on presence/absence of SPF / DKIM / DMARC records\n- Lack of DNS CAA and DNS-related configurations\n- Weak Certificate Hash Algorithm\n- Social engineering of GS employees or contractors\n- Any physical/wireless attempt against GS property or data centers\n- Avoid all active testing on contact and registration forms, such as \"Contact us\", \"Register for a Demo\". These forms may generate emails that will affect the business. \n- Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points\n\n\n**The following items are out-of-scope for mobile applications:**\n- Vulnerabilities that can *only* be exploited on a rooted, jailbroken, or device with intentionally reduced security controls are considered out of scope. Submissions will be rewarded only if the vulnerability exists and can be exploited on a non-jailbroken, non- rooted or non-modified device.\n- Vulnerabilities that require extensive user interaction or social engineering\n- Lack of / Incomplete certificate pinning\n- Bugs that simply cause an app to crash without any security impact\n- Known 0-day/ Day 1 vulnerabilities or recently disclosed CVE will not be considered eligible until more than 90 days have passed since patch availability\n- Exposure of non-sensitive data on the device\n- Exposure of data via usage of overlays or accessibility services.\n- Enumerating and/or Brute Forcing Login and/or Registration.\n_____\n\n\n# **Public Disclosure Policy**\n- Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker.\n- Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n- Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# **Legal**\n- You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n- You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n- You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n- You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n- GS may modify the terms of this policy or terminate the policy at any time.\n- By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n- Please use your own account for testing or research purposes. Do not attempt to gain access to another users account or confidential information.\n- Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nThank you for helping keep Goldman Sachs and our clients and customers safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-04-20T21:21:57.414Z"},{"id":3663907,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n_____\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\n_____\n\nRewards\n---------------------\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. Severity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score doesn't always qualify for a higher or lower reward amount. Below you'll find listed our reward structure and what usually falls under the 4 different impact classes.\n\n| Security Impact | Minimum Reward | Maximum Reward |\n| --------------- | -------------- | -------------- |\n| Critical        | $6,000         | $15,000       |\n| High            | $3,000         | $5,000        |\n| Medium          | $1,000         | $2,500         |\n| Low             | $50            | $500           |\n| Informational   | $0             | $0             |\n\n\n####Critical Impact\n\nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include:\n\n- Server Side Injections (RCE, Command Injections)\n- SQLi\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n\n####High Impact\n\nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues:\n\n- SSRF\n- LFI\n- XXE\n- Significant Authentication Bypasses\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Medium Impact\n\nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities:\n\n- RFI\n- Memory Leaks\n- IDORs\n- Stored XSS\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Low Impact\n\nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues:\n\n- Reflected XSS (Note that Reflected XSS might have a higher traditional cvss score but in our apps it's usually considered a low impact issue)\n- Open Redirects (Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps it's usually considered a low impact issue) \n\n\n####Informational Issues\n\nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n\n**NOTE:**\n\n- **For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you you to read underlying file/ folder structure it is prohibited to to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure**\n\n- **Please note that a lot of our public domains share the same code bases, CMSs and as such, any vulnerability found on one might exist on others. At the same time though, a lot of those issues generally require the same fix. So in cases like this, where the same fix addresses the issue in multiple places, only the first submission is going to be eligible for a reward.**\n\n- **All submissions will be evaluated on a case by case basis by the Firm's BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.**\n\n# Monetary bonus for HTTP header and IP Address identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n`\nX-HackerOne-Research: \u003cYOUR-USERNAME\u003e\n`\n\n_____\n\nSpecific Vulnerabilities Guidance\n---------------------\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (`SELECT LOAD_FILE`)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as: `@@version; @@SERVERNAME; user(); system_user(); database(); etc.`\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii('A'); # returns 65)\n3. String Concatenation (SELECT CONCAT('A','B','C'); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN 'A' ELSE 'B' END; # returns A)\n5. SELECT 0x414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\n_____\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   Sites not operated by Goldman Sachs. Goldman Sachs does not authorize testing against third-party websites. A major indicator for this is when a subdomain has a DNS CNAME record pointing to another organization. If you are unsure, please ask before testing.\n+   All vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\n_____\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\n\nThank you for helping keep Goldman Sachs and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-01-06T23:20:52.056Z"},{"id":3661704,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n_____\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\n_____\n\nRewards\n---------------------\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. Severity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score doesn't always qualify for a higher or lower reward amount. Below you'll find listed our reward structure and what usually falls under the 4 different impact classes.\n\n| Security Impact | Minimum Reward | Maximum Reward |\n| --------------- | -------------- | -------------- |\n| Critical        | $6,000         | $15,000       |\n| High            | $3,000         | $5,000        |\n| Medium          | $1,000         | $2,500         |\n| Low             | $50            | $500           |\n| Informational   | $0             | $0             |\n\n\n####Critical Impact\n\nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include:\n\n- Server Side Injections (RCE, Command Injections)\n- SQLi\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n\n####High Impact\n\nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues:\n\n- SSRF\n- LFI\n- XXE\n- Significant Authentication Bypasses\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Medium Impact\n\nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities:\n\n- RFI\n- Memory Leaks\n- IDORs\n- Stored XSS\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Low Impact\n\nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues:\n\n- Reflected XSS (Note that Reflected XSS might have a higher traditional cvss score but in our apps it's usually considered a low impact issue)\n- Open Redirects (Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps it's usually considered a low impact issue) \n\n\n####Informational Issues\n\nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n\n\n####NOTE:\n\n- **All Flash based vulnerabilities are considered Out of Scope**\n\n- **For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you you to read underlying file/ folder structure it is prohibited to to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure**\n\n- **Please note that a lot of our public domains share the same code bases, CMSs and as such, any vulnerability found on one might exist on others. At the same time though, a lot of those issues generally require the same fix. So in cases like this, where the same fix addresses the issue in multiple places, only the first submission is going to be eligible for a reward.**\n\n- **All submissions will be evaluated on a case by case basis by the Firm`s BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.**\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n_____\n\nSpecific Vulnerabilities Guidance\n---------------------\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\n_____\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   Sites not operated by Goldman Sachs. Goldman Sachs does not authorize testing against third-party websites. A major indicator for this is when a subdomain has a DNS CNAME record pointing to another organization. If you are unsure, please ask before testing.\n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\n_____\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-11-15T16:47:20.158Z"},{"id":3653229,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n_____\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\n_____\n\nRewards\n---------------------\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. Severity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score doesn't always qualify for a higher or lower reward amount. Below you'll find listed our reward structure and what usually falls under the 4 different impact classes.\n\n| Security Impact | Minimum Reward | Maximum Reward |\n| --------------- | -------------- | -------------- |\n| Critical        | $6,000         | $15,000       |\n| High            | $3,000         | $5,000        |\n| Medium          | $1,000         | $2,500         |\n| Low             | $50            | $500           |\n| Informational   | $0             | $0             |\n\n\n####Critical Impact\n\nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include:\n\n- Server Side Injections (RCE, Command Injections)\n- SQLi\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n\n####High Impact\n\nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues:\n\n- SSRF\n- LFI\n- XXE\n- Significant Authentication Bypasses\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Medium Impact\n\nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities:\n\n- RFI\n- Memory Leaks\n- IDORs\n- Stored XSS\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Low Impact\n\nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues:\n\n- Reflected XSS (Note that Reflected XSS might have a higher traditional cvss score but in our apps it's usually considered a low impact issue)\n- Open Redirects (Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps it's usually considered a low impact issue) \n\n\n####Informational Issues\n\nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n\n\n####NOTE:\n\n- **All Flash based vulnerabilities are considered Out of Scope**\n\n- **For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you you to read underlying file/ folder structure it is prohibited to to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure**\n\n- **Please note that a lot of our public domains share the same code bases, CMSs and as such, any vulnerability found on one might exist on others. At the same time though, a lot of those issues generally require the same fix. So in cases like this, where the same fix addresses the issue in multiple places, only the first submission is going to be eligible for a reward.**\n\n- **All submissions will be evaluated on a case by case basis by the Firm`s BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.**\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n_____\n\nSpecific Vulnerabilities Guidance\n---------------------\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\n_____\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\n_____\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-06-08T17:56:31.938Z"},{"id":3652657,"new_policy":"**Limited time promotion:**\n\n**To appreciate your hard work and continued collaboration, we currently have a promotion running on our program between May24th and June 7th. All valid, non-duplicate, high or critical severity findings submitted between the aforementioned dates will be eligible for a 20% higher reward! Moreover, as part of this promotion we have increased our maximum possible reward for a critical finding to $20,000!**\n\n**Good luck and Happy Hunting!**\n\nMaintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n_____\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\n_____\n\nRewards\n---------------------\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. Severity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score doesn't always qualify for a higher or lower reward amount. Below you'll find listed our reward structure and what usually falls under the 4 different impact classes.\n\n| Security Impact | Minimum Reward | Maximum Reward |\n| --------------- | -------------- | -------------- |\n| Critical        | $7,200         | $20,000 limited time!       |\n| High            | $3,600         | $6,000 limited time!        |\n| Medium          | $1,000         | $2,500         |\n| Low             | $50            | $500           |\n| Informational   | $0             | $0             |\n\n\n####Critical Impact\n\nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include:\n\n- Server Side Injections (RCE, Command Injections)\n- SQLi\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n\n####High Impact\n\nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues:\n\n- SSRF\n- LFI\n- XXE\n- Significant Authentication Bypasses\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Medium Impact\n\nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities:\n\n- RFI\n- Memory Leaks\n- IDORs\n- Stored XSS\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Low Impact\n\nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues:\n\n- Reflected XSS (Note that Reflected XSS might have a higher traditional cvss score but in our apps it's usually considered a low impact issue)\n- Open Redirects (Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps it's usually considered a low impact issue) \n\n\n####Informational Issues\n\nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n\n\n####NOTE:\n\n- **All Flash based vulnerabilities are considered Out of Scope**\n\n- **For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you you to read underlying file/ folder structure it is prohibited to to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure**\n\n- **Please note that a lot of our public domains share the same code bases, CMSs and as such, any vulnerability found on one might exist on others. At the same time though, a lot of those issues generally require the same fix. So in cases like this, where the same fix addresses the issue in multiple places, only the first submission is going to be eligible for a reward.**\n\n- **All submissions will be evaluated on a case by case basis by the Firm`s BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.**\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n_____\n\nSpecific Vulnerabilities Guidance\n---------------------\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\n_____\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\n_____\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-24T13:56:36.295Z"},{"id":3652656,"new_policy":"**Limited time promotion:**\n\n**To appreciate your hard work and continued collaboration, we currently have a promotion running on our program between May24th and June 7th. All valid, non-duplicate, high or critical severity findings submitted between the aforementioned dates will be eligible for a 20% higher reward! Moreover, as part of this promotion we have increased our maximum possible reward for a critical finding to $20,000!**\n\n**Good luck and Happy Hunting!**\n\nMaintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n_____\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\n_____\n\nRewards\n---------------------\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. Severity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score doesn't always qualify for a higher or lower reward amount. Below you'll find listed our reward structure and what usually falls under the 4 different impact classes.\n\n| Security Impact | Minimum Reward | Maximum Reward |\n| --------------- | -------------- | -------------- |\n| Critical        | $7,200         | $20,000 limited time!       |\n| High            | $3,600         | $6,000         |\n| Medium          | $1,000         | $2,500         |\n| Low             | $50            | $500           |\n| Informational   | $0             | $0             |\n\n\n####Critical Impact\n\nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include:\n\n- Server Side Injections (RCE, Command Injections)\n- SQLi\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n\n####High Impact\n\nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues:\n\n- SSRF\n- LFI\n- XXE\n- Significant Authentication Bypasses\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Medium Impact\n\nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities:\n\n- RFI\n- Memory Leaks\n- IDORs\n- Stored XSS\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Low Impact\n\nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues:\n\n- Reflected XSS (Note that Reflected XSS might have a higher traditional cvss score but in our apps it's usually considered a low impact issue)\n- Open Redirects (Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps it's usually considered a low impact issue) \n\n\n####Informational Issues\n\nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n\n\n####NOTE:\n\n- **All Flash based vulnerabilities are considered Out of Scope**\n\n- **For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you you to read underlying file/ folder structure it is prohibited to to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure**\n\n- **Please note that a lot of our public domains share the same code bases, CMSs and as such, any vulnerability found on one might exist on others. At the same time though, a lot of those issues generally require the same fix. So in cases like this, where the same fix addresses the issue in multiple places, only the first submission is going to be eligible for a reward.**\n\n- **All submissions will be evaluated on a case by case basis by the Firm`s BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.**\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n_____\n\nSpecific Vulnerabilities Guidance\n---------------------\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\n_____\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\n_____\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-24T13:55:40.853Z"},{"id":3652655,"new_policy":"**Limited time promotion:**\n\n**To appreciate your hard work and continued collaboration, we currently have a promotion running on our program between May24th and June 7th. All valid, non-duplicate, high or critical severity findings submitted between the aforementioned dates will be eligible for a 20% higher reward! Moreover, as part of this promotion we have increased our maximum possible reward for a critical finding to $20,000!**\n\n**Good luck and Happy Hunting!**\n\nMaintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n_____\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\n_____\n\nRewards\n---------------------\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. Severity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score doesn't always qualify for a higher or lower reward amount. Below you'll find listed our reward structure and what usually falls under the 4 different impact classes.\n\n| Security Impact | Minimum Reward | Maximum Reward |\n| --------------- | -------------- | -------------- |\n| Critical        | $6,000         | $20,000 limited time!       |\n| High            | $3,000         | $5,000         |\n| Medium          | $1,000         | $2,500         |\n| Low             | $50            | $500           |\n| Informational   | $0             | $0             |\n\n\n####Critical Impact\n\nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include:\n\n- Server Side Injections (RCE, Command Injections)\n- SQLi\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n\n####High Impact\n\nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues:\n\n- SSRF\n- LFI\n- XXE\n- Significant Authentication Bypasses\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Medium Impact\n\nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities:\n\n- RFI\n- Memory Leaks\n- IDORs\n- Stored XSS\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Low Impact\n\nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues:\n\n- Reflected XSS (Note that Reflected XSS might have a higher traditional cvss score but in our apps it's usually considered a low impact issue)\n- Open Redirects (Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps it's usually considered a low impact issue) \n\n\n####Informational Issues\n\nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n\n\n####NOTE:\n\n- **All Flash based vulnerabilities are considered Out of Scope**\n\n- **For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you you to read underlying file/ folder structure it is prohibited to to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure**\n\n- **Please note that a lot of our public domains share the same code bases, CMSs and as such, any vulnerability found on one might exist on others. At the same time though, a lot of those issues generally require the same fix. So in cases like this, where the same fix addresses the issue in multiple places, only the first submission is going to be eligible for a reward.**\n\n- **All submissions will be evaluated on a case by case basis by the Firm`s BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.**\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n_____\n\nSpecific Vulnerabilities Guidance\n---------------------\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\n_____\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\n_____\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-24T13:33:58.488Z"},{"id":3652654,"new_policy":"**Limited time promotion:**\n\n**To appreciate your hard work and continued collaboration, we currently have a promotion running on our program between May24th and June 7th. All valid, non-duplicate, high or critical severity findings submitted between the aforementioned dates will be eligible for a 20% higher reward! Moreover, as part of this promotion we have increased our maximum possible reward for a critical finding to $20,000!**\n\nGood luck and Happy Hunting!\n\nMaintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n_____\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\n_____\n\nRewards\n---------------------\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. Severity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score doesn't always qualify for a higher or lower reward amount. Below you'll find listed our reward structure and what usually falls under the 4 different impact classes.\n\n| Security Impact | Minimum Reward | Maximum Reward |\n| --------------- | -------------- | -------------- |\n| Critical        | $6,000         | $20,000 limited time!       |\n| High            | $3,000         | $5,000         |\n| Medium          | $1,000         | $2,500         |\n| Low             | $50            | $500           |\n| Informational   | $0             | $0             |\n\n\n####Critical Impact\n\nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include:\n\n- Server Side Injections (RCE, Command Injections)\n- SQLi\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n\n####High Impact\n\nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues:\n\n- SSRF\n- LFI\n- XXE\n- Significant Authentication Bypasses\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Medium Impact\n\nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities:\n\n- RFI\n- Memory Leaks\n- IDORs\n- Stored XSS\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Low Impact\n\nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues:\n\n- Reflected XSS (Note that Reflected XSS might have a higher traditional cvss score but in our apps it's usually considered a low impact issue)\n- Open Redirects (Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps it's usually considered a low impact issue) \n\n\n####Informational Issues\n\nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n\n\n####NOTE:\n\n- **All Flash based vulnerabilities are considered Out of Scope**\n\n- **For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you you to read underlying file/ folder structure it is prohibited to to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure**\n\n- **Please note that a lot of our public domains share the same code bases, CMSs and as such, any vulnerability found on one might exist on others. At the same time though, a lot of those issues generally require the same fix. So in cases like this, where the same fix addresses the issue in multiple places, only the first submission is going to be eligible for a reward.**\n\n- **All submissions will be evaluated on a case by case basis by the Firm`s BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.**\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n_____\n\nSpecific Vulnerabilities Guidance\n---------------------\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\n_____\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\n_____\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-24T13:22:30.217Z"},{"id":3652653,"new_policy":"**Limited time promotion:**\n\n**To appreciate your hard work and continued collaboration, we currently have a promotion running on our program between May24th and June 7th. All valid, non-duplicate, high or critical severity findings submitted between the aforementioned dates will be eligible for a 20% higher reward! Moreover, as part of this promotion we have increased our maximum possible reward for a critical finding to $20,000!**\n\nGood luck and Happy Hunting!\n\nMaintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n_____\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\n_____\n\nRewards\n---------------------\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. Severity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score doesn't always qualify for a higher or lower reward amount. Below you'll find listed our reward structure and what usually falls under the 4 different impact classes.\n\n| Security Impact | Minimum Reward | Maximum Reward |\n| --------------- | -------------- | -------------- |\n| Critical        | $6,000         | $15,000        |\n| High            | $3,000         | $5,000         |\n| Medium          | $1,000         | $2,500         |\n| Low             | $50            | $500           |\n| Informational   | $0             | $0             |\n\n\n####Critical Impact\n\nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include:\n\n- Server Side Injections (RCE, Command Injections)\n- SQLi\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n\n####High Impact\n\nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues:\n\n- SSRF\n- LFI\n- XXE\n- Significant Authentication Bypasses\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Medium Impact\n\nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities:\n\n- RFI\n- Memory Leaks\n- IDORs\n- Stored XSS\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Low Impact\n\nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues:\n\n- Reflected XSS (Note that Reflected XSS might have a higher traditional cvss score but in our apps it's usually considered a low impact issue)\n- Open Redirects (Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps it's usually considered a low impact issue) \n\n\n####Informational Issues\n\nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n\n\n####NOTE:\n\n- **All Flash based vulnerabilities are considered Out of Scope**\n\n- **For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you you to read underlying file/ folder structure it is prohibited to to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure**\n\n- **Please note that a lot of our public domains share the same code bases, CMSs and as such, any vulnerability found on one might exist on others. At the same time though, a lot of those issues generally require the same fix. So in cases like this, where the same fix addresses the issue in multiple places, only the first submission is going to be eligible for a reward.**\n\n- **All submissions will be evaluated on a case by case basis by the Firm`s BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.**\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n_____\n\nSpecific Vulnerabilities Guidance\n---------------------\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\n_____\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\n_____\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-24T13:21:31.944Z"},{"id":3650513,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), vulnerabilities allowing you to access file/folder structure, defacement and file uploads are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n_____\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\n_____\n\nRewards\n---------------------\nGoldman Sachs believes in rewarding findings based on their security impact regardless of the vulnerability class. Severity scores and reward amounts are calculated by evaluating two primary factors: Impact to our users and CVSS 3.0 base score. Please note that those two always work in tandem and a higher or lower CVSS score doesn't always qualify for a higher or lower reward amount. Below you'll find listed our reward structure and what usually falls under the 4 different impact classes.\n\n| Security Impact | Minimum Reward | Maximum Reward |\n| --------------- | -------------- | -------------- |\n| Critical        | $6,000         | $15,000        |\n| High            | $3,000         | $5,000         |\n| Medium          | $1,000         | $2,500         |\n| Low             | $50            | $500           |\n| Informational   | $0             | $0             |\n\n\n####Critical Impact\n\nCritical Impact findings present a direct and immediate risk to Goldman Sachs or a **majority** of our users or customers. They often affect core/ critical components in production application stacks or infrastructure. Examples might include:\n\n- Server Side Injections (RCE, Command Injections)\n- SQLi\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n\n####High Impact\n\nHigh impact findings usually materially impact **several** users/ customers or affect the security of the platform itself including the processes it supports. This would usually include the following types of issues:\n\n- SSRF\n- LFI\n- XXE\n- Significant Authentication Bypasses\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Medium Impact\n\nMedium impact findings typically materially impact a **small** number of our users/ customers and usually require little to no user interaction to trigger. They often result due to the following types of vulnerabilities:\n\n- RFI\n- Memory Leaks\n- IDORs\n- Stored XSS\n\nNote again that a finding falling under these examples doesn't automatically qualify for a critical bounty reward, the final decision is always based on the security impact of the issue.\n\n\n####Low Impact\n\nBased on how our apps are setup, low impact findings usually only affect a very small number of users or have a fairly limited security impact. These might include issues that require interaction or significant prerequisites to trigger. In our apps this would usually comprise of the below issues:\n\n- Reflected XSS (Note that Reflected XSS might have a higher traditional cvss score but in our apps it's usually considered a low impact issue)\n- Open Redirects (Similar to reflected XSS, open redirects might have a higher traditional cvss score, but in our apps it's usually considered a low impact issue) \n\n\n####Informational Issues\n\nThese are usually best practices, mitigations, issues that are by design or acceptable business risk because of the way our apps are setup. \n\n\n\n####NOTE:\n\n- **All Flash based vulnerabilities are considered Out of Scope**\n\n- **For any vulnerability (including RCE, XXE, LFI, Path Traversal etc.) that might allow you you to read underlying file/ folder structure it is prohibited to to read sensitive files (eg /etc/shadow) and/or snooping through the file/folder structure**\n\n- **Please note that a lot of our public domains share the same code bases, CMSs and as such, any vulnerability found on one might exist on others. At the same time though, a lot of those issues generally require the same fix. So in cases like this, where the same fix addresses the issue in multiple places, only the first submission is going to be eligible for a reward.**\n\n- **All submissions will be evaluated on a case by case basis by the Firm`s BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.**\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n_____\n\nSpecific Vulnerabilities Guidance\n---------------------\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\n_____\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\n_____\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-03-29T19:29:25.682Z"},{"id":3629045,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), and FileUpload vulnerabilities are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per second. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n# SLA\nGoldman Sachs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | Estimated SLA in business days | \n|----------|--------------------|\n| First Response | 1 day | \n| Time to Triage   | 2 days |\n| Time to Bounty (from triage)  | 10 days |\n| Time to Resolution   | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nSCOPE\n---------------------\nPlease carefully review the scope section below. While many of our web properties are in-scope for submissions, **not all are eligible for bounties**. \n\nRewards\n---------------------\nGoldman Sachs may provide rewards to researchers for qualifying vulnerabilities.\n\nAll submissions will be evaluated on a 1-to-1 basis by the Firm's BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.\n\n| Vulnerability Types | Maximum Payout | \n|----------|--------|\n| Remote Code Execution / OS Command Injection | $15,000 |\n| SQL Injection | $10,000 |\n| Significant Authentication Bypass | $5,000 |\n| Server Side Request Forgery | $5,000 |\n| Local file Inclusion | $5,000 |\n| XML External Entity Injection | $5,000 |\n| Remote file Inclusion | $2,500 |\n| Memory leaks | $2,500 |\n| Insecure Direct Object References | $2,500 |\n| Stored Cross Site Scripting | $2,500 |\n| Unauthorized access to sensitive information | $2,500 |\n| Reflected Cross Site Scripting | $250 |\n| Open Redirection | $250 |\n| Flash-Based Cross Site Scripting | $0 |\n|          |        |\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n____________________________________________________________________________\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-01-23T20:56:45.768Z"},{"id":3625094,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\n\u003e Do not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), and FileUpload vulnerabilities are listed below.\n\n\u003e Do not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\n\u003e If you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\n\u003e Please limit any automated scanning to 60 requests per minute. Aggressive testing that causes service degradation will be grounds for removal from the program.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n# SLA\nGoldman Sachs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | Estimated SLA in business days | \n|----------|--------------------|\n| First Response | 1 day | \n| Time to Triage   | 2 days |\n| Time to Bounty (from triage)  | 10 days |\n| Time to Resolution   | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nSCOPE\n---------------------\nPlease carefully review the scope section below. While many of our web properties are in-scope for submissions, **not all are eligible for bounties**. \n\nRewards\n---------------------\nGoldman Sachs may provide rewards to researchers for qualifying vulnerabilities.\n\nAll submissions will be evaluated on a 1-to-1 basis by the Firm's BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.\n\n| Vulnerability Types | Maximum Payout | \n|----------|--------|\n| Remote Code Execution / OS Command Injection | $15,000 |\n| SQL Injection | $10,000 |\n| Significant Authentication Bypass | $5,000 |\n| Server Side Request Forgery | $5,000 |\n| Local file Inclusion | $5,000 |\n| XML External Entity Injection | $5,000 |\n| Remote file Inclusion | $2,500 |\n| Memory leaks | $2,500 |\n| Insecure Direct Object References | $2,500 |\n| Stored Cross Site Scripting | $2,500 |\n| Unauthorized access to sensitive information | $2,500 |\n| Reflected Cross Site Scripting | $250 |\n| Open Redirection | $250 |\n| Flash-Based Cross Site Scripting | $0 |\n|          |        |\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n____________________________________________________________________________\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-12-03T16:47:43.808Z"},{"id":3617364,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\nDo not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), and FileUpload vulnerabilities are listed below.\n\nDo not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\nIf you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\nThank you for helping keep Goldman Sachs and our users safe!\n\n# SLA\nGoldman Sachs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | Estimated SLA in business days | \n|----------|--------------------|\n| First Response | 1 day | \n| Time to Triage   | 2 days |\n| Time to Bounty (from triage)  | 10 days |\n| Time to Resolution   | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nSCOPE\n---------------------\nPlease carefully review the scope section below. While many of our web properties are in-scope for submissions, **not all are eligible for bounties**. \n\nRewards\n---------------------\nGoldman Sachs may provide rewards to researchers for qualifying vulnerabilities.\n\nAll submissions will be evaluated on a 1-to-1 basis by the Firm's BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.\n\n| Vulnerability Types | Maximum Payout | \n|----------|--------|\n| Remote Code Execution / OS Command Injection | $15,000 |\n| SQL Injection | $10,000 |\n| Significant Authentication Bypass | $5,000 |\n| Server Side Request Forgery | $5,000 |\n| Local file Inclusion | $5,000 |\n| XML External Entity Injection | $5,000 |\n| Remote file Inclusion | $2,500 |\n| Memory leaks | $2,500 |\n| Insecure Direct Object References | $2,500 |\n| Stored Cross Site Scripting | $2,500 |\n| Unauthorized access to sensitive information | $2,500 |\n| Reflected Cross Site Scripting | $250 |\n| Open Redirection | $250 |\n| Flash-Based Cross Site Scripting | $0 |\n|          |        |\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research: username\n\n____________________________________________________________________________\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-08-27T21:06:14.547Z"},{"id":3612651,"new_policy":"Maintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\nDo not try to further pivot into the network by using a vulnerability. The rules around Remote Code Execution (RCE), SQL Injection (SQLi), and FileUpload vulnerabilities are listed below.\n\nDo not try to exploit service providers we use, prohibited actions include, but are not limited to bruteforcing login credentials of Domain Registrars, DNS Hosting Companies, Email Providers and/or others. The Firm does not authorize you to perform any actions to a non-GS owned property/system/service/data.\n\nIf you encounter Personally Identifiable Information (PII) contact us at bugbounty@gs.com immediately. Do not proceed with access and immediately purge any local information, if applicable.   \n\nThank you for helping keep Goldman Sachs and our users safe!\n\n# SLA\nGoldman Sachs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | Estimated SLA in business days | \n|----------|--------------------|\n| First Response | 1 day | \n| Time to Triage   | 2 days |\n| Time to Bounty (from triage)  | 10 days |\n| Time to Resolution   | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nSCOPE\n---------------------\nPlease carefully review the scope section below. While many of our web properties are in-scope for submissions, **not all are eligible for bounties**. \n\nRewards\n---------------------\nGoldman Sachs may provide rewards to researchers for qualifying vulnerabilities.\n\nAll submissions will be evaluated on a 1-to-1 basis by the Firm's BugBounty Rewards Panel. Please keep in mind that being able to execute RCE (Remote Code Execution/OS Command Injection) doesn’t necessarily mean that the impact is Critical. The BugBounty Panel will analyze the finding, evaluate the risk, and pay according to the reward schema, while taking the highest foreseen impact scenario into account. Reward amounts may vary depending upon the aforementioned risk/impact of the vulnerability reported.\n\n| Vulnerability Types | Maximum Payout | \n|----------|--------|\n| Remote Code Execution / OS Command Injection | $15,000 |\n| SQL Injection | $10,000 |\n| Significant Authentication Bypass | $5,000 |\n| Server Side Request Forgery | $5,000 |\n| Local file Inclusion | $5,000 |\n| XML External Entity Injection | $5,000 |\n| Remote file Inclusion | $2,500 |\n| Memory leaks | $2,500 |\n| Insecure Direct Object References | $2,500 |\n| Stored Cross Site Scripting | $2,500 |\n| Unauthorized access to sensitive information | $2,500 |\n| Reflected Cross Site Scripting | $250 |\n| Open Redirection | $250 |\n| Flash-Based Cross Site Scripting | $0 |\n|          |        |\n\n# Monetary bonus for IP Address and/or header identification:\nThere is a possibility that traffic generated by researchers can be categorized as malicious. Providing additional information allows us to identify your traffic. Researchers who are willing to put this information and provide it in a report will be eligible for a small monetary bonus. **This can be done by adding the following header to your request:** \n\n### X-HackerOne-Research:username\n\n____________________________________________________________________________\n\nOut of scope vulnerabilities\n---------------------\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n \n+   For the time being we are making all vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   Full Path Disclosure\n+   IP Address Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\n\nPublic Disclosure Policy\n---------------------\n* Goldman Sachs will not be publicly disclosing reports at this time. If and when Goldman Sachs does disclose a report, it will be mutually agreed upon with the hacker. \n* Goldman Sachs reserves the right to deny any request for public disclosure. If a hacker publicly discloses without consent, they run the risk of a program ban.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\nProgram Rules\n---------------------\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* 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.\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\nFile-Upload Policy\n---------------------\n\nVulnerabilities which allow upload of files through any means (f.g PUT HTTP Method, File-upload functionality/module., etc.) are subjected to these rules\n\nProhibited actions when conducting File-upload attempts:\n\n+  Altering/Modifying/Deleting/Replacing any files on the system. (f.g. defacement)\n+  Uploading files to the account of a user which is not owned by you and you are not authorized by (does not apply to system users or web users like www-data f.g)\n+  Uploading files which deliberately introduce additional exploitation vectors (f.g html code with cross-site scripting code on it etc.)\n+  Uploading files which can cause Denial of Service (f.g. over-sized files or unlimited amount of files resulting in running out of Disk Quota)\n\nAllowed actions when conducting File-upload attempts:\n\n+  Chained exploitation vectors allowing you to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.\n+  Upload of a file (any extension) with no content, simple string, integer or a special character.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-06-25T15:58:46.922Z"},{"id":3577130,"new_policy":"Committed to Coordination\n====================\n\nMaintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\nDo not try to further pivot into the network by using a vulnerability, the rules around Remote Code Execution (RCE), SQL Injection (SQLi) and vulnerabilities allowing you to access file/folder structure are listed below.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\nScope\n---------------------\n\n+   *.gs.com\n+   *.goldman.com\n+   *.goldmansachs.com\n\nOut of Scope\n---------------------\n\n+   For the time being we are making all Vulnerabilities in Flash files out of scope\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\nThe GS security team will review your submission and respond within 2 business days\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\n\n \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-05-18T09:30:42.680Z"},{"id":3575914,"new_policy":"Committed to Coordination\n====================\n\nMaintaining the security of our applications and networks is a high priority for Goldman Sachs. If you have information related to security vulnerabilities of GS products and services, please submit a report in accordance with the guidelines below. \n\nThe vulnerabilities identified in the HackerOne reports will be classified by the degree of risk as well as the impact they present to the host system, this includes the amount and type of data exposed, privilege level obtained, proportion of systems or users affected.\n\nDo not try to further pivot into the network by using a vulnerability, the rules around Remote Code Execution (RCE), SQL Injection (SQLi) and vulnerabilities allowing you to access file/folder structure are listed below.\n\nThank you for helping keep Goldman Sachs and our users safe!\n\nScope\n---------------------\n\n+   *.gs.com\n+   *.goldman.com\n+   *.goldmansachs.com\n\nOut of Scope\n---------------------\n\n+   Reports from automated tools or scans\n+   Reports affecting outdated browsers\n+   Denial of Service Attacks\n+   Issues without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack.\n+   Missing security best practices and controls (rate-limiting/throttling, lack of CSRF protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure  - without clear and working exploit)\n+   Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard presence/misconfigurations in these.\n+   Use of a known-vulnerable libraries or frameworks - for example an outdated JQuery or AngularJS (without clear and working exploit)\n+   Self-exploitation (cookie reuse, self cookie-bomb, self denial-of-service etc.)\n+   Self Cross-site Scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user\n+   Lack of HTTPS\n+   Reports about insecure SSL / TLS configuration \n+   Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a GS-related account\n+   Presence/Lack of autocomplete attribute on web forms/password managers.\n+   Server Banner Disclosure/Technology used Disclosure\n+   CSRF on logout or insignificant functionalities\n+   Publicly accessible login panels\n+   Clickjacking\n+   CSS Injection attacks. (Unless it gives you ability to read anti-CSRF tokens or other sensitive information) \n+   Tabnabbing\n+   Host Header Injection (Unless it gives you access to interim proxies)\n+   Cache Poisoning\n+   Reflective File Download\n+   Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario\n+   PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens)\n+   OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario\n+   Cookie scoped to parent domain or anything related to the path missconfiguration and improperly scoped\n+   Private IP/Hostname disclosures or real IP disclosures for services using CDN\n+   Open ports which do not lead directly to a vulnerability\n+   Our policies on presence/absence of SPF / DKIM / DMARC records\n+   Lack of DNS CAA and DNS-related configurations\n+   Weak Certificate Hash Algorithm\n+   Social engineering of GS employees or contractors\n+   Any physical/wireless attempt against GS property or data centers\n+   Do not try sending your commando-trained pigeons equipped with knowledge of RFC-2549 to sniff the traffic from our access points.\n\nProcess\n---------------------\n\nPlease submit your report by clicking on the “Submit Report” button, your submission will be reviewed and validated by a member of the GS Security team. Providing clear and concise steps to reproduce the issue will help to expedite the response. As a bare minimum, please include in your report: \n+   List the URL and any affected parameters\n+   Describe the browser, OS, and/or app version\n+   Describe the perceived impact. How could the bug potentially be exploited?\nThe GS security team will review your submission and respond within 2 business days\n\nLegal\n---------------------\n\n+   You must comply with all applicable Federal, State, and local laws in connection with your security research activities or other participation in this vulnerability disclosure program.\n+   You agree that You shall not, without the prior written consent of GS in each instance (i) use in advertising, publicity or otherwise the name of GS or its Affiliates or any trade name, trademark, trade device, service mark, symbol or any abbreviation, contraction or simulation thereof owned by GS or its Affiliates, or (ii) represent, directly or indirectly, any service or work provided by You as approved or endorsed by GS or its Affiliates.\n+   You agree that any and all information acquired or accessed by You as part of this exercise is confidential to GS and You shall hold the Confidential 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.\n+  You acknowledge and agree that any and all information you encounter is owned by GS or its third party providers, clients or customers. You have no rights, title or ownership to any information that you may encounter.\n+   GS may modify the terms of this policy or terminate the policy at any time.\n+   By clicking Submit Report, you consent to Your Information being transferred to and stored in the United States and acknowledge that you have read and accepted the Terms, Privacy Policy and Disclosure Guidelines presented to you when you created your account.\n+   Please use your own account for testing or research purposes. Do not attempt to gain access to another user’s account or confidential information.\n+   Please do not test for spam, social engineering or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not your own.\n\nRemote Code Execution (RCE) Policy\n---------------------\nVulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance to this policy.\n\nProhibited actions when conducting RCE attempts:\n+   Altering or uploading files on the web server. (In case of file-upload functionality upload of webshells is prohibited, try uploading echo, info or any variable/info-based invocation code)\n+   Altering file permissions\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (Same applies to XXE, LFI and Path Traversal, or any other vulnerability which allows you to read underlying file/folder structure)\n+   Altering/Modifying/Deleting any files on the system.\n+   Copying any files from the system and disclosing them to a non GS site or entity\n+   Interacting with underlying OS-level data and/or databases.\n+   Interacting with other services running on the OS-level and/or any remote hosts residing on the network.\n+   Interrupting the normal operation of the server.\n+   Any type of establishment for persistent connection mechanisms (netcat, ssh reverse tunnel, etc) are prohibited.\n\nAllowed actions when conducting RCE attempts - Unix:\n+   Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top' or any metrics commands\n+   Reading content of the '/etc/passwd' file\n+   Using 'echo' to pipe characters into a file located in the \"/tmp/\", reading the file and then removing it right after confirmation.\n\nAllowed actions when conducting RCE attempts - Windows:\n+   Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands\n+   Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'\n+   Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.\n\nSQL Injection (SQLi) Policy\n---------------------\n\nVulnerabilities which allow injection of attacker controlled parts of the SQL query should be run in accordance to this policy.\nProhibited actions when conducting SQLi attempts:\n+   Reading sensitive files on the system (e.g /etc/shadow) and/or snooping through the file/folder structure (SELECT LOAD_FILE)\n+   Reading specific sensitive database records\n+   Creating/Altering/Modifying/Deleting any files/records on the system/database. This includes use of INTO OUTFILE\n+   Command Execution (xp_cmdshell, uploading .so or any action that leads to command execution)\n+   Creating/Deleting Users\n+   Reading/Altering Username and Password information (includes password hashes)\n+   Interrupting the normal operation of the server and the database.\n\nAllowed actions when conducting SQLi attempts:\n+   Executing SELECT queries such as \"@@version\", \"user();\" \"system_user();\", \"database();\", \"@@hostname\"\n+   Listing Databases names from schema, listing Columns, Table names\n+   Executing Mathematical, conversion or logical queries, such as:\n\n1. ASCII Value -\u003e Char (SELECT char(65); # returns A)\n2. Char -\u003e ASCII Value (SELECT ascii(‘A’); # returns 65)\n3. String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC)\n4. Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A)\n5. SELECT 0×414243; # returns ABC\n6. Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); )\n\n+   Using Logic and time in Server Responses \n+   Using output responses\n\n\n \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-05-08T17:09:53.755Z"}]